Case Study : System-Level Design of a Pepsi Vending Machine

This project uses systems engineering principles for the system-level development and design of Pepsi soda vending machine. We apply UML to the visual modeling of the system functionality and structure.

TABLE OF CONTENTS

  1. Problem Statement
    Purpose : Describe problem.
    Topics : Problem statement and approach.

  2. Goals, Scenarios, and User Requirements
    Purpose : Create system requirements.
    Topics : Goals and scenarios for initial use case modeling; Initial use case modeling; Goals and scenarios for expanded use case modeling; Expanded use case modeling; Organization of use cases; Generation of requirements.

  3. Simplified Models of System Behavior
    Purpose : Describe system behavior with activity/statechart diagrams
    Topics : High-level description of behavior; lower-level descriptions of behavior.

  4. Simplified Models of System Structure
    Purpose : Use class diagrams to describe the system structure.
    Topics : Simplified and detailed descriptions of the system struture.

  5. Creating the Logical Design
    Purpose : Map models of system behavior onto system structure.
    Topics : Use case/component task interaction matrix; Traceability.

  6. Evaluation and Ranking of System-Level Design Alternatives
    Purpose : Preliminary evaluation/ranking of system alternatives.
    Topics : Measures of effectiveness; Trade-off analysis via analytical hierarchy process (AHP).

  7. Conclusions and Future Work

  8. References and Web Resources


Problem Statement

Each day millions of coins and bills are poured into coin-operated devices. Automatic merchandising is one of today's fastest growing industries. Every day nearly 7 out of 10 people will get some product from the devices. Vending machine, coin-operated, has the greatest diversification of vending such like snack machine, Coke vending machine, snack and soda combination vending machines, bulk candy vending machines, and other specialty vending machines, medical vending, cigarette vending, phone card machines, even disposable panty vending machine. [Vending Machine]

The purpose of this project is to demonstrate systems engineering processes concerned with the step-by-step system development of Pepsi soda vending machine system, from identification of system requirements through to specification of all components and sub-systems to be designed.  We will examine Pepsi soda vending machine through system-level development and design along with UML and, further, explore alternative system design whose objectives vary through the design space bounded by constraints

This case study will evolve as follows:

  1. We will develop the requirements for the soda vending machine by using a use-case development with goals and scenarios elicitation.  The key steps involve identification of: (1) the actors and system boundaries, (2) the use cases, (3) information flows between the actors and the use cases, and (3) potential dependencies among the use cases.

  2. We will develop system hierarchies for this problem, and indicate how they will communicate.

  3. We will develop state chart diagrams for the vending machine system behavior.

  4. We will develop logical design of the vending machine by mapping the system behavior model onto the system structure.
  5. We will conduct a trade-off analysis for design options versus measures of effectiveness at the logical state of design.

Approach

The systems engineering approach is used in order to determine system structure and system behavior from user/system requirements.  Once they are determined, the system logical design is obtained.


Goals, Scenarios, and User Requirements

Goals and Scenarios for Initial Use Case Modeling

Elicitation of goals and scenarios are very important phase in designing the vending machine system.  This is the very first place where system requirements are generated.  Once the elicitation of goals and scenarios are done, the following use case modeling is performed.  This will help identify systems requirements for the vending machine.

Goal 1. The Soda Vending Machine must allow a customer buy a soda.

Scenario 1.1. When a customer feels thirsty, a customer goes to a soda vending machine to get a soda with money.

Scenario 1.2. A customer checks the availability and the price of a soda he or she wants to buy.

Scenario 1.3. A customer inserts either $1 bill or coins.

Scenario 1.4. The soda vending machine will display the amount of money deposited.

Scenario 1.5. A customer makes a selection for a soda.

Scenario 1.6. A customer gets a soda from the soda vending machine.

Scenario 1.7. A customer will get the change if there is the difference.

Scenario 1.8. A customer leaves after he or she gets a soda.

Goal 2. The Soda Vending Machine must allow a supplier to restock sodas and change.

Scenario 2.1. With fixed period of time, a supplier goes to the soda vending machine to restock sodas and change.

