Draw Flow And Test Cases For Password Comparison Essay

On By In 1

Project: Fast Food Automated Ordering System

Students: Vimal Mayank and Deep Saraf
Faculty Advisors: Mark Austin and John Baras

TABLE OF CONTENTS

  1. Introduction
    Purpose : Define fast food automated ordering system.
    Topics : Problem statement; benefits of the system; purpose.
  2. Goals, Scenarios, and Use Cases
    Purpose : Develop use cases, scenarios and system requirements.
    Topics : Goals and Scenarios; initial use cases with activity diagrams.
  3. Generation of Requirements from Use Cases
    Purpose : Generate high-level requirements from use cases.
    Topics : High-level requirements; synthesis and breakdown of requirements; requirements traceability.
  4. Generation of Specifications
    Purpose : Generate low-level requirements
    Topics : Synthesis and Breakdown of Requirements
  5. High-Level System Modeling and Analysis
    Purpose : Create simplified models of behavior and structure.
    Topics : System structure diagram; functional flow block diagram; requirement traceability matrix.
  6. System-Level Design
    Purpose : Create the system-level design.
    Topics : Map chunks of behavior onto the system structure; sequence diagrams.
  7. Design Structure Matrix (DSM)
    Purpose : Applying DSM to system decomposition and Integration Problems .....
    Topics : Activity Based Design Structure Matrix
  8. Tradeoff Analysis
    Purpose : Create framework for trade-off analysis for selection of components in a small subsystem.
    Topics : Performance characteristics; decision variables; CPLEX Formulation of the problem; Result of the CPLEX runs; plot of non inferior solution in the objective space; analysis of pareto points of the system; final system design.
  9. Component - System Testing
    Purpose : Develop procedures of system test, verification and validation.
    Topics : Primary verification plan; verification traceability matrix; VSN's; coverage and completeness.
  10. References and Web Resources
  11. Appendices
    Purpose : Details of the CPLEX analysis.
    Topics : LP file for CPLEX run; Log file of the CPLEX runs.

Introduction

Problem Statement

This case study looks at the problem of setting up a fast food restaurant. The basic problem in the food service industry is that restaurants are not realizing efficiencies that would result from better applications of technology in their daily operations. Every fast food has counter where you can place your order and then make the payment. So every fast food needs an employee for taking the order and processing the payment. Labor rates are increasing every now and then and it is difficult to find employees in the middle of the highway, hence to solve this problem we plan to design a "Self Served Fast Food System."

This self-service fast food restaurant will be equipped with a user-friendly touch screen, a credit/debit card reader, and software for completing the process at the backend. For this system there will be a system administrator who will have the rights to enter the menu with their current prevailing prices. He/she can enter anytime in the system by a secured system password to change the menu contents by adding or deleting an item or changing its price.

Now when the customer enters the restaurant, he will place his order with the help of the touch screen using the intuitive graphical user interface, right from the selection of language till the payment confirmation. He will select from the food options according to his choice and the system will display the payment amount he has to make once he has finished with his order. He will have the option of paying the bill by cash, debit card or a credit card. The user will slide his card and the system will check for the validity of the card and the payment will be made. A receipt will be printed containing the order number and the order will be sent in the kitchen for processing.

Anticipated Benefits

  1. This will minimize the number of employees at the back of the counter.
  2. The system will help to reduce the cost of labor.
  3. The system will be less probable to make mistake, since it?s a machine.
  4. This will avoid long queues at the counter due to the speed of execution and number of optimum screens to accommodate the maximum throughput.
  5. The system will be available 24 hours for 365 days, because the machine is not going to take any sick or vacation leave.

Scope and Objectives

The purpose of this analysis is to demonstrate the extent to which high-level systems concept and UML notation/semantics can be used to describe the functionality of this system. This study lays out a framework for a new system to be developed and brought to the market for maximum use. The following issues, which are useful in performing a detailed analysis of the system, will be addressed in this study:

  1. What should the system do?
  2. What are the systems requirements?
  3. How does the system work?
  4. Can the system work?
  5. What objects should be chosen and each of the subsystems functionality?
  6. How should the object/subsystem interact?
  7. How to verify and validate the system?

System Framework and Boundary


Goals, Scenarios and Use Cases

Goals and Scenarios

Goal 1. The system has a user-friendly user interface.

  1. Scenario 1.1. A particular user of the system has no difficulty in reading the text on the display.
  2. Scenario 1.2. The system is navigable through intuition.
  3. Scenario 1.3. Menu choices are presented in form of buttons, which contain text as well as little pictures illustrating the choice for better understanding.

Goal 2. The system supports multi lingual capabilities.

  1. Scenario 2.1. User is not a native speaker of the common spoken language in the country.
  2. Scenario 2.2. System caters to English (universally accepted language for communication) and other native languages, which are commonly spoken in the country where the system is operative.

Goal 3. System takes order from the customer as per his/her choice.

  1. Scenario 3.1. User selects a combo deal (i.e. a combination of main food, drink and side dish).
  2. Scenario 3.2. User may want to make up his own order by selecting dishes.

Goal 4. The system calculates and displays the final bill based on the placed order.

  1. Scenario 4.1. System calculates final bill based on the quantity of the items multiplied by their unit price topped up by the applicable taxes if any.
  2. Scenario 4.2. User is given the option to either pay for the order or revise the order.

Goal 5. System handles the payment for the user-defined order.

  1. Scenario 5.1: User decides to pay cash and system asks user to enter cash in the slot.
  2. Scenario 5.2: System verifies the cash amount and gives refund if any after deducting the amount.
  3. Scenario 5.3: User decides to pay through credit/debit card. System informs user to swipe card through card reader.
  4. Scenario 5.4: The system verifies the card and charges the amount of the bill to the card. Asks user to sign the bill on the signing pad.
  5. Scenario 5.5. The system prints out receipt containing a token number, details of the order, bill and the payment method with a terminal message (Thank you visit again or Store address).
  6. Scenario 5.6: System communicates the order to the kitchen through the internal ordering system.

