Help - Help for Webmasters
« back to results for "retail audit plan gantt chart" Below is a cache of http://joegakenheimer.com/Gakenheimer/software_engineering/TeamBFinalSpecification.doc. It's a snapshot of the page taken as our search engine partner crawled the web. We've highlighted the words: retail audit plan gantt chart Beta The website itself may have changed. You can check the current page (without highlighting). Yahoo! is not affiliated with the authors of this page or responsible for its content.

DinnerWare

A Restaurant Management Software Systemm

Final Specification

Comp 395 Software Engineering

Spring 2003

Joe Gakenheimer

Table of Contents

Project Overview

Introduction…………………………………………………………………..

Specific Project Objectives………………………………………………….

Overall Project Requirements………………………………………………..

Constraints and Assumptions………………………………………………..

Requirements ?

Planning Documents

Project Plan Gantt Chart…………………………………………………….

Risk Management Plan…………………………………………………………….

Cost Analysis……………………………………………………………….

Configuration Management Plan…………………………………………..

Functional Requirements

Entity Relationship Diagram………………………………………………

Data Dictionary……………………………………………………………

Data Flow Diagrams………………………………………………………

Process Descriptions………………………………………………………

CRUD Matrices……………………………………………………………

Use Case Diagrams………………………………………………………..

Use Case Scenarios………………………………………………………..

Design Specifications

Design Architecture Description…………………………………………..

Performance and Reliability Requirements……………………………….

Component/Deployment Diagram………………………………………..

Test Plan

Test Case Grids……………………………………………………………

Appendices

……………………………………………………………………………..

Specific Project Objectives

The purpose of this project is to develop a software prototype that can help run a restaurant. The needs of a restaurant involve inventory, order taking, menu maintenance and business reporting. The restaurant in question is a fictional restaurant, and its owner is our client and professor; Barbara Hecker. The time or inception for this software project will be the first week of April 2003.

The objective of this software project is to create an atmosphere where efficiency and preciseness are the norm. The benefits of such a system will improve payroll, and consequently improve food costs. Food cost and payroll will be benefited from the mere disappearance of employee pilfering, and the discipline of consistent products. Inventory will also be more tightly secured from pilfering, and will induce higher quality inventory and eradicate much of the losses due to spoilage. All in all the goal is to allow the client to prosper in an efficient money making operation and turn all weaknesses into strengths.

Our initiatives are to model and create a strong degree of design for the entire production and accounting practices for the restaurant. The process will involve a menagerie of tools and methods, but in the end we feel that all efforts will result in a software product that will fulfill the needs of the client. The client will be giving us all of the needs that they feel is necessary to regain profitability and to capture market competitiveness. In return we will provide a detailed description of the design of the software, the performance requirements, the security requirements, and the need for employee training. By giving a detailed description of the system in a macro view, we intend to give strong understanding to the client so they will have a strong idea of how the processes are antiquating, and if we will ever have to make changes to conform to newer needs of the client.

Overall Requirements for Restaurant System

The system shall provide support across three major areas of restaurant business functions, including inventory management, food costing/menu maintenance and customer order processing.

The inventory management subsystem will track food items from the time they arrive at the store, reduce levels based on sales data and spoilage and provide alerts to reorder. The subsystem will also update the Inventory database with gross food cost to support ad hoc reporting and food costing of menu items, which is handled in the menu maintenance subsystem.

Menu Maintenance will provide graphical support for creating and editing menu items in the development and maintenance of various menus. It will utilize the item food costs in the Inventory database for determining appropriate pricing of menu items, consistent with desired profit margins.

The order processing subsystem will provide on-line, point of service customer meal order-taking by wait staff. Each order will flow through the order fulfillment process electronically and be displayed on video monitors that may be viewed by the kitchen and bar (if applicable) staff, as well as by management personnel. When finalizing the bill, the system shall be able to group the individual orders on the ticket in what ever configuration is desired by the customers, from one check to separate checks for every customer at the table. For customer service quality assurance and future business planning, the system will record the time at various points in the order processing cycle on the ticket. All ticket records will be stored in the ticket database and sales data entered into the Sales database.

Assumptions and Constraints

Assumptions

• Assume a maximum number of 25 simultaneous users of the system.
• Assume compatibility with a Microsoft Windows 2000/NT/XP operating system.
• Assume software performs on a single Ethernet based LAN with Internet connectivity and a wireless 802.11b network.