Scenario 2.2. The supplier exposes the inside of the soda vending machine by unlocking the lock.

Scenario 2.3. The supplier restocks both sodas and change according to sales.

Scenario 2.4. The supplier secures the soda vending machine after restocking.

Goal 3. The Soda Vending Machine must allow a supplier to collect the accumulated money from the soda vending machine.

Scenario 3.1. With fixed period of time, a supplier goes to the soda vending machine to collect the accumulated money.

Scenario 3.2. The supplier exposes the inside of the soda vending machine by unlocking the lock.

Scenario 3.3. The supplier collects the accumulated money.

Scenario 3.4. The supplier secures the soda vending machine after collecting the money.

Initial Use Case Modeling

The Unified Modeling Language (UML) is a tool used to illustrate how systems work. It is be very useful in describing a system visually and diagramming components, interactions, and relationships.  The development of initial use case models is required to identify overall system requirements through elicitation of goals and scenarios.  In initial step, a use case describes a single goal and all possible scenarios that can happen in system usage.

The purpose of the initial use case modeling is to provide high-level framework and traceability for the system functionality, expected performance, and system requirements.  In this case study several use cases will be expanded to cover detailed functionality of the soda vending machine.

Identify Actors

In the initial use case of the soda vending machine the actors are as follows:

Actor
Role
Customer. A person who buys a soda from the soda vending machine.
Supplier. A person who a soda company hired to restock sodas and change to a soda vending machine with a contract. Also, the person collects the money accumulated in the soda vending machine.
Power Source. A soda vending machine will be connected to AC/DC power source of a building.
Soda. A product that is provided for a customer.
Money. The money that is needed to get soda by a customer, i.e., $1 bill or coins.
Change. Coins needed to return the difference after delivering the soda product. Also it is needed to restock by a supplier.

System Boundary

System boundary is about what things are inside the system and what are outside the system. It is defined by identifying the actors and the use cases. The system boundary of the soda vending machine is defined by the machine itself that has an interface which receives information from external system and delivers the proper outputs. A customer, a supplier, money, and power sources are all external systems.

Baseline (Textual) Initial Use Cases with Activity Diagrams

In this section baseline use cases are described and activity diagrams are presented to make up the initial use cases.

Use Case (1): Buy Soda.

Figure 1. Activity diagram for "Customer buys a Soda with Money."

Use Case 2: Restock Soda and Coins.

Figure 2. Activity diagram for "Supplier restocks Sodas and Change."

Use Case 3: Collect Money.

Figure 3. Activity diagram for "Supplier collects Money from Machine."

Initial Use Case Diagram

Figure 4. Initial Use Cases Diagram of Pepsi Soda Vending Machine

Expanded Use Case Modeling

Before developing detailed design, some of expanded use cases are needed to provide a level of specification consistent with design details that will appear in the initial logical and physical design.

Elicitation of Goals and Scenarios

Goal 1. The Soda Vending Machine must show its availability.

Scenario 1.1. When a customer presses a selection button for a soda before he or she inserts money, the soda vending machine shows the price of the soda he or she wants to buy.

Scenario 1.2. If any soda selected is out of stock, the soda vending machine displays “Sold Out” message.

Goal 2. The Soda Vending Machine must provide a cool soda.

Scenario 2.1. At power on, the soda vending machine will make sodas cool automatically.

Goal 3. The machine must allow a customer to deposit money.

Scenario 3.1. A customer inserts money to the bill or coin acceptor.

Scenario 3.2. If the money inserted can be scanned successfully, the soda vending machine will accept the money.

Scenario 3.3. If the money inserted can not be scanned successfully, the soda vending machine will reject the money.

Scenario 3.4. If a customer changes his mind not to buy a soda, he or she will press “Return” button at any time to get the money deposited back.

Goal 4. The machine must allow a customer to deposit $1 bill.

Scenario 4.1. When the bill receiver is operating normally, it flashes to a customer.

Scenario 4.2. If the bill receiver is not working, it will not flash.

Scenario 4.3. When the bill receiver is not operating, it will automatically reject the $ 1 bill if a customer tries to insert.