Goal 6. System offers the choice to change the menu items to the store manager.

  1. Scenario 6.1. Store manager decides to add / delete an item from the menu.
  2. Scenario 6.2. Store manager wants to put festive offers on some items because of which there is a change in the price of some of the items.
  3. Scenario 6.3. Store manager notices that some dishes are out of stock. Consequently he updates the menu so that those items are deleted temporarily deleted from the display presented to the user.

Goal 7. The system is resistant to active/rigorous handling.

  1. Scenario 7.1. The customer must be a minor or hacker who might want to get into the system to change it. It should provide security for these areas.
  2. Scenario 7.2. The system will be used by different users and might experience some rough hand every now and then.

Identify Actors

An actor is anything that interfaces with the system externally and participates in use case modeling. In our Self Served Fast Food System the actors would be:

  1. Customer. This actor is the principle customer who will order food and make the payment.
  2. Store Manager. This actor will hold the rights to change the menu and enter the system to make any changes.
  3. Internal Order System. This actor will read the order given by the customer and pass it to the food preparation person.
  4. Bank System. This actor serve as a backbone for doing the credit / debit card transaction.
  5. Cash Collector. This actor will accept the cash from the customer and gives back the change.
  6. Food Preparation Person. This person receives the order placed by the customer through internal order system.

System Boundary

The system boundary is defined by the elevator itself.

Initial Use Case Diagram

A use case describes a single goal and all the things that can happen as the user attempts to reach that goal. Although use cases are neither requirements nor functional specification, they imply requirements, objects and object interactions in the stories they tell. Use cases are textual description of the interaction between external actors and a system.

Our initial use case diagram has six actors and five use cases.

Figure 1. Initial Use Case Diagram for Serve Fast Food.

As you can see that the Customer places the order, which is read by the internal order system, and the order is then sent to the food preparation person for execution. In the mean time the customer makes the payment. If the payment is made in cash there is a cash collector actor or there is a bank system for credit/debit card processing and keeping the balance cash amount.

Baseline (Textual) Use Cases with Activity Diagrams

When the flow of events is linear, a textual description of behavior is often sufficient to capture the system behavior. Activities diagram provide a visual documenting sequence of task making up a single activity. They especially are useful for activities governed by conditional logic, and flow of event running concurrently. We describe the basic system functionality with textual use cases, and employ activity diagrams for a visual representation of the corresponding sequence of task or flow of information.

Use Case 1. Place Order

  • Primary Actor: Customer
    Description: Customer places an order from the available choices after indicating his language preference for the session.
    Pre-conditions: System is connected to a power source, display is turned on and system is configured to accept the inputs.
    Flow of Events:
    1. User selects his language preference for the session.
    2. User selects from the menu.
    3. User selects from the drinks menu
    4. User selects from the combo deals
    5. User confirms the order
    Alternative Flow of Events:
    1. User accidentally presses a wrong button and after realizing it he hits the backspace button.
    2. User enters a wrong order and wants to go back to the main menu.
    Post-condition: Order has been made that goes to the kitchen for processing.
    Assumption: User is familiar with how to enter values through mouse and has a general idea why the inputs are being provided and what is expected out of system.

Activity diagram for this use case is given as below:

Figure 2. Activity Diagram for Place Order.

Use Case 2. Make Payment

  • Primary Actors: customer, Credit/Debit system, cash collector.
    Description: The user is asked for the mode of payment. The payment is accepted in terms of credit/debit card or is collected by cash collector. And the customer is given a token with their order number.
    Pre-condition: The order has been confirmed and the total bill has been displayed on the screen to the customer. Costumer decides to go ahead with the order. Flow of Events:
    1. User enters the mode of payment. (Credit/Debit/Cash)
    2. User makes the payment in cash
    3. Cash collector collects the money and gives back the change if required.
    4. User makes the payment by credit/debit card.
    5. User receives a token number and final bill.
    Alternative Flow of Events:
    1. User selects the mode of payment.
    Post-condition: Customer waits for the order to be processed.
    Assumption: User is familiar with how the system works and what is expected out of system.

Activity diagram for this use case is given as below:

Figure 3. Activity Diagram for Payment Process Use Case

Use Case 3. Update Menu.

  • Primary Actor: Store Manager.
    Description: The menu might change according to the inventories or add/delete items from menu and deals. The prices of each item might change for the period of time.
    Pre-condition: An order menu with their respective price already exists in the system in some particular format.
    Flow of Events:
    1. The Store manager enters the system with some password.
    2. The Store manager makes the required changes.
    3. The Store manager saves the changes and logs out.
    Alternative Flow of Events:
    1. Some of the menu might not need any change.
    2. User might enter invalid password and need to go back.
    Post-condition: A menu list will be displayed when the user enters the system.
    Assumption: The Store manager is given the rights and privileges to enter the system and make the required changes.

Activity diagram for this use case is given below:

Figure 4. Activity diagram for Update Menu Use Case

Use Case 4. Monitor Inventory.

  • Primary Actor: Food preparation person, Store Manager Description: This use case triggers when an item goes out of stock.
    Pre-condition: None
    Flow of Events:
    1. Food preparation person/Store manager notices an item out of stock
    2. Updates the menu accordingly.
    Post-condition: A new and updated menu list will be displayed.
    Assumption: The Store manager is given the rights and privileges to enter the system and make the required changes.

Activity diagram for this use case is given below:

Figure 5. Activity Diagram for Monitor Inventory

Use Case 5. Read Order.

  • Primary Actor: Food preparation person, Internal Order system.
    Description: Internal order system reads the order once the customer confirms his order and then he communicates the order to the food preparation person. Pre-condition: User confirms the order.
    Flow of Events:
    1. Internal order system reads the order
    2. Communicates the order to the food preparation person
    Post-condition: The final order is being processed in the kitchen.
    Assumption: Food preparation person is available to take the order and know the sequence of processing the orders.

