Online Pizza Ordering

1. Introduction
This SRS is made to briefly describe the requirements of the project of online pizza ordering using speaking agents. It will tell us about all the requirements for making this project. The project will be based on Web Publishing System. 1.1 Purpose

.The purpose of this document is to present a detailed description of the Web Publishing System. It will explain the purpose and features of the system, the interfaces of the system, what the system will do, the constraints under which it must operate and how the system will react to external stimuli. This document is intended for both the stakeholders and the developers of the system. 1.2 Scope

This software system will be a Web Publishing System for a local editor of a regional historical society. This system will be designed to maximize the editor’s productivity by providing tools to assist in automating the article review and publishing process, which would otherwise have to be performed manually. By maximizing the editor’s work efficiency and production the system will meet the editor’s needs while remaining easy to understand and use. More specifically, this system is designed to allow an editor to manage and communicate with a group of reviewers and authors to publish articles to a public website. The software will facilitate communication between authors, reviewers, and the editor. This SRS document will also help the maintenance team to maintain the project or adding new techniques for making it advance.

1.3 Definitions, Acronyms, and Abbreviations
.SRS: Software Requirement Specifications
A software requirements specification (SRS) is a comprehensive description of the intended purpose and environment for software under development. The SRS fully describes what the software will do and how it will be expected to perform.

1.5 Overview
The next chapter, the Overall Description section, of this document gives an overview of the functionality of the product. It describes the informal requirements and is used to establish a context for the technical requirements specification in the next chapter. The third chapter, Requirements Specification section, of this document is written primarily for the developers and describes in technical terms the details of the functionality of the product. Both sections of the document describe the same software product in its entirety, but are intended for different audiences and thus use different language.

2. General Description
We are looking for new website for online Pizza ordering system. With same admin site wit all statistics options and features.

Here I explain the system that how I want to use it.

Online Ordering system :

In that user can order online for food and whatever in menu item. User can get delievery and also user can check delivery status. User can get payment also after delivery of Pizza. Other common functionlity are also included.

2.1 Product Perspective

2.2 Product Functions
2.3 User Characteristics
The Reader is expected to be Internet literate and be able to use a search engine. The main screen of the Online Journal Website will have the search function and a link to “Author/Reviewer Information.” The Author and Reviewer are expected to be Internet literate and to be able to use email with attachments. The Editor is expected to be Windows literate and to be able to use button, pull-down menus, and similar tools. General Constraints

This subsection of the SRS should provide a general description of any other items that will limit the developer’s options for designing the system. (See the IEEE Guide to SRS for a partial list of possible general constraints). 2.5 Assumptions and Dependencies

This subsection of the SRS should list each of the factors that affect the requirements stated in the SRS. These factors are not design constraints on the software but are, rather, any changes to them that can affect the requirements in the SRS. For example, an assumption might be that a specific operating system will be available on the hardware designated for the software product. If, in fact, the operating system is not available, the SRS would then have to change accordingly. 3. Specific Requirements

This will be the largest and most important section of the SRS. The customer requirements will be embodied within Section 2, but this section will give the D-requirements that are used to guide the project’s software design, implementation, and testing.

Each requirement in this section should be:
•Correct
•Traceable (both forward and backward to prior/future artifacts)
•Unambiguous
•Verifiable (i.e., testable)
•Prioritized (with respect to importance and/or stability)
•Complete
•Consistent
•Uniquely identifiable (usually via numbering like 3.4.5.6)

Attention should be paid to the carefuly organize the requirements presented in this section so that they may easily accessed and understood. Furthermore, this SRS is not the software design document, therefore one should avoid the tendency to over-constrain (and therefore design) the software project within this SRS. 3.1 External Interface Requirements

3.1.1 User Interfaces
3.1.2 Hardware Interfaces
3.1.3 Software Interfaces
3.1.4 Communications Interfaces
3.2 Requirements
This section describes different types of users of the system in 3.3.1. In the following paragraph 3.3.2, the functional requirements for each type of user are listed. 3.3.3 Lists the non-functional requirements of the system.

Users
Three types of users should be able to use the system: customer, employee and administrator. Customers are users who visit the website and can create orders by customizing pizzas, selecting products and entering customer details. Employees are the group of users that work with the ordering system on a daily basis. Employees will have their own accounts to log on to. They are the ones responsible for processing orders. Since Customer users do not need a log in, employees who process telephone orders can use the system as a Customer and enter the telephone order directly into the system as they take the order from the calling customer. The administrator, or super user, has the ultimate control of the system, he can add, change or delete ingredients and products, as well as add, change, or delete employee accounts.

Functional requirements
1 Customers
1.1 The user must be able to create a new order.
1.2 The user must be able to customize a pizza by:
1.2.1 The user must be able to view a list of available ingredients. 1.2.2 The user must be able to add an ingredient to a custom pizza 1.2.3 The user must be able to remove an ingredient from a custom pizza 1.2.4 The user must be able to get graphical feedback from selecting ingredients. A photo of a pizza will contain the newly selected ingredient combined with previous selected ingredients.

1.3 The user must be able to add a custom pizza to an order. 1.4 The user must be able to view a list of available non-pizza products. 1.5 The user must be able to add non-pizza products to an order. 1.6 The user must be able to see a list of custom pizzas and non-pizza products that are added to the order.