Scenario 4.4. A customer inserts $1 bill to the bill receiver.

Scenario 4.5. If the $1 bill inserted can be scanned successfully, the bill receiver will accept the money.

Scenario 4.6. If the money inserted cannot be scanned successfully, the bill receiver will reject the money.

Goal 5. The machine must allow a customer to deposit coins.

Scenario 5.1. If the soda vending machine does not have enough change, it will show a signal, “Use Exact Change.”

Scenario 5.2. A customer inserts coins to the coin receiver.

Scenario 5.3. The coin receiver will accept only nickel, dime, and quarter.

Scenario 5.5. If the coins inserted can be scanned successfully, the coin receiver will accept the coins.

Scenario 5.6. If the coins inserted can not be scanned successfully, the coins receiver will reject the coins.

Goal 6. The machine must allow a customer to make a selection for the soda he or she wants to buy.

Scenario 6.1. A customer presses the selection button for the soda he or she wants to buy.

Scenario 6.2. If the soda selected is sold out, the soda vending machine will display “Sold Out” message.

Goal 7. The Soda Vending Machine must deliver a soda product through the dispenser window.

Scenario 7.1. After the selections, the soda vending machine will deliver a soda product.

Scenario 7.2. After the delivery, a customer will pick up the soda product through the dispenser.

Goal 8. The Soda Vending Machine must return the change if there is any difference through the change window.

Scenario 8.1. After the selections, the money is stored into the money repository.

Scenario 8.2. If there is any difference, the soda vending machine will return the change.

Scenario 8.3. A customer picks up the change through the change window.

Goal 9. The Soda Vending Machine must allow a supplier to restock sodas and change.

Scenario 9.1. A supplier unlocks the soda vending machine.

Scenario 9.2. A supplier pulls open the front of the soda vending machine.

Scenario 9.3. A supplier checks the current amount of the stock and change.

Scenario 9.4. If there is need to restock sodas and change, a supplier restocks sodas and change.

Goal 10. The Soda Vending Machine must allow a supplier to secure the front of the soda vending machine.

Scenario 10.1. After restocking, a supplier closes the front of the soda vending machine.

Scenario 10.2. A supplier secures the soda vending machine.

Scenario 10.3. A supplier leaves.

Expanded Use Case Modeling

Baseline (Textual) Use Cases with Activity Diagrams

In this section baseline use cases are described and activity diagrams are presented to make up the expanded use cases.

Use Case 1: Check Availability and Price of a Soda.

Figure 5. Activity Diagram for "Check Availability and Price of a Soda."

Use Case 2: Decide Type of Payment.

Figure 6. Activity Diagram for "Decide type of Payment."

Use Case 3: Use $1 Bill.

Figure 7. Activity Diagram for "Use $1 Bill."

Use Case 4: Use Coins.

Figure 8. Activity Diagram for "Use coins."

Use Case 5: Make a Selection for a Soda.

Figure 9. Activity Diagram for "Make a Selection for a Soda."

Use Case 6: Get Soda.

Figure 10. Activity Diagram for "Get Soda."

Use Case 7: Get Change.

Figure 11. Activity Diagram for "Get Change."

Use Case 8: Expose Inside of the Machine.

Figure 12. Activity Diagram for "Expose Inside of the Machine."

Use Case 9: Secure the Machine.

Figure 13. Activity Diagram for "Secure the Machine."

Expanded Use Case Diagram

The expanded use case diagram is as follows:

Figure 14. Expanded Use Cases Diagram of Pepsi Soda Vending Machine

Organization of Use Cases

At this point the use cases for the soda vending machine system are identified and defined. It is important from system behavior modeling perspective to organize the use cases first so that we can get a very high level relationship between use cases.

Figure 15. Organized Use Case Diagram

Generation of System Requirements

The development of both initial and expanded use case models was required to identify system requirements through elicitation of goals and scenarios.

The requirements for the Pepsi soda vending machine are as follows:

1. Performance Requirements

1.1. The soda vending machine shall dispense the right soda for a selection.