Activity diagram for this use case is given below:

Figure 6. Activity diagram for Read Order

Use Case Task Component Interaction

Figure 7. Use Case Task Component Interaction


Generation of Requirements from Use Cases

Having generated the baseline textual use cases and the scenarios for the current problem we can now generate the requirements for the Self Served Fast Food system. Requirements are derived from various goals and scenarios, use cases so it is important to trace back the source of requirement.

High-Level Requirements (ENSE 621 version)

These are the first draft of requirements written during the beginning of the semester when the system engineering principles were not very clear. These requirements are not quantified and are very ambiguous. They are not specific to any object or process and hence needs to be refined.

User Requirements

  1. User should be able to navigate the system without any difficulty.
  2. System supports native language of the country and other commonly spoken languages.
  3. User should be able to place order according to his choices
  4. User should be able to make payment using cash/credit/debit card.
  5. User should get a receipt and a token number after making the payment.

Sources: Goals 1,2 & 5, Scenario 1.1,3.1, & 5.4, Use Case 1 & 2.

Performance Requirements

  1. The system should be able to take any type of inputs, once the mouse is clicked on the respective button.
  2. The system should be able to take any amount of order and display it when finished.
  3. The system should be able to calculate the bill and prompt the user for the mode of payment and generate a receipt.
  4. The system should be able to pass on the order in the kitchen for processing.
  5. The system should be secured to restrict the number of people to enter the system to make changes in the menu and its items.
  6. The system should be sturdy for rough usage.
  7. System has a cash collector which gives refund up to 5 $ in coins.
  8. System should be able to communicate to the central database to verify the authenticity of the credit/debit card.
  9. System should allow Store manager to add/delete/alter system items.

Sources: Goals 5,6 & 7, Scenario 4.1 & 4.2, Use Case 2,3,4 & 5

User Interface Requirements

  1. The system must be a graphical user interface for easy use and understanding.
  2. The system must be able to prompt the user for the next step to be performed during the process of using the system.
  3. The system must display the bill and final order for confirmation.

Sources: Goal 1, Scenario 4.3 & 5.4, Use Case 1 & 4

Ergonomics Requirements

  1. The system interface layout must be self-explanatory
  2. Horizontal and vertical distances between two adjacent buttons should be at least 5 pixels for better visibility and accessibility.
  3. The mouse should be placed not below 3 feet above the ground.

Sources: Goal 1, Scenario 1.2 & 1.3, Use Case 1 & 4.

Requirements Traceability

Flowdown of Requirements from Use Cases/Scenarios

The detailed flowdown of requirements from use cases and scenarios is as follows (ENSE 621, version):

SOURCE
DESTINATION
Use Case
Scenario
Requirement No
Description
Place Order
1.2
User 1 Easy navigability
2.1, 2.2
User 2 Support of native language and others
1.3, 3.1, 3.2
User 3 User places order as per his choice
3.1, 3.2
Performance 1,2 Take any input and amount of order
4.1
Performance 3 Able to calculate bill, prompt for mode of payment and give receipt.
1.3, 1.1
User Interface 1 Supports GUI for easy use.
1.2
User Interface 2 Prompts user for next step
4.1
User Interface 3 Display bill and confirm order
1.1, 1.3
Ergonomics 1 Self explanatory system interface
1.3
Ergonomics 2 5 pixel distance b/w buttons
Make Payment
1.2
User 1 Easy navigability
5.1, 5.3
User 4 Make payment using cash/credit/debit cards.
5.5
User 5 Generation of receipt/token no.
4.1
Performance 3 Able to calculate bill, prompt for mode of payment and give receipt.
5.2
Performance 7 Equipped with cash refund device.
5.4
Performance 8 Ability to connect with bank central database.
1.2
User Interface 2 Prompts user for next step.
4.1
User Interface 3 Display bill and confirm order.
1.1 & 1.3
Ergonomics 1 Self explanatory system interface.
1.3
Ergonomics 2 5 pixel distance b/w buttons Update Menu.
7.1
Performance 5 Restricted access to change system.
6.1, 6.2 & 6.3
Performance 9 Ability to add /delete / alter menu items.
1.1 & 1.3
Ergonomics 1 Self explanatory system interface.
1.3
Ergonomics 2 5 pixel distance b/w buttons Monitor inventory.
6.1, 6.2 and 6.3
Performance 9 Ability to add /delete / alter menu items Read Order.
5.6
Performance 4 Communicate order to kitchen.

Traceability of Requirements to Use Cases / Scenarios

Traceability from requirements back to originating use cases/scenarios is as follows (ENSE 621 version):

SOURCE
DESTINATION
Requirement No
Description
Scenario
Use Case
User 1 Easy navigability
1.2
1,2
User 2 Support of native language & others.
2.1, 2.2
1
User 3 User places order as per his choice.
1.3, 3.1 & 3.2
1
User 4 Make payment using cash/credit/debit cards
5.1 & 5.3
2
User 5 Generation of receipt/token no.
5.5
2
Performance 1 Take any input.
3.1 & 3.2
1
Performance 2 Take any amount of order.
3.1 & 3.2
1
Performance 3 Able to calculate bill, prompt for mode of payment and give receipt.
4.1
1,2
Performance 4 Communicate order to kitchen.
5.6
5
Performance 5 Restricted access to change system.
7.1
3
Performance 6 Sturdy system for rough usage.
7.2
None
Performance 7 Equipped with cash refund device.
5.2
2
Performance 8 Ability to connect with bank central database.
5.4
2
Performance 9 Ability to add /delete / alter menu items.
6.1, 6.2 & 6.3
3,4
User Interface 1 Supports GUI for easy use.
1.1 & 1.3
1
User Interface 2 Prompts user for next step.
1.2
1,2
User Interface 3 Display bill and confirm order.
4.1
1,2
Ergonomics 1 Self explanatory system interface
1.1 & 1.3
1,2,3
Ergonomics 2 5 pixel distance b/w buttons.
1.3
1,2,3
Ergonomics 3 Vertical placing of mouse.
1.2
None