Constraints

• One machine (e.g. server) on network must be at least an 800 MHz PIII with 256 MB of RAM and free disk space of 1 GB.
• Total retail cost constrained to be no greater than $24,000.
• Project resources constrained to 3 programmers, each working part time on the project for 3 months – estimated total possible effort at 3 person-months
• Programming languages constrained to Java, C++, SQL, or Object Pascal.
• IDEs constrained to Microsoft Visual Studio and/or NetBeans .
• No added software security – the software must rely on Windows 2000/XP built-in security and possibly Java built-in security.
• Database will be ODBC compliant.

Gantt Chart here
Risk Management Plan

Project Risks

Technical Risks

Business Risks

Cost Analysis here

Configuration Management Plan

Software Configuration Items

• Project Specification
• Project Plan
• Project Requirements
• Design Specifications
• Process Description
• Architectural Description
• Ergonomically Friendly
• User Manuals for Staff
• Source code listing
• Interface Source Code
• Small Website Source Code?
• Database Source Code
• Test Specification
• Test Plan
• Test Case Grid
• Executable Program
• Interface Executable
• Database Executable

Version Control
The Version Control software we will use is Rational ClearCase. At this time we are planning to use Visual Studio and NetBeans. As the project moves along, we may use other IDE’s such as JBuilder. The needs we have for text editors will be Microsoft Word, EditPlus, and a nice FTP program, preferably CuteFTP.

Change Control
When the need for change is needed, the individual must decide whether it is a significant change. If it is a significant change then a change document must be submitted to the Project Manager. If a change is not significant, then there is no need for documentation. If a change is for largely needed, and the individual can not make the decision on his or her own, then the Project Manager or group must discuss the change as a whole. If any change can or would have significant alteration to the project then the group must meet and come to a decision.

Configuration Management Audit
All changes will follow the specified instructions which have already been developed. Formal Technical Reviews and Software Configuration Audits will also be included in the process. And finally, all changes will be dated and recorded to the standards already specified in the group.

Status Report

Whenever substantial changes take place, we will document them. The individual initializing the change will submit a Configuration Management Report to the rest of the group. And form there the document will be filed and added to the Gantt chart. The documentation will answer the questions who, where, when, and why, or the individual will be held accountable for stepping out of the boundaries of the project. Documentation will not be needed unless the changes are significant; these changes are at the discretion of the Project Manager.

Entity Relationship Diagram

Data Dictionary

Attribute Length Type Validation Criteria

Entity: Head Chef

Head Chef ID* 4 integer value > 0

Description: ID of head chef

Head Chef Name 40 char none

Description: Full name of head chef

Entity: Manager

Manager ID* 4 integer value > 0

Description: ID of manager

Manager Name 40 char none

Description: Full name of manager

Entity: Menu

Menu ID* 4 integer value > 0

Description: ID of the menu

Date Created 10 date must be in MM/DD/YYYY format

& value <= current date

Description: Date menu added to system

Date Put In Use 10 date must be in MM/DD/YYYY format

& value <= current date

Description: Date menu put into use

Date Taken From Use 10 date must be in MM/DD/YYYYY format

Description: Date menu taken out of use

Head Chef ID 4 integer value > 0

Description: ID of head chef who created the menu

Manger ID 4 integer value > 0

Description: ID of manager who approved menu

Menu Item ID 4 integer value > 0

Description: Item which appeared on this menu, will generally be more than one

* denotes Key

Data Definitions (continued)

Attribute Length Type Validation Criteria

Entity: Menu Item

Menu Item ID* 4 integer value > 0

Description: ID of menu item

Menu Item Name 40 char none

Description: Description of menu item

Date Created 10 date must be in MM/DD/YYYY format

& value <= current date

Description: Date menu item added to system

Head Chef ID 4 integer value > 0

Description: ID of head chef who created the menu item

Special Flag 1 boolean none

Description: True means the menu item is a special

Ingredient ID 4 integer value > 0

Description: ID of ingredient used in menu item

Ingredient Name 40 char none

Description: Name of ingredient used in menu item, may be more than one

Ingredient Amount 6 decimal(4,2) value > 0

Description: Amount of ingredient used in menu item

Menu Item Price 6 decimal(4,2) value > 0

Description: Listed price of item on menu

Menu Item Cost 6 decimal(4,2) value > 0

Description: Total cost of all ingredients in menu item – does not include labor (direct burden) or indirect burden (lights, heat, other overhead).