1.2. The soda vending machine shall return the right change.

1.3. The soda vending machine shall scan both $1 bill and coins.

1.4. The soda vending machine shall return exact amount of money if a customer presses a return button at any time.

2. Human Factors Requirements

2.1. The selection buttons shall be placed at distance where two adjacent selection buttons cannot to be pressed by one finger.

2.2. The change dispense window shall prevent coins from coming out of the window.

2.3. The dispenser of the soda vending machine shall be located within arm’s reach.

2.4. The soda dispense window shall keep a soda from coming out of the window.

2.5. The bill or coin acceptor shall be placed within arm’s reach.

2.6. The soda vending machine shall have rack for restocking soda.

2.7. The soda vending machine shall have rack for restocking coins.

3. User Interface Requirements

3.1. After money is deposited, the amount of money shall be displayed on display window.

3.2. When a selection button for a soda is pressed, the soda vending machine shall display either the price of the soda selected or "Sold Out" message on display window.

3.3. After a soda is dispensed, the difference shall be displayed on display window.

3.4. The bill acceptor of the soda vending machine shall blink if it is working.

3.5. The selection buttons shall show the product information of a soda.

3.6. The information of available coin that a customer can use shall be presented near the coin acceptor on the front of the soda vending machine.

3.7. The information that a customer can use only $1bill shall be presented near the bill acceptor on the front of the soda vending machine.

3.8. The soda vending machine shall have a set of selection buttons for soda.

4. Functional Requirements

4.1. The soda vending machine shall show the price of a soda selected when a customer pushes a selection button.

4.2. If the soda vending machine does not have a soda for selection, it shall display "Sold Out" message when a customer presses a selection button.

4.3. If the soda vending machine has less than 35 cents of change, it shall display "Use Exact Change" message.

4.4. The soda vending machine shall scan $1 bill with sensor.

4.5. The soda vending machine shall scan only nickel, dime, and quarter with sensor.

4.6. The soda vending machine shall reject both $1 bill and coins if the scanned data is different from the default data.

4.7. The soda vending machine shall memorize the scanned data of money.

4.8. The soda vending machine shall show the amount of money deposited.

4.8. The soda vending machine shall show the amount of money deposited. 4.9 The soda vending machine shall calculate the difference if the amount of money deposited is greater than the price data of a soda.

4.10. The soda vending machine shall show the remaining difference if the amount of money deposited is greater than the price data of a soda.

4.11. The soda vending machine shall store the money deposited after selection is made.

4.12. The soda vending machine shall return the difference if the amount of money deposited is greater than the price data of a soda.

4.13. The soda vending machine shall make sodas in stock cool.

4.14. The bill acceptor of the soda vending machine shall blink a light to show that it is working.

4.15. The soda vending machine shall not accept money any longer after the amount of money deposited excesses $1.

4.16. The bill and coin acceptor shall reject money if it fails to scan.

4.17. The soda vending machine shall be capable of checking the remaining stock of soda.

5. Security Requirements

5.1. The soda vending machine shall be unlocked only a supplier.

5.2. The soda vending machine shall be secured only by a supplier.

5.3. The soda vending machine shall not be broken by vandal.

5.4. The money storage box shall have a different security device.


Simplified Models of System Behavior

We use statechart diagram to show the system behavior. First, high level statechart diagram is given to show the overall system behavior, and then detailed statechart diagrams are used to show more specific system behavior.

Behavior (Availability Displayed State)

Figure 16. Statechart diagram for "Overall System Behavior."

Detailed System Behavior (Availability Displayed State)

Figure 17. Activity diagram for "Availability Displayed State."

Detailed System Behavior (Ready State)

Figure 18. Activity diagram for "Ready State."

Detailed System Behavior (Collected/Restocked State)

Figure 19. Activity diagram for "Collected/Restocked State."

Detailed System Behavior (Deposited State)

Figure 20. Activity diagram for "Deposited State."

Detailed System Behavior (Dispensed State)

Figure 21. Activity diagram for "Dispensed State."

Detailed System Behavior (Selected State)

Figure 21. Activity diagram for "Selected State."


