CHAPTER 6 ANALYSIS STRUCTURING SYSTEM REQUIREMENTS DESIGN STRATEGY

CHAPTER 6 ANALYSIS: STRUCTURING SYSTEM REQUIREMENTS & DESIGN STRATEGY 1

Where R we now? ? 2

Introduction n Requirements structuring is the process to use some kind of: n systematical and standard, well-structured methods to model the real world. n n n Process modeling Logic modeling Data modeling 3

I. Process Modeling q Process modeling involves represent the processes that: q graphically capture, manipulate, store and distribute data between a system and its environment and among system components. A common form of a process model is a data flow diagram (DFD). q Data flow diagrams (DFD) q Graphically illustrate movement of data q between external entities and the processes and data stores within a system 4

Modeling a system’s process q As part of structuring you must: q q Utilize information gathered requirements determination during In addition to modeling the process, Structure of the data is also modeled Deliverables? ? ? 5

Deliverables and Outcomes q Set of coherent, interrelated DFD q Context data flow diagram (DFD) q Shows the scope of system q q Shows which element is inside and outside the system DFDs of current system Enables analysts to understand current system q Specify the peoples and technology involved q q DFDs of new logical system Technology independent q Show data flows, structure requirements of new system q So how to draw? ? ? ? ? and functional 6

Data flow diagramming mechanics q Four symbols are used q Developed by Gane and Sarson 7

Data flow Diagramming Mechanics q Data Flow q Depicts data that are in motion and moving as a unit from one place to another in the system Drawn as an arrow Select a meaningful name to represent the data q The data can be : q q q Result of a query to a database Content of report Data entry form of computer display 8

Data flow Diagramming Mechanics q Data Store q q Depicts data at rest May represent data in: q q File folder Computer-based file Drawn as a rectangle with the right hand vertical line missing Label includes: q name of the store as well as the number 9

Data flow Diagramming Mechanics q Process q Depicts work or action performed on data so that they are transformed, stored or distributed q Drawn as a rectangle with rounded corners q Number of process as well as name are recorded 10

Data flow Diagramming Mechanics q Source/Sink Depicts the origin and/or destination of the data q Sometimes referred to as an external entity q Drawn as a square symbol q Name states what the external agent is q Because they are external, many characteristics are not of interest to us q 11

Data Flow Diagramming Definitions q Context Diagram q A data flow diagram (DFD) of the scope of an organizational system that shows: q q the system boundaries, external entities that interact with the system and the major information flows between the entities and the system Level-O Diagram q A data flow diagrams (DFD) that represents: q a system’s major processes, data flows and data stores at a higher level 12

Developing DFDs: An Example automated food ordering system q Figure shows Context Diagram q Contains no data stores q 13

Context diagram of Hoosier Burger’s food ordering system 14

Example (continued) Expand the context diagram to show the breakdown of processes q Also show data interrelationship q 15

Level-0 DFD of Hoosier Burger’s food ordering system 16

Data Flow Diagramming Rules q Basic rules that apply to all DFDs q Inputs to a process are always different than outputs q Objects always have a unique name q In order to keep the diagram uncluttered, you can repeat data stores and data flows on a diagram 17

Data Flow Diagramming Rules q Process q q No process can have only outputs (a miracle) No process can have only inputs (black hole) A process has a verb phrase label Data Store q Data cannot be moved from one store to another Data cannot move from an outside source to a data store Data cannot move directly from a data store to a data sink q Data store has a noun phrase label q q 18

Miracle and Black hole 19

All flows to or from a data store must move through a process. Data store labels should be noun phrases. 20

q q Data Flow Diagramming Rules Source/Sink q Data cannot move directly from a source to a sink q A source/sink has a noun phrase label Data Flow q A data flow has only one direction of flow between symbols q A join means that exactly the same data come from any two or more different processes, data stores or sources/sinks to a 21

No data moves directly between external entities without going through a process. Interactions between external entities without intervening processes are outside the system and therefore not represented in the DFD. Source and sink labels should be noun phrases. 22

Data Flow Diagramming Rules n A fork means that exactly the same data goes from a common location to two or more processes, data stores or sources/sinks q A data flow cannot go directly back to the same process it leaves q A data flow to a data store means update q A data flow from a data store means retrieve or use q A data flow has a noun phrase label 23

24

25

