CHAPTER 6

ANALYSIS: STRUCTURING SYSTEM

REQUIREMENTS & DESIGN
STRATEGY

1
Where R we now????

2
 Introduction

 Requirements structuring is the

process to use some kind of:
 systematical and standard, well-structured
methods to model the real world.
 Process modeling
 Logic modeling
 Data modeling
3
 I. Process Modeling
 Process modeling involves graphically
represent the processes that:
 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).
 Data flow diagrams (DFD)
 Graphically illustrate movement of data
between external entities and the processes and
data stores within a system 4
 Modeling a system’s process
 As part of structuring you must:

 Utilize information gathered during

requirements determination

 In addition to modeling the process,

Structure of the data is also modeled

Deliverables??????
5
 Deliverables and Outcomes

 Set of coherent, interrelated DFD

 Context data flow diagram (DFD)
 Shows the scope of system
 Shows which element is inside and outside the system
 DFDs of current system
 Enables analysts to understand current system
 Specify the peoples and technology involved

 DFDs of new logical system

 Technology independent
 Show data flows, structure and functional
requirements of new system
So how to draw????????? 6
Data flow diagramming mechanics

 Four symbols are used

 Developed by Gane and Sarson

7
 Data flow Diagramming Mechanics
 Data Flow
 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

 The data can be :

 Result of a query to a database
 Content of report
 Data entry form of computer display
8
 Data flow Diagramming Mechanics
 Data Store
 Depicts data at rest
 May represent data in:
 File folder
 Computer-based file

 Drawn as a rectangle with the right hand vertical

line missing

 Label includes:
 name of the store as well as the number
9
 Data flow Diagramming Mechanics
 Process
 Depicts work or action performed on data so
that they are transformed, stored or distributed
 Drawn as a rectangle with rounded corners
 Number of process as well as name are recorded

10
 Data flow Diagramming Mechanics
 Source/Sink
 Depicts the origin and/or destination of the
data
 Sometimes referred to as an external entity

 Drawn as a square symbol

 Name states what the external agent is

 Because they are external, many

characteristics are not of interest to us

11
 Data Flow Diagramming Definitions
 Context Diagram
 A data flow diagram (DFD) of the scope of an
organizational system that shows:
 the system boundaries, external entities that interact
with the system and the major information flows between
the entities and the system
 Level-O Diagram
 A data flow diagrams (DFD) that represents:
 a system’s major processes, data flows and data stores at
a higher level
12
 Developing DFDs: An Example
 automated food ordering system
 Figure shows Context Diagram
 Contains no data stores

13
Context diagram of Hoosier Burger’s food
ordering system

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

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

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

17
 Data Flow Diagramming Rules
 Process
 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
 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
 Data store has a noun phrase label

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
 Data Flow Diagramming Rules
 Source/Sink
 Data cannot move directly from a source to a sink


A source/sink has a noun phrase label
 Data Flow
 A data flow has only one direction of flow between symbols


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
 A fork means that exactly the same data goes from a common
location to two or more processes, data stores or sources/sinks
 A data flow cannot go directly back to the same process it leaves
 A data flow to a data store means update
 A data flow from a data store means retrieve or use

 A data flow has a noun phrase label

23
24
25
 Decomposition of DFDs
 Functional decomposition

Act of going from one single system to many
component processes
 Repetitive procedure

 Lowest level is called a primitive DFD

 Level-N Diagrams

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
 Hoosier Burger’s automated food ordering system
 Context Diagram contains no data stores
 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

 When decomposing a DFD, you must conserve

inputs to and outputs from a process at the next
level of decomposition
 This is called balancing
 Example: Hoosier Burgers
 In the above example, notice that there is one input to the
system: the customer order
 Three outputs:
 Customer receipt
 Food order
 Management reports

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

33
Balancing DFDs: An Unbalanced Example

34
 Balancing DFDs
 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
 DFD must include all components necessary for