1.7 The user must be able to change the amount of a custom pizza. 1.8 The user must be able to change the amount of a non-pizza product. 1.9 The user must be able to delete a custom pizza from an order. 1.10 The user must be able to delete a non-pizza product from an order. 1.11 The user must be able to see the total price of an order. 1.12 The user must be able to choose a delivery date and time that is up to two weeks ahead.

1.13 The user must be able to add the name and address of the customer. 1.14 The user must be able to clear the current order to start a new one. 1.15 The user must be able to confirm the order.
2 Employees
2.1 The employee must be able to log in and out.
2.2 The employee must be able to view a list of available orders and their custom pizzas.
2.3 The employee must be able to mark orders as “prepared”.
2.4 The employee must be able to mark order as “delivered”
2.5 The employee must be able to mark order as “failure to deliver”
2.6 Only users with respective rights (employee) must be able to use all these “Employees” features.

3 Administrators
3.1 The administrator must be able to log in and out.
3.2 The administrator must be able to add/delete/edit orders. 3.3 The administrator must be able to add/delete/edit ingredients. 3.4 The administrator must be able to add/delete/edit non-pizza products. 3.5 The administrator must be able to add/delete/edit other users. 3.6 The administrator must be able to view an order log.

3.7 Only users with respective rights (administrators) must be able to use all these “Administrators” features.
.
3.2.1.1 Introduction
3.2.1.2 Inputs
3.2.1.3 Processing
3.2.1.4 Outputs
3.2.1.5 Error Handling
3.2.2

3.3 Use Cases
Three main use cases are identified: ordering, order processing and administration. The following paragraphs describe each use case in more detail. Ordering

The first use case is ordering. To order, a potential customer must first know what he can choose from (“What’s on the menu?”). For ordering custom pizzas a customer will have to know the ingredients he can choose from and how choosing ingredients will influence the total price. Customers pick ingredients for their pizza and sometimes they want a double portion of specific ingredients. When a customer is done choosing his pizza, he may want to order several pizzas of the same configuration. A customer may also want to order non-pizza side orders, such as drinks and salads. Also the customer will have to provide his name, address and telephone number. A customer can also pick another delivery date and time if they wish for the order to be delivered on a later date and time. Customers can order up to two weeks in advance.

Order processing
When an order has been confirmed by a customer order processing begins. Throughout the order processing the order status will be updated and the customer will be notified. New orders will show up in a list for the employees in the kitchen. They need to state which products are ordered and which ingredients are chosen for the custom pizzas. The kitchen employees have to look at the order and decide if they can prepare the order or not. When the decision is made, the order status will change and the customer will be notified. After preparing the order the order status will be updated and the delivery employees will take over. They will look up the name and address, and deliver the order. The customer will also be notified when the order is prepared and ready to be delivered. When delivery has been completed or failed, the order status will be changed once more. Administration

Custom pizzas are made by selecting several ingredients, the list of available ingredients and their prices are administrated by an employee, for instance the manager. Administration includes added, editing and deleting ingredients. Besides the administration of ingredients, the non-pizza side orders must also be administrated. Administrators also need to have logs of previous orders.

3.5 Non-Functional Requirements
As an operational requirement, the system will run as a database with a website as user interface. As performance requirement the system must be accessible 24 hours a day, seven days a week. Due to the nature of the system as an ordering website, the system must have a low response time, preferably shorter than second, with a maximum of five seconds. The exception is viewing order logs which could have a higher response time (of seconds) as the log increases in size over time. Due to the low complexity of the system, no problems with response time are expected. Customers who visit the website to order will get a sessionID for their visit, which is used to identify them while using the system. For every action they take, a timestamp is stored. From time to time a service on the server will scan sessionID’s and timestamps. SessionID’s which have not been active for more than three hours will be deleted along with the corresponding ordering information 3.5.1 Performance

3.5.2 Reliability
3.5.3 Availability
3.5.4 Security
3.5.5 Maintainability
3.5.6 Portability
3.6 Inverse Requirements
State any *useful* inverse requirements.

3.7 Design Constraints
Specify design constrains imposed by other standards, company policies, hardware limitation, etc. that will impact this software project. 3.8 Logical Database Requirements
Will a database be used? If so, what logical requirements exist for data formats, storage capabilities, data retention, data integrity, etc. 3.9 Other Requirements
Catchall section for any additional requirements.
4. Analysis Models
List all analysis models used in developing specific requirements previously given in this SRS. Each model should include an introduction and a narrative description. Furthermore, each model should be traceable the SRS’s requirements. 4.1 Sequence Diagrams

4.3 Data Flow Diagrams (DFD)
4.2 State-Transition Diagrams (STD)
4.3 Entity Relationship Diagram(ERD)

5. Change Management Process
Identify and describe the process that will be used to update the SRS, as needed, when project scope or requirements change. Who can submit changes and by what means, and how will these changes be approved. A. Appendices

Appendices may be used to provide additional (and hopefully helpful) information. If present, the SRS should explicitly state whether the information contained within an appendix is to be considered as a part of the SRS’s overall set of requirements.

Example Appendices could include (initial) conceptual documents for the software project, marketing materials, minutes of meetings with the customer(s), etc.