Decomposition of DFDs q Functional decomposition Act of going from one single system to many component processes q Repetitive procedure q Lowest level is called a primitive DFD q q Level-N Diagrams q A DFD that is the result of n nested decompositions of a series of sub processes from a process on a level-0 diagram 26

Decomposition of DFDs n Hoosier Burger’s automated food ordering system n Context Diagram contains no data stores n Next step is to expand the context diagram to show the breakdown of processes 27

Context diagram of Hoosier Burger’s food ordering system 28

Level-0 DFD of Hoosier Burger’s food ordering system 29

Decomposition of DFDs: Level-1 DFD of process 1 30

Decomposition of DFDs: Level 1 & 2 DFD of process 4 31

Balancing DFDs q When decomposing a DFD, you must conserve inputs to and outputs from a process at the next level of decomposition q q This is called balancing Example: Hoosier Burgers q q In the above example, notice that there is one input to the system: the customer order Three outputs: q q q Customer receipt Food order Management reports 32

Balancing DFDs q In context diagram, we have one input to the system, A and one output, B in the next slide. q Level-0 diagram has one additional data flow, C q These DFDs are not balanced 33

Balancing DFDs: An Unbalanced Example 34

Balancing DFDs q We can split a data flow into separate data flows on a lower-level diagram 35

Balancing DFDs: Four Additional Advanced Rules 36

Additional Guidelines for Drawing DFDs 1. Completeness q q 2. DFD must include all components necessary for system Each component must be fully described in the project dictionary or CASE repository Consistency q The extent to which information contained on one level of a set of nested DFDs is also included on other levels 37

Guidelines for Drawing DFDs 3. Timing q 4. Time is not represented well on DFDs Iterative Development q Analyst should expect to redraw diagram several times before reaching the closest approximation to the system being modeled 38

Guidelines for Drawing DFDs 5. Primitive DFDs q q Lowest logical level of decomposition Decision has to be made when to stop decomposition 39

Guidelines for Drawing DFDs q Rules for stopping decomposition q When each process has been reduced to a single: q q decision, calculation or database operation When each data store represents data about a single entity q When the system user does not care to see any more detail 40

Guidelines for Drawing DFDs q Rules for stopping decomposition (continued) q When every data flow does not need to be split further to show that data are handled in various ways q When you believe that you have shown: q each transaction, online display and report as a single data flow 41

Using DFDs as Analysis Tools q Gap Analysis q q The process of discovering discrepancy between two or more sets of data flow diagrams or discrepancies within a single DFD Inefficiencies in a system can often be identified through DFDs 42

II. Logic Modeling q q q Data flow diagrams do not show the logic inside the processes Logic modeling involves representing internal structure and functionality of processes depicted on a DFD Three methods Structured English q Decision Tables q 43

Modeling Logic with Structured English q Can be used to represent all the 3 fundamental statements necessary for structured programming: q q q Modified form of English used to specify the logic of information processes Uses a subset of English q q Choice Repetition and Sequence Action verbs like read, write, print, sort, move, merge, add, subtract, multiply, divide, etc Noun phrases like customer name, customer id, etc No adjectives or adverbs No specific standards 44

Modeling Logic with Structured English q q Sequence structure requires no special structure but can be represented with one statement following another Conditional statement can be represented with a structure like the following q BEGIN IF q q q IF quantity in stock is less than minimum order quantity THEN GENERATE new order ELSE DO nothing END IF OR 45

Modeling Logic with Structured English q q READ quantity in stock SELECT CASE q CASE 1 (quantity in stock greater than minimum order quantity) q q CASE 2 (quantity in stock equals to minimum order quantity) q q DO nothing CASE 3 (quantity in stock less than minimum order quantity) GENERATE new order q END CASE 46

Modeling Logic with Structured English q q Repetition can take the form DO-UNTIL loops or DO-WHILE loops A DO-UNTIL loop can be represented as q DO q q READ (inventory records) quantity in stock BEGIN IF q q q IF quantity in stock (inventory records) Is less than minimum order quantity THEN GENERATE new order ELSE DO nothing END IF UNTIL End of the file q OR 47

Modeling Logic with Structured English q A DO-WHILE loop can be represented as READ inventory records q WHILE NOT End of the file DO q q BEGIN IF q q q IF quantity in stock is less than minimum order quantity THEN GENERATE new order ELSE DO nothing END IF END DO 48