High-Level Requirements (ENSE 622 version)

Concept Requirement List (CRL) are the set of requirements which demonstrate the over all system, its needs and outputs. These are the set of requirements generally provided by the management to the designers. Following are the set of CRL for the fast-food ordering system that we plan to design and develop.

  1. System supports native language of the country and other commonly spoken languages.
  2. User should be able to place order according to his choices
  3. User should be able to make payment using cash / credit / debit card.
  4. User should get a receipt and a token number after making the payment.
  5. The system should be able to take any type of inputs, once he touches the respective button.
  6. The system should be able to calculate the bill and prompt the user for the mode of payment and generate a receipt.
  7. The system should be able to pass on the order in the kitchen for processing.
  8. The system should be secured to restrict the number of people to enter the system to make changes in the menu and its items.
  9. The system should be sturdy for rough usage.
  10. System has a cash return mechanism which gives refund up to 5 $ in coins.
  11. System should be able to communicate to the central database to verify the authenticity of the credit/debit card.
  12. System should allow Store manager to add/delete/alter system items.
  13. The system must be a graphical user interface for easy use and understanding.
  14. The system must be able to prompt the user for the next step to be performed during the process of using the system.

Generation of Specifications

Synthesis and Breakdown of Requirements

Detailed model of Requirements Flowdown : System-level requirements are assigned to elements in the system architecture, which in turn, flow down to subsystem elements. Appropriate test requirements are generated at each level of the system development. Starting ate the sub-system level, other stakeholder requirements are taken into account, perhaps because the subsystem elements will be used across a product line. Designers working on the sub-system elements provide feedback to the system-level designers.

We divide our system at different levels of requirements, to make sure that all the requirement specifications are covered and study the flowdown of requirements. You will notice that there are the requirements at the system level, which are very similar to the higher level requirements and then we study the requirements at the Sub-System level and component level. Later, in the project we will see how these requirements are tested and verified at there levels and then we integrate them to test the whole system.

Figure 8. Detailed model of Requirement Flowdown

1.0 System Level Requirements

System-level requirements are assigned to elements in the system architecture, which in turn, flow down to subsystem elements. Appropriate test requirements are generated at each level of the system development.

1.1. Restaurant will be open for 16 hours and will operate in four shifts as Morning (730 AM -1130 AM), Afternoon (1130 AM -330 PM), Evening (330 PM - 730 PM) and Night (730 PM -1130 PM).

1.2. System should be able to serve a throughput of 50, 125, 50, 75 customers per hour during these four shifts respectively.

1.3. Cooks, cleaners and assemblers will be the type of employees working the restaurant.

1.4. Cook will be paid at the rate of $5 per hour for the duration of their work.

1.5. Assemblers will be paid at the rate of $4.75 per hour for the duration of their work.

1.6. Cleaner will be paid at the rate of $4.5 per hour for the duration of their work.

1.7. Customer will leave without ordering if he sees 6 or more people in the line waiting to be served thereby causing a loss in revenue.

2.0 Sub-system Level Requirements

Starting at the sub-system level, other stakeholder requirements are taken into account, perhaps because the subsystem elements will be used across a product line. Designers working on the sub-system elements provide feedback to the system-level designers.

(a) 2.1 Ordering and Processing System

2.1.1. The system will provide queue management by passing orders sequentially to kitchen (FIFO) by assigning order numbers to them.

2.1.2. Customer should be able to order item either by name or by number (for combo deals).

2.1.3. System will support native and other commonly spoken language in the country.

2.1.4. An average order takes about 1 minute to complete with a variance of 10 seconds.

2.1.5. Customer takes 2 minutes on an average to complete and ordering process.

2.1.6. System will be equipped with a standard QWERTY keyboard for taking inputs.

(b) 2.2 Payment System

2.2.1. This Order number will be printed on the bill that customer receives.

2.2.2. System shall be able to accept cash and coins.

2.2.3. System should be able to accept debit / credit cards.

2.2.4. System will accept only $1, 5, 10, 20 bills and nickel, dime, quarter denomination of coins.

2.2.5. System will reject pennies & $50, $100 bills.

2.2.6. System won't allow putting in $1 coin.

2.2.7 Cash return will return change only in coins (up to $5 maximum)

3.0 Component Level Requirements

(a) 3.1 Touch Screen

3.1.1. Touch screen should be able to take inputs from users when they apply a light pressure (x lb) from their fingers corresponding to an item.

3.1.2. Touch screen should be able to withstand rough use i.e. it will be scratch proof (i.e., will be resistant to nail scratching) and will not malfunction if a pressure of (x+5) lb is applied to the screen.

3.1.3. Touch screen will colored for visual appeal and will support at least 256 colors.

3.1.4. Resolution of the screen will be at least 640X480 pixels.

3.1.5. Touch screen will be at least 10 in size.

3.1.6. Touch screen should be able to display at least 15 rows and 60 columns of text when the font size of the text is 10.

(b) 3.2 Card Acceptor/Reader