Entity: Ingredient

Ingredient ID* 4 integer value > 0

Description: ID of ingredient – doesn’t refer to a specific purchase of ingredient

Ingredient Name 40 char none

Description: Name of ingredient

Date Created 10 date must be in MM/DD/YYYY format

& value <= current date

Description: Date new ingredient ID added to system

Ingredient Unit Cost 6 decimal(4,2) value > 0

Description: Unit cost (per lb, oz, etc.) of ingredient

*denotes Key

Data Definitions (continued)

Entity: Ingredient (continued)

Attribute Length Type Validation Criteria

Amount On Hand 6 decimal(4,2) value > 0

Description: Amount of ingredient on hand

Threshold Amount 6 decimal(4,2) value >0

Description: Threshold value which generates an order for more

Ingredient Ceiling 6 decimal(4,2) value > 0

Description: Maximum amount of ingredients needed

Date Purchased 10 date must be in MM/DD/YYYY format & value <= current date

Description: Date ingredient was received and put into actual storage or used

Food Distributor ID 4 integer value > 0

Description: ID of distributor who carries this ingredient, may be more than 1

Storage Location 40 char none

Description: Location of ingredient which was purchased

Entity: Food Distributor

Food Distributor ID* 4 integer value > 0

Description: ID of food distributor

Food Distributor Name 40 char none

Description: Name of food distributor

Food Distributor Address 80 char none

Description: Address of food distributor

Food Distributor Phone 10 char none

Description: Phone Number of food distributor

Food Distributor Contact 40 char none

Description: Name of contact person at food distributor

* denotes Key

Data Flow Diagrams

Inventory and Reporting DFDs here

1.2 Ordering Process, Level 1 thru Primitive

1.2.1 Create Ticket

1.2.2 Edit Ticket Orders

1.2.3 Submit Ticket Orders

1.2.4 Fulfill Ticket Orders

Menu Maintenance Process Level 1 DFD

Menu Process DFD 2^nd Level

Menu Item Process 2^nd Level

Ingredient Process DFD 2^nd l

Process Descriptions

Inventory Processes

Joe – are there updates on these?

Subtract from Inventory

If order has been completed

Subtract amount from inventory

If inventory below inventory needed

Purchase from distributor

Else

Don’t order from distributor

Order Supplies

If order levels low

Purchase from distributor

Else

Don’t order from distributor

Delivers Supplies

If distributor has received order

If distributor has stock of needed supplies

Distributor delivers supplies accordingly

Else

Distributor tells Purchasing out of stock

Distributor orders from manufacturing

Adds to Inventory

If supplies are delivered

Stock Boy counts

Signs for

And stocks and rotates the supplies

Computes Food costs

For all orders completed

Compute aggregate sales

For all products purchased from distributor

Compute all aggregate food cost

Compute aggregate food costs divided by aggregate sales

Food costs equal aggregate food costs divided by aggregate sales

Computes Product Sales

For all order compute sales

If order is carryout

Return total

Else

If order is dine in

Add income plus (income * tax rate)

For all sales that are dine in and are carryout

Return total sales

Compute aggregate food costs divided by aggregate sales

Food costs equal aggregate food costs divided by aggregate sales

Computes Product Stats

For each individual product

If item is beverage

For each food product

Add to database beverage field

Compute units sold by price

Return beverage sales of each

If item is food

For each food product

Add to database food field

Compute units sold by price

Return food sales of each

If item is salad

For each salad product

Add to database salad field

Compute units sold by price

Return produce sales of each

Creates Marketing Data

For each individual product

Compute units sold divided by price

Return profit margin

Sort each product by profit margin

For each sorted product profit margin

Classify all which are below median

For each order

Compute total sales for dine in

Compute sales for dine out

For all orders with discounts

Compute percentage of all patrons using coupons

Computes Marketing Expenses

For all advertising expenses

Add all advertising and statistical analysis expenditures together

Ordering Processes

Ticket Process Descriptions

A ticket is created by the hostess for every group of patrons dining at the restaurant. This ticket is then used by the server (wait staff) to take the customers menu orders, which the kitchen uses to fulfill the ticket’s orders. The ticket may continue to be used by the server to take additional orders from the same customers or be totaled to create a bill for the customers. Finally, the ticket information is saved to disk for accounting and reporting purposes.

Create Ticket Process