Modeling Logic with Structured English q Remarks: q No mathematical symbols are used q Logic modeling is implemented to process that are at lowest level (primitive DFD) 49

Example DFD and structured logic modeling Stock on hand 1. 0 Invoices Supplier Update inventory added counts Payment Invoices Amount added 4. 0 Generate payment Amount used 2. 0 Update inventory used D 1: Inventory Minimum order quantities Inventory levels 3. 0 Generate orders 50

51

Modeling Logic with Decision Tables q q q There are processes with complex conditions and action to be checked and decide Structured English require complex nested IF and difficult to understand DT is a matrix representation of the logic of a decision q q Specifies the possible conditions and the resulting actions Best used for complicated decision logic 52

Modeling Logic with Decision Tables q Consists of three parts q Condition stubs q q Action stubs q q Lists condition relevant to decision Actions that result for a given set of conditions Rules q Specify which actions are to be followed for a given set of conditions 53

Modeling Logic with Decision Tables q Indifferent Condition q q Condition whose value does not affect which action is taken for two or more rules Standard procedure for creating decision tables q q q Name the condition and values each condition can assume Name all possible actions that can occur List all possible rules (total number of rules = product of number of values of each condition) Define the actions for each rule (See Figure 5 -18) Simplify the table (See Figure 5 -19) 54

55

Rules for simplifying the table q Combine rules where it is apparent that an alternative doesn’t make a difference in the outcome Condition 1 Condition 2 Y Y Y N Condition 1 Condition 2 Y - Action 1 X X Action 1 X 56

Rules for simplifying the table q Check the table for any impossible situations, contradictions, and redundancies 57

Rules Conditions 1 2 3 4 5 6 7 8 Customer order from fall catalog Y Y N N Customer order from X-Mass catalog Y Y N N Customer order from specialty catalog Y N Y N Actions X Send out this year X-Mass catalog X X Send out speciality catalog Send out both catalogs X X X 58

Rules Conditions 1 2’’ 3 5 7 Customer order from fall catalog Y - Y N N Customer order from X-Mass catalog Y - N Y N Customer order from specialty catalog Y N Y Y Y Actions X Send out this year X-Mass catalog X Send out speciality catalog Send out both catalogs X X X 59

Rules Conditions 1” 2’’ 3” Customer order from fall catalog - - - Customer order from X-Mass catalog Y - N Customer order from specialty catalog Y N Y 5 7 actions X Send out this year X-Mass catalog X Send out speciality catalog Send out both catalogs X 60

61

Modeling Logic with Decision Trees q A graphical representation decision situation of a Decision situation points are connected together by arcs and terminate in ovals q Two main components q n n Decision points represented by nodes Actions represented by ovals 62

Modeling Logic with Decision Trees Read from left to right q Each node corresponds to a numbered choice on a legend q All possible actions are listed on the far right q 63

Generic decision tree 64

Decision tree representation of the decision logic in the decision tables in Figures 9 -4 and 9 -5 65

Decision tree representation of the decision logic in the decision tables in Figures 9 -4 and 9 -5 66

Decision tree representation of the decision logic in the decision tables in Figures 9 -4 and 9 -5 Criteria Structured English Decision Tables Decision Trees Determining Conditions and Actions Second Best Third Best Transforming Conditions and Actions into Sequence Best Third Best Checking Consistency and Completeness Third Best 67

Decision tree representation of the decision logic in the decision tables in Figures 9 -4 and 9 -5 68

III. Data Modeling q q Data modeling is the act of exploring dataoriented structures through the identification of the relationships among the data objects that are used in a business. Representation of organizational data q q In data modeling you identify entity type, data attributes are assigned to entity types and associations between entities are determined. Consistency must be maintained between process flow, decision logic and data modeling descriptions 69

Data Modeling q There are 3 types of data modeling, these are: Conceptual data modeling (CDM) q Logical data modeling (LDM)/Logical Database Design q Physical data modeling (PDM)/ Physical Database Design q 70

Conceptual Data modeling q q It is called domain models, are typically used to explore domain concepts of the business. Purpose is to show rules about the meaning and interrelationships among data Entity-Relationship (E-R) diagrams are commonly used to show data are organized Main goal of conceptual data modeling is to create accurate E-R diagrams q Methods such as interviewing, questionnaires and JAD are used to collect information 71