system
 Each component must be fully described in the
project dictionary or CASE repository
2. Consistency
 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
 Time is not represented well on DFDs
4. Iterative Development
 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
 Lowest logical level of decomposition
 Decision has to be made when to stop
decomposition

39
 Guidelines for Drawing DFDs
 Rules for stopping decomposition
 When each process has been reduced to a single:
 decision, calculation or database operation

 When each data store represents data about a single

entity
 When the system user does not care to see any more
detail 40
 Guidelines for Drawing DFDs
 Rules for stopping decomposition (continued)
 When every data flow does not need to be split
further to show that data are handled in various ways
 When you believe that you have shown:
 each transaction, online display and report as a single
data flow

41
 Using DFDs as Analysis Tools
 Gap Analysis
 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
 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
 Decision Tables
 Decision Tree
43
 Modeling Logic with Structured
English
 Can be used to represent all the 3 fundamental
statements necessary for structured programming:
 Choice
 Repetition and
 Sequence
 Modified form of English used to specify the logic of
information processes
 Uses a subset of English
 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
 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
 BEGIN IF
 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

 READ quantity in stock

 SELECT CASE
 CASE 1 (quantity in stock greater than minimum order quantity)
 DO nothing
 CASE 2 (quantity in stock equals to minimum order quantity)
 DO nothing
 CASE 3 (quantity in stock less than minimum order quantity)
GENERATE new order

 END CASE

46
 Modeling Logic with Structured English

 Repetition can take the form DO-UNTIL loops or

DO-WHILE loops

 A DO-UNTIL loop can be represented as

 DO
 READ (inventory records) quantity in stock
 BEGIN IF
 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
 OR
47
 Modeling Logic with Structured
English

 A DO-WHILE loop can be represented as

 READ inventory records
 WHILE NOT End of the file DO
 BEGIN IF
 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
 Remarks:
 No mathematical symbols are used

 Logic modeling is implemented to process

that are at lowest level (primitive DFD)

49
 Example DFD and structured
logic modeling
1.0 Stock on hand
Update inventory
Invoices added
Supplier

counts

Payment Invoices

Amount 2.0
added Amount Update inventory used
used

D1: Inventory
4.0
Generate payment

Minimum order
Inventory levels
quantities

3.0
Generate orders

50
51
 Modeling Logic with Decision
Tables
 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
 Specifies the possible conditions and the resulting
actions
 Best used for complicated decision logic

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

53
 Modeling Logic with Decision
Tables
 Indifferent Condition
 Condition whose value does not affect which action is taken for
two or more rules
 Standard procedure for creating decision
tables
 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
 Combine rules where it is apparent that an
alternative doesn’t make a difference in
the outcome
Condition 1 Y Y Condition 1 Y
Condition 2 Y N Condition 2 -
Action 1 X X
Action 1 X

56
 Rules for simplifying the table
 Check the table for any impossible
situations, contradictions, and
redundancies

57
 Rules

Conditions 1 2 3 4 5 6 7 8

Y Y Y Y N N N N
Customer order from fall catalog
Y Y N N Y Y N N
Customer order from X-Mass catalog
Y N Y N Y N Y N
Customer order from specialty catalog
Actions
X X X X
Send out this year X-Mass catalog

X X
Send out speciality catalog

X X
Send out both catalogs

58
 Rules

Conditions 1 2’’ 3 5 7

Y - Y N N
Customer order from fall catalog

Y - N Y N
Customer order from X-Mass catalog

Y N Y Y Y
Customer order from specialty catalog

Actions
X
Send out this year X-Mass catalog

X X
Send out speciality catalog

X X
Send out both catalogs

59
 Rules

Conditions 1” 2’’ 3” 5 7

- - -
Customer order from fall catalog

Y - N
Customer order from X-Mass catalog

Y N Y
Customer order from specialty catalog

actions
X
Send out this year X-Mass catalog

X
Send out speciality catalog