Simplified Models of System Structure

Here are the key components and subsystems that are needed for the system structure are identified.

Component Definition

  1. Power System. Provides power to the mechanical and electrical systems.

  2. User Interface System. Provides communication tools (i.e., selection button, return button, display window, etc.) between a customer and the soda vending machine.

  3. Coin/Bill Processing System. Provide function of accepting, scanning, counting, and sorting coins and $1 bill. It also provide storage function.

  4. Main Processor. Comprised of memory, processing unit, and control unit which cover all main function of the vending machine.

  5. Soda Dispense System. Through this system, soda is dispensed.

  6. Security System. Provide access to supplier.

  7. Cooling System. Makes the machine to provide cool soda.

High-Level System Structure

Figure 22. Simplified Model of System Structure.

Low-Level System Structure

Figure 23. Simplified Model of System Structure.


Creating the Logical Design

This section describes the logical design phase of Pepsi soda vending machine system.  At this phase, high-level decisions about component usage and integration, based on the conceptual design, are made.  Use cases are used to construct a logical model of the vending machine.  At the close of this process, a logical design will have been developed, which is the basis for the physical design phase of Pepsi soda vending machine.

Figure 24. Schematic of Logical Design.

The goal of the logical phase is to convert the functions that were defined in system behavior model into an abstract model that identifies the cooperating logical components that support. The resulting logical design does not identify specific technologies. Instead, the objective of this phase is to analyze and understand the functionality before making any technology commitments.

The things needed in the creation of a logical design are the objects (the components) that will provide the required functionality, the behaviors, and relationships that each object (component) has.

Use Case/Component Task Interaction Matrix

The following matrix provides traceability from use cases to system components that implement these requirements. It shows why each system-level component is required.

Use Cases

 

 

Requirement 

Buy Soda

Restock Soda & Change

Collect Money

Secure the Machine

Expose Inside of the Machine

Check Availability & Price of Soda

Decide Type of Payment

Make Selection for a Soda

Get Soda

Get Change

Use $1 Bill

Use Coins

Power System

X

X

X

X

X

X

X

X

 

 

User Interface System

X

X

X

X

X

X

 

 

 

 

Coin/Bill Processing System

 

X

X

X

 

X

X

X

 

 

Main Processor

X

X

X

X

X

X

X

X

 

 

Soda Dispense System

X

 

 

X

X

 

X

 

 

 

Security System

 

 

 

 

 

 

X

X

X

X

Cooling System

 

 

 

 

X

 

 

 

 

 

Traceability

The following traceability matrix shows how use cases trace to groups of requirements and how individual requirements have been taken into account in the system-level design.

Use Cases

 

 

Requirement

Buy Soda

Restock Soda & Change

Collect Money

Secure the Machine

Expose Inside of the Machine

Check Availability & Price of Soda

Decide Type of Payment

Make Selection for a Soda

Get Soda

Get Change

Use $1 Bill

Use Coins

Performance

1.1

 

 

 

X

X

 

 

 

 

 

1.2

 

 

 

 

X

X

 

 

 

 

1.3

 

 

 

 

 

 

 

 

 

 

1.4

 

X

X

X

 

X

 

 

 

 

Human Factors

2.1

X

 

 

X

 

 

 

 

 

 

2.2

 

 

 

 

 

X

 

 

 

 

2.3

 

 

 

 

X

 

 

 

 

 

2.4

 

 

 

 

X

 

 

 

 

 

2.5

 

X

X

 

 

 

 

 

 

 

2.6

 

 

 

 

 

 

X

 

 

 

2.7

 

 

 

 

 

 

X

X

 

 

User Interface

3.1

 

X

X

 

 

 

 

 

 

 

3.2

X

 

 

X

 

 

 

 

 

 

3.3

 

 

 

X

 

X

 

 

 

 

3.4

 

X

 

 

 

 

 

 

 

 

3.5

X

 

 

X

 

 

 

 

 

 

3.6

 

 

X

 

 

 

 

 

 

 

3.7

 

X

 

 

 

 

 

 

 

 

3.8