Gathering Information for Conceptual Data Modeling q Two perspectives q Top-down q q Data model is derived from an intimate understanding of the business Bottom-up q Data model is derived by reviewing specifications and business documents 72

Introduction to Entity. Relationship (E-R) Modeling q Notation uses three main constructs Data entities q Relationships q Attributes q q Entity-Relationship (E-R) Diagram q A detailed, logical and graphical representation of the entities, associations and data elements for an organization or business 73

Entity-Relationship (E-R) Modeling Key Terms q Entity q q A person, place, object, event or concept in the user environment about which the organization wishes to maintain data rectangle Represented by a What Should an Entity Be? SHOULD BE: q q in E-R diagrams An object that will have many instances in the database An object that will be composed of multiple attributes An object that we are trying to model SHOULD NOT BE: q q A user of the database system An output of the database system (e. g. a report) 74

Entity-Relationship (E-R) Modeling Key Terms q Entity q q q A person, place, object, event or concept in the user environment about which the organization wishes to maintain data Represented by a rectangle in E-R diagrams Attribute q A named property or characteristic of an entity that is of interest to an organization 75

Entity-Relationship (E-R) Modeling Key Terms q Candidate keys and identifiers Each entity type must have an attribute or set of attributes that distinguishes one instance from other instances of the same type q Candidate key q q Attribute (or combination of attributes) that uniquely identifies each instance of an entity type Alternate key q Primary key q 76

77

78

79

Address Employee-Name Dependent Employee-ID Employee-Name Address Dep-Name Dep-Age Employee-ID Employee Dependent Dep-Relation 80

Entity-Relationship (E-R) Modeling Key Terms q Relationship An association between the instances of one or more entity types that is of interest to the organization q Association indicates that an event has occurred or that there is a natural link between entity types q Relationships are always labeled with verb phrases q 81

Degree of Relationship q Degree q q Number of entity types that participate in a relationship Three cases q Unary q q Binary q q A relationship between the instances of one entity type A relationship between the instances of two entity types Ternary q q A simultaneous relationship among the instances of three entity types Not the same as three binary relationships 82

Cardinality q q The number of instances of entity B that can be associated with each instance of entity A Minimum Cardinality q q The minimum number of instances of entity B that may be associated with each instance of entity A Maximum Cardinality q The maximum number of instances of entity B that may be associated with each instance of entity A 83

q q Selecting the Best Alternative Design Strategy Two basic steps 1. 2. Generate a comprehensive set of alternative design strategies Select the one design strategy that is most likely to result in the desired information system Process q Divide requirements into different sets of capabilities. q Enumerate different potential implementation environments that could be used to deliver the different sets of capabilities. q Propose different ways to source or acquire the various sets of capabilities for the different implementation environments. 84

Selecting the Best Alternative Design Strategy q If there are 3 sets of requirements, 2 implementation environments, and 4 sources of application software, there would be 24 possible design strategies. 85

Selecting the Best Alternative Design Strategy q Deliverables 1. At least 3 substantially different system design strategies for building the replacement information system 2. A design strategy judged most likely to lead to the most desirable information system 3. A Baseline Project Plan (BPP) for turning the most likely design strategy into a working information system 86

Generating Alternative Design Strategies q n n In alternative design decision we are required to fined out problem with the existing system. In the process of finding the problems in the existing system, we use the PIECES framework as a main tool. PIECES stands for Performance, Information, Economics, Control, Efficiency Service. 87

Generating Alternative Design Strategies q Performance q q Information q q Performance of a system is measured in terms of throughput and response time. Availability of up-to-date and relevant information is vital for a given system to reach to an accurate decision. Economic q The existing system has to be evaluated from the economic point of view by analyzing the costs and benefits. 88

Generating Alternative Design Strategies q Control q q Efficiency q q This is about degree of security of the data/system in general. Here we are expected to list down all security related problems of the existing system. Here we deal with cost-effectiveness problems of the existing system. Service q We evaluate the existing system service related problems. Whether customer satisfied or not? 89

Generating Alternative Design Strategies q Best to generate three alternatives q Low-end q q High-end q q Provides all required functionality users demand with a system that is minimally different from the current system Solves problem in question and provides many extra features users desire Midrange Lies between the extremes of the low-end and high-end systems. q Combines the frugality of low-end alternative with the 90 focus on functionality of high-end. q