X
Send out both catalogs

60
61
Modeling Logic with Decision Trees
 A graphical representation of a
decision situation

 Decision situation points are

connected together by arcs and
terminate in ovals
 Two main components
 Decision points represented by nodes
 Actions represented by ovals
62
 Modeling Logic with Decision Trees
 Read from left to right
 Each node corresponds to a

numbered choice on a legend

 All possible actions are listed on the

far right

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 Decision Decision

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

68
 III. Data Modeling
 Data modeling is the act of exploring data-
oriented structures through the identification of
the relationships among the data objects that are
used in a business.
 Representation of organizational data

 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
 There are 3 types of data modeling, these
are:
 Conceptual data modeling (CDM)
 Logical data modeling (LDM)/Logical Database
Design
 Physical data modeling (PDM)/ Physical
Database Design

70
 Conceptual Data modeling
 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 how data are organized
 Main goal of conceptual data modeling is to
create accurate E-R diagrams
 Methods such as interviewing, questionnaires and
JAD are used to collect information
71
Gathering Information for
Conceptual Data Modeling
 Two perspectives
 Top-down
 Data model is derived from an intimate
understanding of the business
 Bottom-up
 Data model is derived by reviewing
specifications and business documents

72
Introduction to Entity-
Relationship (E-R) Modeling
 Notation uses three main constructs
 Data entities
 Relationships

 Attributes

 Entity-Relationship (E-R) Diagram

 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
 Entity
 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
 What Should an Entity Be?
 SHOULD BE:
 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:

 A user of the database system
 An output of the database system (e.g. a report)

74
Entity-Relationship (E-R) Modeling
Key Terms
 Entity
 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
 A named property or characteristic of an entity
that is of interest to an organization

75
Entity-Relationship (E-R) Modeling
Key Terms
 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
 Candidate key
 Attribute (or combination of attributes) that
uniquely identifies each instance of an entity type
 Alternate key
 Primary key

76
77
78
79
 Address
Employee-Name

Dependent
Employee-ID
Employee

Address
Employee-Name Dep-Name
Dep-Age

Employee-ID
Employee Dependent Dep-Relation

80
Entity-Relationship (E-R) Modeling
Key Terms

 Relationship
 An association between the instances of
one or more entity types that is of interest
to the organization
 Association indicates that an event has

occurred or that there is a natural link

between entity types
 Relationships are always labeled with verb

phrases

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

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

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

 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
 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
 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
 Performance
 Performance of a system is measured in terms of
throughput and response time.
 Information
 Availability of up-to-date and relevant information is
vital for a given system to reach to an accurate
decision.
 Economic
 The existing system has to be evaluated from the
economic point of view by analyzing the costs and
benefits.

88
 Generating Alternative Design
Strategies
 Control
 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.
 Efficiency
 Here we deal with cost-effectiveness problems of the
existing system.
 Service
 We evaluate the existing system service related
problems. Whether customer satisfied or not?

89
 Generating Alternative Design
Strategies
 Best to generate three alternatives
 Low-end
 Provides all required functionality users demand with a
system that is minimally different from the current system
 High-end
 Solves problem in question and provides many extra
features users desire
 Midrange
 Lies between the extremes of the low-end and high-end
systems.
 Combines the frugality of low-end alternative with the focus
on functionality of high-end.
90
 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
 Mandatory refers any feature that must not missed.
 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.
 Desire features are those that users could live with out.

91
92
 Drawing Bounds on Alternative Designs

2. Constraints on System Development


 A date when the replacement system is needed.
 Available financial and human resources.
 Legal and contractual restriction.
 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.
 A strategically important system that uses highly
proprietary data can not be outsourced or purchased.

93
 Issues to Consider in Generating
Alternatives
 potential implementation environments
 Mainframe with central database Vs with Client-
server 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

 Implementation Issues
 Technical and social aspects of