3.2.1. System will be equipped with a card reader with built it keypad (containing all digits and special function keys corresponding to CANCEL, OK, # etc).

3.2.2. This card reader should be able to read the card information if swiped at a speed > 1 m/s.

3.2.3. Card reader will have a vertical slot on the right hand side of the keypad.

(c) 3.3. Display

3.3.1. System will display all the menu items in icons/graphics format for selecting.

3.3.2. System will prompt the user for mode of payment.

3.3.3. Order will be transferred to the kitchen touch screen instantaneously once the user does the payment.

3.3.4. System will display the order sequentially on the kitchen screen with a forward and back button at the bottom.

3.3.5. Touching an order on the kitchen screen will prompt the system that the order has been delivered and the screen will be rolled forward.

3.3.6. Any error message during such a process will be reported to the user on the touch screen informing him to take any further action.

3.3.7. There will be a high contrast between the foreground and the background of the display for easy reading capabilities.

3.3.8. Throughout the ordering process all the text displayed on the screen will be either greater than 10 or less than 18 font size so that all users (young, adult, old) can read it.

(d) 3.4. Modem

3.4.1. Modem should be able to complete a transaction (dialing, sending information, receiving information) in 15 seconds or less at all times.

3.4.2. Once connected to the bank system will supply the card information to the bank database, will query the card validity and will supply the amount to be charged to the card.

(e) 3.5 Software

3.5.1. System will be secured to grant access rights only to the system administrator. For this a login ID and a password will be assigned which could be changed. Password won't be visible to onlookers while typing for increased security.

3.5.2. System will deny access to change the contents if the login/password both are incorrect by providing an error message


System Modeling and Analysis

System Behavior

System behavior shows what a system does or appears to do, Its represented graphically by a model which integrates the functional model and the inputs and outputs. The figures below shows two versions of two different functional models. Our first model is the Order System and the second model show the payment activity. The 621 version is the basic version of the model with most of function not very well defined which you will notice when you view the 622 version of the Activities.

FFBD's for Order and Payment (ENSE 621 version)

Figure 9. FFBD's for Order and Payment (ENSE 621 Version)

FFBD for System Updates (ENSE 621 version)

Figure 10. FFBD for System Updates.

FFBD for Pay Bill (ENSE 622 version)

This is a more detailed functional flow block diagram of the sequence of functions that take place in the Order and Payment processes.

Figure 11. FFBD for Pay Bill (ENSE 622 version)

FFBD for System Administrator (ENSE 622 version)

Figure 12. FFBD for System Administrator (ENSE 622 version)

Statechart Diagram

A statechart diagram (STD) describes the possible states of a single class and the events that cause state transitions. They are useful for showing the life cycle of the class. Statechart and activity diagrams both describe state transitions and share many of the same elements. An activity diagram is most effective for describing processes that involve more than one object. The following diagram shows the statechart diagram of our system.

Figure 13. Statechart diagram ....

System Structure

The model of system structure has evolved through two versions.

Preliminary System Structure (ENSE 621 version)

In the preliminary implementation (ENSE 621), the "automated ordering system" was partitioned into elements for input, menu, payment, system administration and output.

Figure 14. System Structure (ENSE 621 Version).

Notice that the system structure does not include the environment within which the ordering system works and also some of the objects that are considered at lower level are not objects of the system, instead they are attributes.

Revised System Structure (ENSE 622 version)

Version two of the system structure has a larger scope. The highest-level of system structure, "fast food system" is a composition of three systems -- staff, kitchen and automated food ordering system.

Figure 15. Revised System Structure (ENSE 622 version)

Attributes and functions are assigned to classes in the system hierarchy, as shown in Figure 15.


System-Level Design

We now map chunks of behavior onto the system structure and show the flow of messages/data among system components with sequence diagrams. As you can see in the diagram below the system structure have been revised again to trace all the functions of the system behavior. We have also added the attributes related to each object in the system structure.

Assigning Fragments of Behavior to the Object Structure

System-Level Design (ENSE 622 version)

Figure 16. System Structure

Fragments of Behavior for the System-Level Design

Sequence diagram provides a graphical representation for how a task is accomplished by passing a sequence of messages among objects. These interactions define behavior as implemented by the fragments of the system structure.

Our system can be divided into two different sequence diagram as shown below:

Sequence Diagrams for Placing an Order (ENSE 621 version)

Figure 17. Sequence of Messages for Placing an Order

As seen in the diagram the customer enters the system by clicking begin button and selects his language choice. He then clicks on the menu button to see the menu items and then makes a selection. He then confirms his order by clicking on the confirm order button.

Sequence Diagrams for Making the Payment (ENSE 621 version)

Figure 18. Sequence of Message for Making the Payment

Customer has been prompted for the mode of payment. If he selects cash then he has to give cash to the cash collector and receive change, if any. He also receives a receipt from the cash collector. If the customer selects debit/credit card payment mode, he is asked again to select from debit or credit. If he selects debit card then he is asked a pin number or else he is asked to slide the card. After checking for the validity of the card the payment is made and the customer receives a receipt.

Traceability of Requirements to Attributes and Functions

System Level Requirements
Object
Attribute
Function
1.1. Restaurant will be open for 16 hours and will operate in four shifts as Morning (730 AM -1130 AM), Afternoon (1130 AM -330 PM), Evening (330 PM - 730 PM) and Night (730 PM -1130 PM). Fast Food System Time  
1.2. System should be able to serve a throughput of 50, 125, 50, 75 customers per hour during these four shifts respectively. Fast Food System Throughput  
1.3. Cooks, cleaners and assemblers will be the type of employees working the restaurant. Employee type  
1.4. Cook will be paid at the rate of $5 per hour for the duration of their work. Cook Salary  
1.5. Assemblers will be paid at the rate of $4.75 per hour for the duration of their work. Assemblers Salary  
1.6. Cleaner will be paid at the rate of $4.5 per hour for the duration of their work. Cleaner Salary  
1.7. Customer will leave without ordering if he sees 6 or more people in the line waiting to be served thereby causing a loss in revenue. Fast Food System Waiting time  
Sub-System Level Requirements
Object
Attribute
Function
2.1.1. The system will provide queue management by passing orders sequentially to kitchen (FIFO) by assigning order numbers to them. Internal Ordering System Order No TransmitOrder
ToKitchen
2.1.2. Customer should be able to order item either by name or by number (for combo deals). Item Type/Name Order
2.1.3. System will support native and other commonly spoken language in the country. Display Language  
2.1.4. An average order takes about 1 minute to complete with a variance of 10 seconds. Kitchen   Make Order
2.1.5. Customer takes 2 minutes on an average to complete and ordering process.     place order
2.1.6. System will be equipped with a standard QWERTY keyboard for taking inputs. Keypad layout  
2.2.1. This Order number will be printed on the bill that customer receives. Receipt Printer Order No PrintOrderNo
2.2.2. System shall be able to accept cash and coins. Cash Acceptor Type AcceptCash-
AndCoin
2.2.3. System should be able to accept debit / credit cards. Card Reader Type ReadCard
2.2.4. System will accept only $1, 5, 10, 20 bills and nickel, dime, quarter denomination of coins. Cash Acceptor TypeTo
AceeptCash-
AndCoin
AcceptCash-
AndCoin
2.2.5. System will reject pennies & $50, $100 bills. Cash Acceptor   RejectCash
AndCoin
2.2.6. System won't allow putting in $1 coin. Cash Acceptor   RejectCash
AndCoin
2.2.7. Cash return will return change only in coins. Cash Return type returnChange
Component Level Requirements
Object
Attribute
Function
3.1.1. Touch screen should be able to take inputs from users when they apply a light pressure (x lb) from their fingers corresponding to an item. Touch Screen   TakeInput
3.1.2. Touch screen should be able to withstand rough use i.e. it will be scratch proof (i.e., will be resistant to nail scratching) and will not malfunction if a pressure of (x+5) lb is applied to the screen. Touch Screen    
3.1.3. Touch screen will colored for visual appeal and will support at least 256 colors. Touch Screen type  
3.1.4. Resolution of the screen will be at least 640X480 pixels. Touch Screen pixels  
3.1.5. Touch screen will be at least 10" in size. Touch Screen dimension  
3.1.6. Touch screen should be able to display at least 15 rows and 60 columns of text when the font size of the text is 10. Touch Screen dimension  
3.2.1. System will be equipped with a card reader with built it keypad (containing all digits and special function keys corresponding to CANCEL, OK, # etc). Card Reader type  
3.2.2. This card reader should be able to read the card information if swiped at a speed > 1 m/s. Card Reader   ReadCard
3.2.3. Card reader will have a vertical slot on the right hand side of the keypad. Card Reader LocationOf
Slot
 
3.2.4. System will read the swiped card, will retrieve the total bill amount and initiate the modem to dial the bank to complete the transaction. Modem / Card Processor   Dial Bank
3.3.1. System will display all the menu items in icons/graphics format for selecting. Display   selectItem
3.3.2. System will prompt the user for mode of payment. Display Payment Mode SelectPayment
Mode
3.3.3. Order will be transferred to the kitchen touch screen instantaneously once the user does the payment. Internal Ordering System ProtocolTo-
Communicate
TransmitOrder
ToKitchen
3.3.4. System will display the order sequentially on the kitchen screen with a forward and back button at the bottom. KitchenScreen   ForwardOrder
ReverseOrder
3.3.5. Touching an order on the kitchen screen will prompt the system that the order has been delivered and the screen will be rolled forward. KitchenScreen   SignalComplete-
Order
3.3.6. Any error message during such a process will be reported to the user on the touch screen informing him to take any further action. Display   ReportError
Message
3.3.7. There will be a high contrast between the foreground and the background of the display for easy reading capabilities. Display    
3.3.8. Throughout the ordering process all the text displayed on the screen will be either greater than 10 or less than 18 font size so that all users (young, adult, old) can read it. Display Text/Size  
3.4.1. Modem should be able to complete a transaction (dialing, sending information, receiving information) in 15 seconds or less at all times. Modem Speed Dial Bank/
Transmit
Information
3.4.2. Once connected to the bank system will supply the card information to the bank database, will query the card validity and will supply the amount to be charged to the card. Modem   Transmit
Information
3.5.1. System will be secured to grant access rights only to the system administrator. For this a login ID and a password will be assigned which could be changed. Password won't be visible to onlookers while typing for increased security. Software Login/
Password
Authorize
3.5.2. System will deny access to change the contents if the login/password/ both are incorrect by providing an error message. System Administrator/ Software  Deny Access


Design Structure Matrix

Systems engineering of product, process, and organizations require tools and techniques for system decomposition and integration. A design structure matrix provides a simple compact and visual representation of a complex system that supports innovative solutions to decomposition and integration problems. The techniques of DSMs have led to there increasing use in a variety of contexts, including product development, project planning, project management, systems engineering, and organization design.

There are two main categories of DSMs: Static and Time-based. Static DSMs represent system elements existing simultaneously, such as components of a product architecture or groups in an organization. In time-based DSMs, the ordering of the rows and columns indicate a flow through time: upstream activities in a process precede downstream activities, and terms like 'Feedforward' and 'Feedback' become meaningful when referring to interfaces.

Figure 19. DSM Taxonomy

1. Component -Based or Architecture DSM: Used for modeling systems architectures based components and/or subsystems and their relationships.

2. Team-Based or Organization DSM: Use for modeling organization structures based on people and/or groups and their interactions.

3. Activity-Based or Schedule DSM: Used for modeling processes and activity based networks based on activities and their information flow and other dependencies.

4. Parameter-Based (or Low-Level Schedule) DSM: Used for modeling low-level relationships between design decisions and parameters, systems of equations, subroutine parameter exchanges.

Now let us apply one of the DSM techniques to our existing system. Let us consider the Pay Bill activity of our system and apply the 'Information Flow based Process Modeling' using the Activity-Based DSM.Processes - especially product development processes are complex systems. A prerequisite to process improvement is process understanding. Process structure or architecture affects process efficiency and effectiveness. Therefore, process architecture can be an important source of competitive advantage. Improved understanding of process architecture can be gained by using process models, particularly ones that support process decomposition and integration analysis. Process decomposition requires and understanding of process activities and their interfaces, because the interfaces are what give a process its added value. therefore process models must capture flows.

Modeling a process requires two representation steps, followed by integration analysis

  1. Decompose the process into activities
  2. Document the information flow among the activities
  3. Analyze the sequencing of the activities into a maximally-feed-forward process flow.

Activity-Based DSM of the payment design process:

Activities 1234567891011121314151617
Display Bill1 X               
Select Mode of payment2  X         X    
Read Card3   X             
Dial bank4    X            
Transmit information5     X X         
Decline card6      X          
Display error message7 X               
Approve card8        X        
Display Approved message9         X       
Get signature10          X      
Print receipt11           X     
Transmit order to kitchen12            X    
Accept cash/coins13                 
read amount14              XX 
Count total amount and display15            X   X
Reject Cash/Coin16            X    
Return change17          X      

Figure: Activity Based DSM for Fast Food Payment System

With a reasonably accurate model of a process, one then uses the model to look for improvements, expecting that they can be implemented in the real process. the primary goal in basic DSM analysis is to minimize feedbacks and their scope by restructuring and re-architecting the process, that is, by re-sequencing the rows and columns of the matrix. This widely practiced initial step in analysis is called partitioning, block diagonalization or block triangularization. 

In our model since there are very few feedback paths and amongst the existing ones every path is important hence we cannot minimize the number of feedback paths. But after frequenting DSM we have the following block-diagonalized DSM

Activities 4561723891015111713141612
Dial bank4 X               
Transmit information5  X    X         
Decline card6    X            
Display Bill1     X           
Display error message7     X           
Select Mode of payment2      X      X   
Read Card3X                
Approve card8        X        
Display Approved message9         X       
Get signature10           X     
Count total amount and display15            XX   
Print receipt11                X
Return change17           X     
Accept cash/coins13              X  
read amount14          X    X 
Reject Cash/Coin16             X   
Transmit order to kitchen12   

Write Use cases or Test cases?

January 26, 2017QA Digest

Use cases and test cases are the terms that are heard very often in Software Testing industry. They both are designed/developed to identify the ways in which the users interact with the system to achieve the expected result in a specific way. Most probably both the documents will contain the same set of data and instructions. And maybe this is why Use Case and Test Case terms are used interchangeably, and this is wrong too. The difference between Use Case and Test Case lies within the scope and purpose of designing them.

Being a software tester it is very much required to understand and interpret the actual meaning of Use Cases and Test Cases and act accordingly. With the rise in testing in mobile software industry the needs to design/develop use cases has risen, as the more use cases we test the more reliable the software is.

Basically to understand at higher-level, what is the use case and test case, consider an online shopping scenario where the user is required to add the particular product to the cart with quantity 3. Use case just says add the product to cart with n quantity. Whereas Test case describes, how to go the particular product page, set the quantity to 3 and then add it to the cart. Here again, test case covers the precondition that product quantity available in the warehouse should be minimum 3, and all the possibilities while adding the product to the cart:

  • Adding the product at once by setting the quantity to 3
  • Adding the same product 3 times with quantity 1
  • Adding the same product 2 times with quantity 1 for the first time and 2 for the second time
  • Adding the same product 2 times with quantity 2 for the first time and 1 for the second time

Understanding the terminologies: Use Case and Test Case

  1. Use Case

By the definition use case is the step by step events developed for the interaction between a role and the system, i.e., to tell how the user interacts with the system. The goal of use case is to advise the development team about the user expectations from the system. Basically, business and user requirements are captured here by describing all the possible paths for the user to interact with the system. Paths here are Basic Path, Alternative Path, and Exceptional Path.

  • Basic Path, also called Happy Path, is the direct flow which captures the user-system interaction directly.
  • Alternative Paths are those flows where user-system interaction happens through different ways which are not so common or desirable. These paths are not frequently used in the system, but cannot be left untested.
  • Exceptional Paths are the flows which fail to achieve user goals with the system due to any reasons: invalid input, missing input, canceling, etc.

It’s very usual that, a single use case can have multiple paths to test and ensure the user-system interaction through all the paths.

Use Cases are one of the inputs to design/develop test cases.

  1. Test Case

By the definition, a test case is a set of conditions or variables under which the response of the system will be tested and evaluated. The purpose of writing test case is to validate whether the system meets all the specified requirements. Test Case is written for each and every path that is described in the use case, which is executed by the testers during the execution phase of the Software Testing Life Cycle. It is preferred to write the separate test cases for every individual path identified for the user-system interaction.

Test Cases are intended for the testers to validate each of them for quality assurance. It is recommended to start writing test cases as early as possible.

Example to understand Use Case and Test Case

In all the applications that support user profile, Reset password flow is one of the basic features to be tested. Here in the example, we will try to understand how the Use Case Diagram and Use Case Scenarios can be written for the feature and the respective test cases to cover the same.

Use Case Diagram

Above Use Case diagram helps to understand the Reset Password feature flows through Email. All the possible flows are shown with arrows which have to be followed the same way to complete the respective flow.

Use Cases / Use Case Scenarios

Now let us analyze the possible Use Case Scenarios that can be derived from Use Case Diagram.

Preconditions:

  • User should have the active account in the application

Scenarios:

  1. User initiates Reset Password flow through Forgot Password button/link
  2. User should be able to request the reset password via Email
  3. Reset password Via Email
    • 3.1   Reset password through the link received in Email within 24 hours
    • 3.2   Click on the reset password link received in Email after 24 hours
      • 3.2.1   New Email should be received with the new reset password link
    • 3.3   Try Reset password through invalid link
      • 3.3.1   Copy-Paste the reset password link in browser and edit the code part of the link before launching
      • 3.3.2   Click on the reset password link received earlier in the Email (2-3 previous Emails)
      • 3.3.3   In both the cases 3.3.1 and 3.3.2, new Email should be received with the new reset password link

The use case diagrams and scenarios are useful in designing how the user should interact with the system. This will be helpful for the developers too for reference while program design. The developers will check and evaluate the use case scenarios when they complete each module of the system. This will ensure they are going in the right way. The use case diagrams are also helpful for the creation of test case scenario.

Test Cases

The Quality Analysts are responsible for creating test criteria. The use case diagrams will also be helpful in creating test cases based on each use case scenarios. The test cases should aim at verifying system’s actual behavior with expected results.

Here we will cover how test cases are written based on the Use Case Diagram and Use Case Scenario:

TC_IDTest Case NameScenario #PreconditionTest StepsExpected Result
1Forgot Password11.      Launch the application

2.      Click on Forgot Password button

Verify three options are displayed to the user:

1.      Via Email

2.      Via SMS (covered in other sample examples)

3.      Via Call (Covered in other sample examples)

2Via Email21.      Click on Via EmailVerify user is asked to enter the Email address to send reset password link
3Send Reset Password link to Valid Email Address3User’s Email address should be registered and activated in the application1.      Enter the valid Email address in the text box

2.      Click on Reset Password

Verify user receives an Email with reset password link
4Non-registered Email Address attempt to reset password3Email address should not be registered in the application1.      Enter the non-registered Email address in the text box

2.      Click on Reset Password button

Verify error message “Email address not registered” is displayed
5The invalid Email address format31.      Enter Email address in invalid format

2.      Click on Reset Password button

Verify error message “Invalid Email Address” is displayed
6Email Address field blank31.      Leave the Email address field blank

2.      Click on Reset Password button

Verify error message “Provide the registered Email address” is displayed
7Reset Password link – Successful3.1User should have received Email Address with Reset Password link1.      Access user’s Email account within 24 hours

2.      Open the Email received for Reset Password via Email

3.      Click on the Reset Password link present in the Email

Verify user is allowed to reset the password
8Reset Password after 24 hours3.2User should have received Email Address with Reset Password link1.      Access user’s Email account after 24 hours

2.      Open the Email received for Reset Password via Email

3.      Click on the Reset Password link present in the Email

Verify User is not allowed to reset the password and appropriate error message is displayed
9Reset Password after 24 hours – new Email3.2.11.      Check the Email Address againVerify new Email is received with new Reset Password link
10Invalid Reset Password link – Copy-Paste method3.3.1User should have received Email with Reset Password link1.      Access user’s Email account

2.      Open the Email received for Reset Password via Email

3.      Copy the Reset Password link present in the Email and Paste it into the browser

4.      Change the code present in the link URL and hit Enter key

Verify User is not allowed to reset the password and appropriate error message is displayed
11Invalid Reset Password link – Copy-Paste method – new Email3.3.31.      Check the Email Address againVerify new Email is received with new Reset Password link
12Invalid Reset Password link – Expired link3.3.2User should have received Email earlier with Reset Password link1.      Access user’s Email account

2.      Open the Email received earlier for Reset Password via Email

3.      Click on the Reset Password link present in the Email

Verify User is not allowed to reset the password and appropriate error message is displayed
13Invalid Reset Password link – Copy-Paste method – new Email3.3.31.      Check the Email Address againVerify new Email is received with new Reset Password link

The flow varies from application to application. Here an attempt is made to understand the Use Case and Test Case terminologies with the simple example.

Try yourself to Reset Password via SMS and via Call. Click the below links to check the sample examples for the same:

Reset Password via SMS

Reset Password via Call

Difference between Use Cases and Test Cases

Use Cases

Test Cases

Use cases are developed  as step by step events which describes how to execute functionalityTest cases are developed based on the use cases and verifies the functionalities defined
Use cases are developed based on the Business Requirement Specifications[BRS]Test cases are developed based on the Use Cases
Use cases are prepared by Business AnalystTest cases are prepared by Quality Analysts
Use cases are made based on one or more use case scenario. The Use Case scenario defines how to achieve the business requirement goals.The test cases scenarios will describe “What to be tested”. The test cases designed for the test case scenario specify “How to be Tested”
Use cases are only designed and cannot executeTest cases are developed based on the use cases and are executed later
Use cases document will explain how the user interacts with the software and the business goalsThe test case documents will verify the goal to see whether all the required test cases are executed or not
Use cases are documented once and verify whether all the requirements are involved or notTest cases documents will be updated after each test phases and will get updated with the test results
Use Cases are pictorial representation of the user-system interactionTest Cases are documented in Excel Sheets or in Test Management Tools
Use Cases can combine relevant multiple scenarios in single documentSince Test Cases cannot have combined results, it is not recommended to include multiple scenarios in the same test case document.
Use case documents are used for reference purpose onlyTest case documents are used for test executions and the results will vary as per the input.
User Acceptance Testing phase depends on Use Case DocumentsRegression and System Testing phases depends on Test Case Documents
Use Case adds more value to understand and enhance the business flowsTest Case adds more value to the QA work during execution phase
Use Case is complimentary testing, and cannot judge the quality of the applicationTest Case is validation activity which helps in judging the quality of the application
Use Case does not provide entire coverage of the systemTest Case goal is to achieve 100% coverage of the system, which is possible through Reverse Traceability Matrix.
Use Case helps in uncovering only Integration defects that comes along the pathTest Cases helps in uncovering all the defects throughout the system

Conclusion

The use case and test case are sometimes considered to be the same. The concepts in designing both are same on the technical side. But, the important aspect is that use cases are more specific to the client’s point of view. 

The use case diagram describes the exact requirement of the client and what they expect their system to be. So, there is a chance to identify missing links in use case diagrams. These links will be filled later when the system design goes on. Also, use cases are the means to identify the ambiguous paths, incomplete requirements, hidden logic, missing requirements, etc.

The test case is specific and concise to the actual performance of the system. The quality assurance of the system is ensured by the execution of the most specific test cases. The test case derived from the use case diagrams and they confirm that the use case diagrams denote the actual results which are possible to achieve. Test Cases are the means to assess the system and ensure the quality of the same.

Testers refer use cases to write test case documents, whereas, developers refer use cases to implement all possible integrations within the system. Both, Use Cases and Test Cases, have equal importance in Software Testing Industry, but they have to be used correctly based on the context at any point in time. Even though they both provide the same basic information and overlap, they are not the same as described in this article. Make use of these documents wisely in the project to gain more efficiency and accuracy during the validation phase.

0 comments

Leave a Reply

Your email address will not be published. Required fields are marked *