q q Drawing Bounds on Alternative Designs To determine the bound between alternative designs we need to consider 2 criteria: 1. Minimum Requirements 2. Constraints 1. The Minimum Requirements q Mandatory refers any feature that must not missed. q Mandatory features are those that every one agreed necessary to solve the problem. Essential features are the important capabilities of a system that serves as the primary basis for comparison of different design strategies. q Desire features are those that users could live with out. q 91

92

Drawing Bounds on Alternative Designs q 2. Constraints on System Development q q q A date when the replacement system is needed. Available financial and human resources. Legal and contractual restriction. q q A software package bought off-the shelf cannot be legally modified. Or number of concurrent users of a package sw The importance or dynamics of the problem that may limit how the system can be acquired. q A strategically important system that uses highly proprietary data can not be outsourced or purchased. 93

Issues to Consider in Generating Alternatives q potential implementation environments n n Mainframe with central database Vs with Clientserver architecture (Distributed with decentralized databases) Batch data input with on-line retrieval and processing or real time data input and process Working environment stand alone or networked Old vs new hw/sw 94

Implementation and Organizational Issues q Implementation Issues Technical and social aspects of implementation need to be addressed q Training q Disruption of work q n Organizational Issues n n n Overall cost and availability of funding Management support User acceptance 95

Hardware and Software Issues Existing Platform 1. 2. 3. 4. Lower costs Information system staff is familiar with operation and maintenance Increased odds of successfully integrating system with existing applications No added costs of converting old systems to new platform or transferring data New Hardware and System Software 1. 2. 3. Some software components will only run on new platform Developing system for new platform gives organization opportunity to upgrade technology holdings New requirements may allow organization to radically change its computing operations (From mainframe computing into client/server structure) 96

Issues to Consider in Generating Alternatives n Source alternatives n q Outsourcing q q q In house development , outsourcing, Purchasing… The practice of turning over responsibility of some to all of an organization’s information systems applications and operations to an outside firm Can provide a cost-effective solution Outside Sources of Software q q q Hardware manufacturers Packaged software producers Custom software producers…… 97

98

Criteria for Choosing Off-the-Shelf Software q Cost q q Functionality q q Mandatory, essential and desired features Vendor Support q q In-house versus purchased Installation Training Technical Support Viability of Vendor q Staying in business for very long period. 99

Criteria for Choosing Off-the-Shelf Software q Flexibility q q Documentation q q q User documentation Technical documentation Response Time q q Ease of customization How long it takes the software package to respond to the user’s requests. Ease of Installation q The level of difficulty of loading the software and making it operational. 100

101

Hoosier Burger’s New Inventory Control System Replacement for existing system q Figure 7 -4 ranks system requirements and constraints q 102

103

Hoosier Burger’s New Inventory Control System q q Figure 7 -5 shows steps of current (OLD) system When proposing alternatives, the Criteria (i. e. requirements & constraints) must be considered 104

105

Hoosier Burger’s New Inventory Control System q Figure 7 -7 lists 3 alternatives q Alternative A is a low-end proposal q Alternative B is a midrange proposal q Alternative C is a high-end proposal 106

107

Hoosier Burger’s New Inventory Control System q Selecting the most likely alternative q q q Weighted approach can be used to compare three alternatives Figure 7 -8 shows a weighted approach for Hoosier Burger Left-hand side of table contains decision criteria q q q Constraints and requirements Weights are arrived at by discussion with analysis team, users and managers Each requirement and constraint is ranked q 1 indicates that the alternative does not match the request well or that it violates the constraint q 5 indicates that the alternative meets or exceeds requirements or clearly abides by the constraint 108

109

Hoosier Burger’s New Inventory Control System q Selecting the most likely alternative q According to the weights used, alternative C appears to be the best choice 110

Updating the Baseline Project Plan (BPP) q q The Baseline Project Plan (BPP) was developed during systems planning and selection phase Baseline Project Plan (BPP) can be used as an outline of a status report at analysis phase Schedule will be updated to reflect actual activities and durations An oral presentation of project status is typically made at this phase 111