implementation need to be addressed
 Training
 Disruption of work
 Organizational Issues
 Overall cost and availability of funding
 Management support
 User acceptance
95
 Hardware and Software Issues
New Hardware and
Existing Platform System Software
1. Lower costs 1. Some software components
will only run on new platform
2. Information system staff is
familiar with operation and 2. Developing system for new
platform gives organization
maintenance
opportunity to upgrade
3. Increased odds of technology holdings
successfully integrating 3. New requirements may allow
system with existing organization to radically
applications change its computing
4. No added costs of converting operations (From mainframe
old systems to new platform computing into client/server
structure)
or transferring data

96
 Issues to Consider in Generating
Alternatives
 Source alternatives
 In house development , outsourcing, Purchasing…
 Outsourcing
 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

 Hardware manufacturers
 Packaged software producers
 Custom software producers…… 97
98
Criteria for Choosing Off-the-Shelf Software

 Cost
 In-house versus purchased
 Functionality
 Mandatory, essential and desired features
 Vendor Support
 Installation
 Training
 Technical Support
 Viability of Vendor
 Staying in business for very long period.

99
Criteria for Choosing
Off-the-Shelf Software
 Flexibility
 Ease of customization
 Documentation
 User documentation
 Technical documentation
 Response Time
 How long it takes the software package to respond to the
user’s requests.
 Ease of Installation
 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
 Figure 7-4 ranks system
requirements and constraints

102
103
 Hoosier Burger’s New Inventory
Control System
 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
 Figure 7-7 lists 3 alternatives
 Alternative A is a low-end proposal

 Alternative B is a midrange proposal

 Alternative C is a high-end proposal

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

C appears to be the best choice

110
Updating the Baseline Project
Plan (BPP)
 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)
 Section 1.0.B
 Contains recommendation for the chosen design strategy
 Section 2.0.A
 Contains descriptions of the competing strategies studied
during alternative generation and selection.
 Section 3.0.F
 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
 Re-assess management issues

112
 Updating the Baseline Project
Plan (BPP)
 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 cost-

benefit analysis for the inventory
project is shown in figure 7.10
 The numbers in the spreadsheet are
based in part on the constraints listed in
Figure 7.4 (Budget, time frame, and
training needs)

114
Hoosier Burger
Economic Feasibility Analysis
Inventory Control System
figure 7.10
Year of Project
Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 TOTAL
Net economic benefit $0 $30,000 $30,000 $30,000 $30,000 $30,000
Discount rate (12%) 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 $108,143

One-time COSTS (100,000)

Recurring Costs $0 ($2,000) ($2,000) ($2,000) ($2,000) ($2,000)

Discount rate (12%) 1.0000 0.8929 0.7972 0.7118 0.6355 0.5674
PV of Recurring Costs 0 ($1,786) ($1,594) ($1,424) ($1,271) ($1,135)

NPV of all COSTS ($100,000) ($101,786) ($103,380) ($104,804) ($106,075) ($107,210) ($107,210)

Overall NPV $934

Overall ROI - (overall

NPV / NPV of all 115
 Before and after BPP for Hoosier
Burger
 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
 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
Inventory Control System
figure 7.11
Year of Project
Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 TOTAL
Net economic benefit $0 $39,000 $39,000 $39,000 $39,000 $39,000
Discount rate (12%) 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 $140,586

One-time COSTS (115,000)

Recurring Costs $0 ($2,000) ($2,000) ($2,000) ($2,000) ($2,000)

Discount rate (12%) 1.0000 0.8929 0.7972 0.7118 0.6355 0.5674
PV of Recurring Costs 0 ($1,786) ($1,594) ($1,424) ($1,271) ($1,135)

NPV of all COSTS ($115,000) ($116,786) ($118,380) ($119,804) ($121,075) ($122,210) ($122,210)

Overall NPV $18,377

Overall ROI - (overall

NPV / NPV of all costs) 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.
 Detail revised statements of economic
analysis worksheet shown in table 7-5.

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