X

 

 

X

 

 

 

 

 

 

Functional

4.1

X

 

 

X

 

 

 

 

 

 

4.2

X

 

 

X

 

 

 

 

 

 

4.3

 

 

X

 

 

 

 

 

 

 

4.4

 

X

 

 

 

 

 

 

 

 

4.5

 

 

X

 

 

 

 

 

 

 

4.6

 

X

X

 

 

 

 

 

 

 

4.7

 

X

X

X

X

X

 

 

 

 

4.8

 

X

X

X

X

X

 

 

 

 

4.9

 

 

 

X

X

 

 

 

 

 

4.10

 

 

 

X

X

 

 

 

 

 

4.11

 

 

 

X

 

 

 

 

 

 

4.12

 

 

 

X

X

X

 

 

 

 

4.13

 

 

 

 

X

 

 

 

 

 

4.14

 

X

 

 

 

 

 

 

 

 

4.15

 

X

X

 

 

X

 

 

 

 

4.16

 

X

X

 

 

X

 

 

 

 

4.17

X

 

 

X

 

 

X

 

 

 

Security

5.1

 

 

 

 

 

 

 

 

 

X

5.2

 

 

 

 

 

 

 

 

X

 

5.3

 

 

 

 

 

 

 

 

X

 

5.4

 

 

 

 

 

 

 

X

 

 


Measures of Effectiveness

Since Soda Vending Machine is a profit-making tool of a supplier, the design strategy is to include the system’s functionality features that may yield high revenue with low cost. Thus the measurements of system effectiveness are mainly related to two categories, which are “preference” of the consumer and/or supplier, and “cost”.

Decision Criteria

Followings are possible contributions to the “preference”:

Followings are sub-categories of Cost

To enable consistent and rational decision making, we will use pair-wise comparison method to evaluate the above subjective and non-quantifiable criteria.


Tradeoff Analysis

For the case using pair-wise comparison method, a good number of alternatives to generate are three because three alternatives can neatly represent both ends and the middle of a continuum or spectrum of potential solutions. One alternative represents the low end of the spectrum. Low-end solutions are the most conservative in terms of the effort, cost, and technology involved in developing a system. This strategy provides nothing but all the required functionality.

Another alternative represents the high end of the spectrum. High-end alternatives go beyond simply providing minimum required functionality and focus instead on systems that contain many extra features it may be desired. Functionality, not cost, is the primary focus of high-end alternatives. A high-end alternative will provide some desired features using advanced technologies, which often allow the system to expand to meet future requirements. Finally the third alternative lies between the extremes of the low-end and high-end systems. Such alternatives combine the frugality of low-end alternatives with the focus on functionality of high-end alternatives. Midrange alternatives represent compromise solutions. There are certainly other possible solutions that exist outside of these three alternatives. Defining the bottom, middle, and top possibilities allows drawing bounds around what can be reasonably done.

Our three Design alternatives are as follows:

Alternatives

Design Options

Alternative A (Low end)

Accept coins only (No Bill Acceptor)

Alternative B (Midrange)

Accept coins and bill

Alternative C (High end)

Accept coins, bill and credit card

Audio direction/feedback

Integration with web system

The analytic hierarchy process (AHP) is a good way to display and compare the design alternatives with non-quantifiable multi-criteria, which is used to arrive at a ratio-scale cardinal ranking of alternatives for multi-attribute decision problems.  AHP is especially suitable for complex decisions which involve the comparison of decision elements which are difficult to quantify. It is based on the assumption that when faced with a complex decision the natural human reaction is to cluster the decision elements according to their common characteristics. It involves building a hierarchy (Ranking) of decision elements and then making comparisons between each possible pair in each cluster (as a matrix). This gives a weighting for each element within a cluster (or level of the hierarchy) and also a consistency ratio (useful for checking the consistency of the data).

The principle of the AHP relies on the pairwise comparison. This comparison is carried out using a scale from 1 to 9 as follows:

Scale Interpretation
1 Equally preferred
2 Equally to moderately preferred
3 Moderately preferred
4 Moderately to Strongly preferred
5 Strongly preferred
6 Strongly to Very Strongly preferred
7 Very Strongly preferred
8 Very to Extremely Strongly preferred
9 Extremely preferred

It is necessary to know if one has been consistent in one's pairwise comparisons in order to accept the result of this process.  The parameter that is used to determine if an acceptable selection has been made is the Consistency Ratio.

Pairwise comparison of Decision Criteria

The results of the pairwise comparison for decision criteria are shown in the following table. Also, confidence ratio (CR) is calculated.

 

Flexibility

Ease-of-Use

Reliability

Tracking

Fixed Cost

Variable Cost

Weight

Flexibility

1

5

4

5

2

3

0.38

Ease-of-Use

1/5

1

1/2

1

1/4

1/3

0.06

Reliability

1/4

2

1

2

1/3

1/2

0.10

Tracking

1/5

1

1/2

1

1/4

1/3

0.06

Fixed Cost

1/2

4

3

4

1

2

0.25

Variable Cost

1/3

3

2

3

1/2

1

0.16

 

2.48

16.00

11.00

16.00

4.33

7.17

1.00

Confidence Ratio (CR) = 0.0130

Comparing Alternatives for each Criterion

We now compare the three alternatives with respect to each of the decision criteria.  The results of the comparison of alternatives for each criterion are shown in the following table.  Also, confidence ratio (CR) for each criterion is calculated.

Flexibility

Alt. A (Low-End)

Alt. B (Mid Range)

Alt. C (High-End)

Weight

Alt. A (Low-End)

1

1/7

1/8

0.06

Alt. B (Mid Range)

7

1

1/2

0.35

Alt. C (High-End)

8

2

1

0.58

 

16.00

3.14

1.63

1.00

Confidence Ratio (CR) = 0.030

Ease-of-Use

Alt. A (Low-End)

Alt. B (Mid Range)

Alt. C (High-End)

Weight

Alt. A (Low-End)

1

1

1/2

0.25

Alt. B (Mid Range)

1

1

1/2

0.25

Alt. C (High-End)

2

2

1

0.50

 

4.00

4.00

2.00

1.00

Confidence Ratio (CR) = 0.000

Reliability

Alt. A (Low-End)

Alt. B (Mid Range)

Alt. C (High-End)

Weight

Alt. A (Low-End)

1

2

3

0.52

Alt. B (Mid Range)

1/2

1

3

0.33

Alt. C (High-End)

1/3

1/3

1

0.14

 

1.83

3.33

7.00

1.00

Confidence Ratio (CR) = 0.046

Tracking

Alt. A (Low-End)

Alt. B (Mid Range)

Alt. C (High-End)

Weight

Alt. A (Low-End)

1

1

1/3

0.20

Alt. B (Mid Range)

1

1

1/3

0.20

Alt. C (High-End)

3

3

1

0.60

 

5.0

5.0

1.67

1.00

Confidence Ratio (CR) = 0.000

Fixed Cost

Alt. A (Low-End)

Alt. B (Mid Range)

Alt. C (High-End)

Weight

Alt. A (Low-End)

1

2

5

0.57

Alt. B (Mid Range)

1/2

1

4

0.33

Alt. C (High-End)

1/5

1/4

1

0.10

 

1.70

3.25

10.00

1.00

Confidence Ratio (CR) = 0.021

Variable Cost

Alt. A (Low-End)

Alt. B (Mid Range)

Alt. C (High-End)

Weight

Alt. A (Low-End)

1

2

6

0.58

Alt. B (Mid Range)

1/2

1

5

0.34

Alt. C (High-End)

1/6

1/5

1

0.08

 

1.67

3.20

12.00

1.00

Confidence Ratio (CR) = 0.025

Grand weight of the three alternatives is shown in the following table.

 

Flexibility

Ease-of-Use

Reliability

Tracking

Fixed Cost

Variable Cost

Weight

 

 

 

 

 

 

 

 

Alt. A (Low-End)

0.06

0.25

0.52

0.20

0.57

0.58

0.33

Alt. B (Mid Range)

0.35

0.25

0.33