Updating the Baseline Project Plan (BPP) q Section 1. 0. B q q Section 2. 0. A q q Contains descriptions of the competing strategies studied during alternative generation and selection. Section 3. 0. F q q Contains recommendation for the chosen design strategy Describe more specific resource allocation and task duration during the analysis phase and whatever additional details can be anticipated for latter phase (design) Section 4. 0 q Re-assess management issues 112

Updating the Baseline Project Plan (BPP) q Your project team should update these areas based on your current understanding of documenting alternatives 113

Before and after BPP for Hoosier Burger The Hoosier Burger’s initial costbenefit analysis for the inventory project is shown in figure 7. 10 q The numbers in the spreadsheet are based in part on the constraints listed in Figure 7. 4 (Budget, time frame, and training needs) q 114

Hoosier Burger Economic Feasibility Analysis figure 7. 10 Inventory Control System Year of Project Year 0 Net economic benefit Year 1 Year 2 Year 3 Year 4 Year 5 $0 $30, 000 $30, 000 1. 0000 0. 8929 0. 7972 0. 7118 0. 6355 0. 5674 PV of benefits $0 $26, 786 $23, 916 $21, 353 $19, 066 $17, 023 NPV of all BENEFITS $0 $26, 786 $50, 702 $72, 055 $91, 120 $108, 143 $0 ($2, 000) ($2, 000) 1. 0000 0. 8929 0. 7972 0. 7118 0. 6355 0. 5674 0 ($1, 786) ($1, 594) ($1, 424) ($1, 271) ($1, 135) ($100, 000) ($101, 786) ($103, 380) ($104, 804) ($106, 075) ($107, 210) Discount rate (12%) One-time COSTS Recurring Costs Discount rate (12%) PV of Recurring Costs NPV of all COSTS Overall NPV Overall ROI - (overall NPV / NPV of all TOTAL $108, 143 (100, 000) ($107, 210) $934 115

Before and after BPP for Hoosier Burger q The cost benefit analysis figure 7. 10 (OLD) is constructed based on the initial economic Analysis worksheet shown in table 7 -4. 116

Before and after BPP for Hoosier Burger Table 7. 4 One-time const: Development 50, 000 One-time costs: Hardware 50, 000 Recurring costs: Maintenance, per year 2, 000 Savings: Fewer stock-outs due to automatic reordering, per year 12, 000 Savings: More accurate data from shipment logging 18, 000 Intangible benefit: Better management information 117

Before and after BPP for Hoosier Burger q q q Figure 7 -11 (NEW) shows the cost-benefits analysis after the analysis phase has ended. The information appears in the updated BPP. Notice that developing the new system, represented by alternative C in figure 7 -10 is better investment , with a 15% return. 118

Hoosier Burger Economic Feasibility Analysis figure 7. 11 Inventory Control System Year of Project Year 0 Net economic benefit Year 1 Year 2 Year 3 Year 4 Year 5 $0 $39, 000 $39, 000 1. 0000 0. 8929 0. 7972 0. 7118 0. 6355 0. 5674 PV of benefits $0 $34, 821 $31, 091 $27, 759 $24, 785 $22, 130 NPV of all BENEFITS $0 $34, 821 $65, 912 $93671 $118, 457 $140, 586 $0 ($2, 000) ($2, 000) 1. 0000 0. 8929 0. 7972 0. 7118 0. 6355 0. 5674 0 ($1, 786) ($1, 594) ($1, 424) ($1, 271) ($1, 135) ($115, 000) ($116, 786) ($118, 380) ($119, 804) ($121, 075) ($122, 210) Discount rate (12%) One-time COSTS Recurring Costs Discount rate (12%) PV of Recurring Costs NPV of all COSTS Overall NPV Overall ROI - (overall NPV / NPV of all costs) TOTAL $140, 586 (115, 000) ($122, 210) $18, 377 119 0. 15

Before and after BPP for Hoosier Burger Much of figure 7 -11 is the same as Figure 7 -10 except the net benefits are now estimated to be larger than in figure 7 -10. q Detail revised statements of economic analysis worksheet shown in table 7 -5. q 120

Before and after BPP for Hoosier Burger figure 7. 5 One-time const: Development 65, 000 One-time costs: Hardware 50, 000 Recurring costs: Maintenance, per year 2, 000 Savings: Fewer stock-outs due to automatic reordering, per year 12, 000 Savings: More accurate data from shipment logging, per year 15, 000 Saving: Better management information and availability, per year 12, 000 121