• Accept the user’s (Hostess) input selection to create a ticket.
• Display ticket set up screen.
• Get server names from the Employee table.
• Populate a Server drop down box that is displayed on the screen.
• Accept the users selection of server.
• Accept the user’s input of the number of patrons in the party being seated.
• Accept the user’s input of table number.
• Accept the user’s input selection of Ticket Complete.
• Get System time and date.
• Send new information to the (system) server.
• Post new Ticket record to the data base
• Send ticket to the food server’s PPC.

Edit Ticket Process

• Accept user’s selection of create new order
• Accept user’s input of a numeric seat assignment for the order
• Display menu screen.
• Prompt the user to select a menu item.
• Accept user’s selection of menu items for this customer.
• If the customer is ordering (paying for) an item for someone else’s consumption, system accepts user’s selection of the ‘serve to other’ check box.
• Prompt the user to enter another item or press complete.
• If user presses complete, prompt the user to: create another order, submit this ticket for the kitchen to fulfill, or put ticket on hold.
• If the user selects ‘hold’, the user can process other tickets until he is prepared to either edit this ticket further or submit the ticket for fulfillment by the kitchen.
• Continue adding to existing or creating new orders for this ticket until user has taken the orders for all the customers in the party.

When the user has completed entering all the orders for this ticket, accept the user’s selection to submit the ticket.

Submit Ticket Order

• Accept user selection to submit ticket
• Add time submitted timestamp to Ticket
• Display on monitors in kitchen and touch screen
• Set ‘order submitted’ property for all instances of order in ticket
• Set ticket state to wait until user selects “edit ticket” or the order is fulfilled by the kitchen

Fulfill Ticket Order

• Set each order’s fulfilled property to true
• Insert a timestamp in Ticket’s time ticket fulfilled property of each Order object
• Accept fulfilled ticket from ticket
• Create a timestamp for the Order properties
• Group orders on ticket user order mapping
• Get totals for each of the groups and print a bill for each.
• Set Ticket Open property to false.

Menu Maintenance Process Descriptions

Menu Creation, Deletion and Update Processes

The Menu Creation Process allows the manager to create a menu from menu items. Each menu has an ID, Name and Date Created. Menu items are added to the menu and can be flagged as specials. The menu, once created, can be put into use immediately, or it can be stored for later use. The option to print the menu is in the Menu Creation Process. All menus need manager approval for final creation. Menus are stored at the end of the process in the data store.

A menu can be deleted from the system given the ID or Name of the menu. Manager approval is needed to delete a menu from the data store. A menu can be updated using the Menu Update Process given the ID, Name or Date Created for the menu. Menu items can be added to or deleted from the menu. Menu Items can also be flagged as Specials. Furthermore, the menu can be put in use or taken from use in the Menu Update Process.

Menu Item Creation, Deletion and Update Processes

The Menu Item Creation Process allows the head chef to create new menu items. Each menu item has an ID, Name, Date Created, and a boolean Special Flag which is set to True if the item is a special. The process loops asking for each ingredient in the menu item. Each ingredient’s ID, Name, Amount and Unit Cost are input. The cost of each ingredient is calculated using the Amount and Unit Cost. The menu item cost is then a summation of the ingredient costs. The margin is read in and added to the cost to yield the price of the menu item. The head chef needs to approve each menu item. If desired the head chef (or person with authority) can override the system generated price (cost + margin) with a user input price. Menu items are stored in the data store at the end of the process.

The Menu Item Deletion Process allows the head chef to delete a menu item from the data store given its name or ID. The Menu Item Update Process allows menu items to be changed by adding ingredients, removing ingredients, changing ingredient amounts or changing the margin on the menu item.

Ingredient Creation, Deletion, and Update Processes

Ingredients are added to the system using the Ingredient Creation Process. Included with each ingredient is its Amount On Hand, Threshold Amount, Ceiling, Storage Location, Date Purchased and Food Distributor for usage and inventory purposes. Ingredient addition to the inventory data store requires head chef approval. Ingredients are removed from the system using the Ingredient Deletion Process. Ingredients are updated using the Ingredient Update Process. The most likely updates will be to ingredient Amounts On Hand, and to a lesser extents Threshold Amounts and Ceiling. Implicit in this process is the running of Inventory Reports which will provide the information about ingredients used as a result of daily or weekly sales, depending on how often management wants to update inventory. Output from Inventory Reports can be used as input to the Ingredient Update Process.

Ingredient Purchasing Process