0.20

0.33

0.34

0.33

Alt. C (High-End)

0.58

0.50

0.14

0.60

0.10

0.08

0.34

The table above shows the best of the three options having the highest value is alternative C.  However the differences among the numerical value of grand weights are merely small so we can conclude that there is no meaningful difference of priority among the three alternatives. 

Alternative A and B have same weight even though alternative B offers much higher flexibility with bill acceptor.  That is because alternative A has relatively more preference in the following three criteria: reliability and fixed and variable cost.

Advantages and Disadvantages of Ranking

The ranking approach to deriving criterion weights is attractive due to its simplicity. In practice, however, the number of criteria limits the practicality of using ranking. The larger the number of criteria the more difficult it is to arrive at a reliable ranking. One limit for the number of criteria, derived from psychometrics, is 7+-2. This means that on average humans are capable of discriminating, at the maximum, among 9 different entities (nine different importance levels that can be assigned ranks). This limitation can be overcome by using hierarchical ranking schemes. Another limitation of ranking is the lack of its theoretical foundations.

Advantages and Disadvantages of Ranking

Rating is easy to understand by using the analogy of distributing a fixed amount of money, on the priority basis, across a set of objectives represented by evaluation criteria. However, rating, similarly to ranking, lacks theoretical foundations and its practicality is limited to a small number of criteria. The approach may be misused if the DM does not pay attention to the definition of criteria and ranges of criterion values.

Advantages and Disadvantages of Pairwise Comparisons

Pairwise comparison, in contrast to ranking and rating, has a solid theoretical foundation based on ratio-scale judgments about pairs of criteria and the properties of reciprocal matrix of pairwise comparisons. The advantage of this technique is that information can be used from handbooks, regression output, or decision makers/experts can be asked to rank-order individual factors. The disadvantage of pairwise comparison is a large number of judgements that must be made when the number of criteria is large.


Conclusions and Future Work

  1. In this project, we have demonstrated system level development and design of Pepsi soda vending machine system along with systems engineering principles and techniques throughout the system development. We mainly focused on the generation of the vending machine system's requirements and the development of the logical design of the system.
  2. Due to lack of information related to the detailed technical specification and costs for the vending machine we did not include much detail in trade-off analysis. The trade-off analysis is based on analytic hierarch process showing that the best design option is high-end alternative with evolving high-tech features (i.e., credit card payment and web integrity).
  3. According to Pepsi Company, they are testing new vending machine technology that has advantages for both the customer and the supplier; For customer, they will have the ability to use credit cards to pay for their drinks, in addition to bills and coins, and for supplier, they will have better integrated function with the Pepsi bottler's web systems, allowing it to keep better track of what is being sold and when to visit the vending machine, and therefore do a more efficient job replenishing machines on a timely basis. We considered the design of this new vending machine as a high-end alternative in trade-off analysis. The result showed it got the best grand weight, but we did not deal its features in other design phases because its conceptual and technical information was not available in detail. Future work should include the most up-to-date technical features of vending machine and try to develop more advanced and cost-effective one.


References and Web Resources

  1. Mark A. Austin. Lecture Notes for ENSE 621/ENPM 641: Systems Engineering Principles. 2001.
  2. Bennett, S. et al., Schaum?s outlines UML. McGraw Hill. 2001
  3. Oestereich, B. Developing Software with UML: Object-Oriented Analysis and Design in Practice, Addison-Wesley. 1999.
  4. Evans, A. et al., UML 2000: The Unified Modeling Language: Advancing the standard. Springer, York, UK. 2000.
  5. Hoffer, J. et al., Modern systems analysis and design. Prentice-Hall, Upper Saddle River, NJ, 2002.
  6. See http://www.toshiba.com/taec/applications/vending_machine_lowend.shtml.
  7. See www.vendingoutlet.com.

Developed by Jeon, Kwan Yong and Chun, Duk-hi, May 2002.
Reformatted and slightly modified by Mark Austin, September 2002
Copyright © 2002, Jeon, Kwan Yong, Chun, Duk-hi, and Mark Austin. University of Maryland.