Inventory Reports will be run to provide the necessary input data for the Ingredient Purchasing Process. If the Amount On Hand is less than the Threshold Amount, an Order Amount is generated which is the Ceiling value less the Amount On Hand. The Purchasing Process will generate a Purchase Report which gives the Ingredient ID, Name, and Food Distributor(s).

CRUD Matrices

Inventory and Reporting Processes CRUD Matrix

Ordering Processes CRUD Matrix

Menu Maintenance Processes CRUD Matrix

Use Case Diagrams

Inventory and Reporting Use Case Diagram

Ordering Use Case Diagram

Menu Maintenance Use Case Diagram

Use Case Scenarios

Ordering Process

1. Assign ticket
2. Enter/Update Order
3. Submit order
4. Fulfill order
5. Finalize Ticket (group ticket orders for totaling bills)

1.2.1 Assign Ticket

1. Hostess selects the ‘Create Ticket’ button.
2. Screen displays the list of active waiters
3. Hostess selects a primary waiter
4. If necessary, hostess selects a secondary waiter
5. System displays a list of tables, along with the station location
6. Hostess selects the ‘Ticket Created’ button

1.2.2 Enter/Edit Ticket Order

1. Waiter requests the system to create a new or edit an existing customer order.
2. If new order, system displays a new blank order.
3. If editing an existing order, the user inputs the seating location of the customer for whom the order is being taken. All menu items previously entered into this order but not yet fulfilled are displayed in red, otherwise they are displayed in black.
4. If order is new, waiter associates the order with a position at the table (specific customer), or if the order is for (deliver to) a customer located at another table, defines as ‘other’.
5. System displays menu list
6. Waiter selects one or more menu items for this order.
7. Waiter repeats steps 1 – 5 until the orders for all the customers at the table have been taken and entered into the system.

1.2.3 Submit Order

1. After waiter has entered all the customers’ orders for a given ticket he requests the system to submit the orders on the ticket.
2. System updates the order submitted field on the order record with a timestamp.
3. The newly created orders for the ticket are displayed on the video displays in the kitchen.

1.2.4 Fulfill Order

1. Once the orders for the ticket have been fulfilled, the staff in the kitchen select order preparation completed on the touch screen.
2. The database is updated when the system inserts a timestamp in the order fulfilled field and sends a message to the waiter’s handheld device that the order is up.
3. Waiter selects the edit ticket button on his handheld device to display the orders to be picked up in the kitchen. This action updates the order records in the database by inserting a timestamp in order picked up field.

1.2.5 Finalize Ticket

1. Waiter selects system request to finalize the ticket.
2. System prompts the waiter to group orders, by seat location, for the purpose of creating customer bills.
3. The system maps the individual orders to specific seat locations. The grouped orders are then listed together and summed up to create the separate bills.

The bills are printed based on the above defined groupings.

Menu Maintenance Process

Manager Changes Menu

1. Enter Menu Maintenance Sub System using optional password
2. Choose from Create, Delete, Update
3. Make Change(s)
4. Authorize Change(s)
5. Exit

Extensions

Create Menu

3 a. Inputs Menu Date and Menu ID

3 b. Adds Menu Item(s) to Menu

Delete Menu

3 c. Inputs Menu Date or Menu ID

3 d. Deletes Menu

Update Menu

3 e. Inputs Menu Date or Menu ID

3 f. Adds Menu Items or Deletes Menu Items

Manager Prices Menu Items

1. Enter Menu Maintenance Sub System using optional password
2. Input Menu Item ID or Name
3. Input Margin
4. Get System Generated Cost for all Ingredients
5. Sum 2. and 3. for System Generated Price

Extension

5 a. Overrides System Generated Price by Inputting Price

Head Chef Changes Menu Item

1. Enter Menu Maintenance Sub System using optional password
2. Choose from Create, Delete, Update
3. Make Change(s)
4. Authorize Change(s)
5. Exit

Extensions

Create Menu Item

3 a. Input Menu Item ID, Name, Date, Descriptioin

3 b. Add Ingredient(s)

Delete Menu Item

3 c. Inputs Menu Item ID, Name or Date

3 d. Deletes Menu Item

Update Menu Item

3 e. Inputs Menu Item ID, Name or Date

3 f. Adds Ingredients and/or Deletes Ingredients

3g. Or Changes Menu Item Description

Manager Updates Ingredients

1. Enter Menu Maintenance Sub System using optional password
2. System Generate Ingredients Used Report
3. System Generate Ingredient Needed Report
4. System Generate Order Report and Purchase Orders
5. Manager Authorizes Purchase Orders
6. Purchase Orders Printed
7. Stock Boy Receives Ingredients
8. Stock Boy Stocks Ingredients

Design Architecture Description

Final Product Design Architecture and Minimum Requirements

Server

• Windows 2000 Server
• 500 MHz Athlon or PIII Processor
• 256 MB RAM
• 1GB Hard Disk Space for OS
• 500 MB Hard Disk Space for Database
• 10/100 BaseT Ethernet NIC

Network

• 802.11b compliant Wireless LAN (WLAN) for PDAs
• Access Point capable of handling 25 clients simultaneously (for example Dell TruMobile 1170 AP which supports 32 wireless clients and has an 10/100 Base-T Ethernet port)
• 10/100 Base-T Ethernet network for Workstations

Clients

PDA

• Windows CE, Pocket PC OS, Palm OS 4.0 or other OS capable of supporting wireless protocols such as CLDC /MIDP for Java 2 Micro Edition (J2ME) and Internet Applications such as HTML, xHTML, cHTML, XML, SSL
• 802.11 b compliant NIC or PCMCIA cards
• 16 MB RAM
• 2MB Disk Space

Workstation

• Windows 2000 Professional
• 500 MHz Athlon or PIII Processor
• 256 MB RAM
• 1 GB Hard Disk Space for OS
• 10/100 Base-T Ethernet NIC

Database

• Microsoft Access

Performance and Reliability Requirements

Simultaneous Transactions

The system shall be capable of processing 15 orders at any given time. Processing of orders on an individual ticket requires small amounts of processor time because the most of the server responsibility is handling database transactions. The business objects and their manipulation are performed on the individual clients. Worst case scenario would involve the maximum of 22 users. This represents a 50% increase over the figure above and is based on the following:

• 15 wait staff (submitting an order, finalizing (closing) a ticket)
• Two kitchen stations (each fulfilling a food order)
• one service bar station (fulfilling a bar order)
• two assistant managers and one general manager (each overriding or inquiring about an order)
• One hostess client (open a new ticket)

Response time and execution efficiency:

The acceptable response time is four seconds.

System accuracy:

System accuracy is very important because the billing (customer check) to our customers is scrutinized on an order-by-order basis as a rule. The business could potentially lose customers if their bill is not accurate.

Conciseness of the software:

The hardware requirements provide for enough memory and processing power to be less concerned about the footprint of the executable.

System error tolerance:

The overall robustness of the system will require the appropriate error handling to allow for continued use of the system and minimal loss of data.

Hardware independence:

The level of hardware dependence is acceptable in that the operating system used is most current and universally used OS in the U.S. Any PC related hardware that can support Windows 2000 is acceptable.

System self-monitoring and error identification:

System modularity:

The level of modularity will be moderate through the use of packages or dll’s. This will allow for flexibility in the degree of functionality loaded on the various clients, depending on the type of work performed by the user.

Operability requirements:

Ease of use will be emphasized for the ticket maintenance client given the high work pace and additional effort required of the users (wait staff).

Source Code Documentation:

Source code documentation will be sufficient to support the maintainability of the software. Primary emphasis will be placed on inline documentation within the source code itself.

System training and degree to which the software assists new users:

System training is very important but online help will be less extensive, given the lack of time available to the users for researching issues. Online help may be useful when loaded as a separate package (dll) on a desktop PC.

Optimizing Performance During "Peak" Business Periods:

Activities designed to

Database Maintenance:

Database maintenance will occur from the clients via ODBC/JDBC.

Archiving Data:

Data archival will occur by the writing all database records for that week on an optical media (CD-RW) via an internal writer located on the server. An additional copy is made every month and stored offsite.

Report Generator:

Since the DBMS is Microsoft Access, the user will use the Access interface and Excel to create all necessary reports. No additional support is required by the system.

Security:

Database access is limited to users with access to the network. Users will be required to enter a user id and password to enter the application. All packages will have authority level support as well as the database. Therefore, user access within the application will be limited to their authority for the individual packages that are loaded on a specific machine. Network security is outside the scope of this application.

Component/Deployment Diagram

Test Case Grids

Inventory

Ordering

1.2.1 Assign Ticket

1.2.2 Enter Ticket Order