Software Requirements

Specification
for

Cafeteria Ordering System,

Release 1.0
Version 1.0 approved

Prepared by Karl Wiegers

Process Impact

September 28, 2013

Copyright © 2013 by Karl Wiegers and Seilevel

Software Requirements Specification for Cafeteria Ordering System Page ii

Table of Contents
Revision History.............................................................................................................................ii
1. Introduction..............................................................................................................................1
1.1 Purpose.........................................................................................................................................1
1.2 Document Conventions................................................................................................................1
1.3 Project Scope and Product Features.............................................................................................1
1.4 References....................................................................................................................................1
2. Overall Description..................................................................................................................1
2.1 Product Perspective......................................................................................................................1
2.2 User Classes and Characteristics..................................................................................................2
2.3 Operating Environment................................................................................................................3
2.4 Design and Implementation Constraints.......................................................................................3
2.5 Assumptions and Dependencies...................................................................................................3
3. System Features.......................................................................................................................3
3.1 Order Meals from Cafeteria..........................................................................................................3
3.1.1 Description...............................................................................................................................3
3.1.2 Functional Requirements..........................................................................................................3
3.2 Order Meals from Restaurants......................................................................................................5
3.3 Create, View, Modify, and Delete Meal Subscriptions................................................................5
3.4 Create, View, Modify, and Delete Cafeteria Menus....................................................................5
4. Data Requirements..................................................................................................................6
4.1 Logical Data Model......................................................................................................................6
4.2 Data Dictionary.............................................................................................................................6
4.3 Reports..........................................................................................................................................9
4.3.1 Ordered Meal History Report...................................................................................................9
4.4 Data Integrity, Retention, and Disposal........................................................................................9
5. External Interface Requirements.........................................................................................10
5.1 User Interfaces............................................................................................................................10
5.2 Software Interfaces.....................................................................................................................10
5.3 Hardware Interfaces....................................................................................................................10
5.4 Communications Interfaces........................................................................................................10
6. Quality Attributes..................................................................................................................11
6.1 Usability Requirements..............................................................................................................11
6.2 Performance Requirements.........................................................................................................11
6.3 Security Requirements................................................................................................................11
6.4 Safety Requirements...................................................................................................................11
6.5 Availability Requirements..........................................................................................................11
6.6 Robustness Requirements...........................................................................................................11
Appendix A: Analysis Models.....................................................................................................12

Revision History
Name Date Reason For Changes Version

Karl Wiegers 8/15/13 initial draft 1.0 draft 1

Karl Wiegers 9/28/13 baseline following changes after inspection 1.0 approved

Copyright © 2013 by Karl Wiegers and Seilevel

Software Requirements Specification for Cafeteria Ordering System Page 1

1. Introduction
1.1 Purpose
The purpose of this Software Requirements Specification (SRS) document is to define the
functional and non-functional requirements for the initial release (1.0) of the Student Relation
Office Management System (SROMS). It serves as a blueprint guiding the project team in
implementing and validating the system's functionality, outlining features, capabilities, and
constraints. By detailing both functional and non-functional requirements, this document ensures
that SROMS meets user needs while adhering to quality standards. It serves as a primary reference
for stakeholders involved in development, deployment, and maintenance, facilitating effective
communication and collaboration. Ultimately, this SRS aims to enable efficient management of
student relations within educational institutions.

1.2 Document Conventions

No special typographical conventions are used in this SRS.

1.3 Project Scope and Product Features

The SROMS will help staff of educational organizations, specifically schools, manage students
more easily and ensure quality without wasting too much time. A detailed description is available in
the Student Relation Office Management System Vision and Scope Document [1], along with
features planned to be implemented in whole or in part in this release.

1.4 References
1. The system includes references FAP to training portals for students, parents, faculty, and staff.,
https://fap.fpt.edu.vn.

2. Overall Description
2.1 Product Perspective
The Student Relation Office System is a new software system that replaces manual processes and
PC, Laptop, Tablet, Phone making the process of using the system simpler. The context diagram in
Figure 1 illustrates the external entities and system interfaces for version 1.0. This system is
expected to develop through several versions, eventually connecting with educational organizations,
specifically schools, to help manage students in the most modern way possible.

Copyright © 2013 by Karl Wiegers and Seilevel

Software Requirements Specification for Cafeteria Ordering System Page 2

Figure 1. Context diagram for release 1.0 of the Student Relation Office Management
System.

2.2 User Classes and Characteristics

Admin Manage all system users and always update the latest news from many different
platforms such as talk show activities, necessary news and main content statistics.
Club Manager Detailed management of clubs. Accept to be put into operation when clubs have all the
criteria for a club to operate normally and when a club is created it must bring many
benefits, specifically to students, and On the contrary, we will not accept operating
licenses for clubs that do not fully meet the criteria. has the right to stop the club's
operations when quality is not guaranteed and can also grant the right to re-operate the
club if there is a commitment.
Event Manager Create events for students to participate in, list participants of those events and
consider accepting student-created events.
Student Students are the ones who have the most information because they are always updated
on the system and have many benefits from creating and joining clubs to public and
individual events.

2.3 Operating Environment

OE-1: The SROMS shall operate correctly with the following web browsers: Windows
Internet Explorer versions 7, 8, and 9; Firefox versions 12 through 26; Google
Chrome (all versions); and Apple Safari versions 4.0 through 8.0.

Copyright © 2013 by Karl Wiegers and Seilevel

Software Requirements Specification for Cafeteria Ordering System Page 3

OE-2: The SROMS shall operate on a server running the current corporate-approved
versions of Red Hat Linux and Apache HTTP Server.
OE-3: The SROMS shall permit user access from the corporate Intranet, from a VPN
Internet connection, and by Android, iOS, and Windows smartphones and tablets.

2.4 Design and Implementation Constraints

CO-1: System design, code, and maintenance documentation must comply with the Process
Impact Intranet Development Standard, Version 1.3 [2].
CO-2: The system will use the educational institution's current standard SQL server
database.
CO-3: All HTML code shall conform to the HTML 5.0 standard.

2.5 Assumptions and Dependencies

AS-1: A system with a suitable user interface will be available for staff to handle
tasks specifically student management.
DE-1: None.

3. System Features
3.1 Manage Account
3.1.1 Description

Create and view accounts for each role in the system such as Event Manager, Club
Manager, Student.

3.1.2 Functional Requirements

Create Event Manager Account

Create an account with addable information facilities Education, Degree, Experience.

Create Club Manager Account

Create an account with addable information facilities Education, Degree, Experience.
View Account
The SROMS displays a list of all accounts with each specific position such as Manager,
Student
Delete Account
Change the status of each account.

3.2 Event Manager.

Update Event, Check request Event, View Events, Create Event, Check participant, View
participant, Evaluate participants

Copyright © 2013 by Karl Wiegers and Seilevel

Software Requirements Specification for Cafeteria Ordering System Page 4

3.3 Student
Participate in Events, Participate in Clubs, Sign Up To Club, View Activities Point, View Club
Check Participation Requests, View Club Point, Evaluate Members, View Members, Update
Role Member, Delete Member, View Event of Club, Create Event of Club, View News, View
Events, View Clubs.

3.4 Club manager

View Clubs Point,View Clubs Members Point, Delete Club, Accept/Decline Club, View
Clubs

4. Data Requirements
4.1 Logical Data Model

Figure . Partial data model for release 1.0 of the Cafeteria Ordering System.

4.2 Data Dictionary

Data Description Composition or Lengt Values
Element Data Type h
delivery where and to whom a meal is patron name
instruction to be delivered, if it isn't being +patron phone number
picked up in the cafeteria +meal date
+delivery location
+delivery time window
delivery building and room to which an alphanumeric 50 hyphens and
location ordered meal is to be commas permitted
delivered

Copyright © 2013 by Karl Wiegers and Seilevel

Software Requirements Specification for Cafeteria Ordering System Page 5

delivery time beginning time of a 15-minute time hh:mm local time; hh = 0-

window range on the meal date during 23 inclusive; mm =
which an ordered meal is to 00, 15, 30, or 45
be delivered;
employee ID company ID number of the integer 6
employee who placed a meal
order
food item ext description of a food item alphabetic 100
description on a menu
food item price pre-tax cost of a single unit of numeric, dollars and dd.cc
a menu food item cents
meal date the date the meal is to be date, MM/DD/YYYY 10 default = current
delivered or picked up date if the current
time is before the
order cutoff time,
else the next day;
cannot be prior to
current date
meal order details about a meal a Patron meal order number
ordered + order date
+ meal date
+ 1:m{ordered food
item}
+ delivery instruction
+ meal order status
meal order unique ID that COS assigns integer 7 initial value is 1
number to each accepted meal order
meal order status of a meal order that a alphabetic 16 incomplete,
status Patron initiated accepted, prepared,
pending delivery,
delivered, canceled
meal payment information about a payment payment amount
COS accepted for a meal + payment method
+ transaction number
menu list of food items available for menu date
purchase on a specific date + 1:m{menu food item}
menu date the date for which a specific date, MM/DD/YYYY 10
menu is available
menu food description of a menu item food item description
item + food item price
order cutoff the time of day before which time, HH:MM 5
time all meal orders for that date
must be placed
order date the date on which a patron date, MM/DD/YYYY 10
placed a meal order
ordered food one menu food item that a menu food item
item Patron requested as part of a + quantity ordered
meal order
patron a Process Impact employee patron name
who is authorized to order a + employee ID

Copyright © 2013 by Karl Wiegers and Seilevel

Software Requirements Specification for Cafeteria Ordering System Page 6

meal + patron phone number

+ patron location
+ patron email
patron email email address of the alphanumeric 50
employee who placed a meal
order
patron location building and room numbers of alphanumeric 50 hyphens and
the employee who placed a commas permitted
meal order
patron name name of the employee who alphabetic 30
placed a meal order
patron phone telephone number of the AAA-EEE-NNNN 18
number employee who placed a meal xXXXX for area code
order (A), exchange (E),
number (N), and
extension (X)
payment total price of an order in numeric, dollars and dddd.cc
amount dollars and cents, calculated cents
per BR-12
payment how the Patron is paying for a alphabetic 16 payroll deduction,
method meal he ordered cash, credit card,
debit card
quantity the number of units of each integer 4 default = 1;
ordered food item that the Patron is maximum =
ordering in a single meal quantity presently in
order inventory
transaction unique sequence number that integer 12
number COS assigns to each
payment transaction

Copyright © 2013 by Karl Wiegers and Seilevel

Software Requirements Specification for Cafeteria Ordering System Page 7

4.3 Reports

4.3.1 Ordered Meal History Report

Report ID: COS-RPT-1

Report Title: Ordered Meal History
Report Purpose: Patron wants to see a list of all meals that he had previously ordered
from the Process Impact cafeteria or local restaurants over a specified
time period up to six months prior to the current date, so he can reorder a
particular meal he liked.
Priority: Medium
Report Users: Patrons
Data Sources: Database of previously placed meal orders
Frequency and Report is generated on demand by a Patron. Data in the report is static.
Disposition; Report is displayed on user's web browser screen on a computer, tablet,
or smartphone. It can be printed if the display device permits printing.
Latency: Complete report must be displayed to Patron within 3 seconds after it is
requested.
Visual Layout: Landscape mode
Header and Footer: Report header shall contain the report title, Patron's name, and date
range specified. If printed, report footer shall show the page number.
Report Body: Fields shown and column headings:
 Order Number
 Meal Date
 Ordered From ("Cafeteria" or restaurant name)
 Items ordered (list all items in the meal order, their quantity, and their
prices)
 Total Food Price
 Tax
 Delivery Charge
 Total Price (sum of food item prices, tax, and delivery charge)

Selection Criteria: date range specified by Patron, inclusive of end points

Sort Criteria: reverse chronological order
End-of-Report None
Indicator:
Interactivity: Patron can drill down to see ingredients and nutritional information for
each item in the order
Security Access A Patron may retrieve only his own meal order history
Restrictions:

[Note: Other COS reports are not provided in this example.]

4.4 Data Integrity, Retention, and Disposal

DI-1: The COS shall retain Individual Patron meal orders for 6 months following the meal's
delivery date.
DI-2: The COS shall retain menus for one year following the menu date.

Copyright © 2013 by Karl Wiegers and Seilevel

Software Requirements Specification for Cafeteria Ordering System Page 8

5. External Interface Requirements

5.1 User Interfaces
UI-1: The Cafeteria Ordering System screen displays shall conform to the Process Impact
Internet Application User Interface Standard, Version 2.0 [3].
UI-2: The system shall provide a help link from each displayed webpage to explain how to
use that page.
UI-3: The webpages shall permit complete navigation and food item selection by using the
keyboard alone, in addition to using mouse and keyboard combinations.

5.2 Software Interfaces

SI-1: Cafeteria Inventory System
SI-1.1: The COS shall transmit the quantities of food items ordered to the Cafeteria
Inventory System through a programmatic interface.
SI-1.2: The COS shall poll the Cafeteria Inventory System to determine whether a
requested food item is available.
SI-1.3: When the Cafeteria Inventory System notifies the COS that a specific food
item is no longer available, the COS shall remove that food item from the
menu for the current date.
SI-2: Payroll System
The COS shall communicate with the Payroll System through a programmatic
interface for the following operations:

SI-2.1: To allow a Patron to register and unregister for payroll deduction.

SI-2.2: To inquire whether a Patron is registered for payroll deduction.
SI-2.3: To inquire whether a Patron is eligible to register for payroll deduction.
SI-2.4: To submit a payment request for a purchased meal.
SI-2.5: To reverse all or part of a previous charge because a patron rejected a meal or
wasn’t satisfied with it, or because the meal was not delivered per the
confirmed delivery instructions.

5.3 Hardware Interfaces

No hardware interfaces have been identified.

5.4 Communications Interfaces

CI-1: The COS shall send an email or text message (based on user account settings) to the
Patron to confirm acceptance of an order, price, and delivery instructions.
CI-2: The COS shall send an email or text message (based on user account settings) to the
Patron to report any problems with the meal order or delivery.

Copyright © 2013 by Karl Wiegers and Seilevel

Software Requirements Specification for Cafeteria Ordering System Page 9

6. Quality Attributes
6.1 Usability Requirements
USE-1: The COS shall allow a Patron to retrieve the previous meal ordered with a single
interaction.
USE-2: 95% of new users shall be able to successfully order a meal without errors on their
first try.

6.2 Performance Requirements

PER-1: The system shall accommodate a total of 400 users and a maximum of 100 concurrent
users during the peak usage time window of 9:00 A.M. to 10:00 A.M. local time, with
an estimated average session duration of 8 minutes.
PER-2: 95% of webpages generated by the COS shall download completely within 4 seconds
from the time the user requests the page over a 20Mbps or faster Internet connection.
PER-3: The system shall display confirmation messages to users within an average of 3
seconds and a maximum of 6 seconds after the user submits information to the
system.

6.3 Security Requirements

SEC-1: All network transactions that involve financial information or personally identifiable
information shall be encrypted per BR-33.
SEC-2: Users shall be required to log on to the COS for all operations except viewing a menu.
SEC-3: Only authorized Menu Managers shall be permitted to work with menus, per BR-24.
SEC-4: The system shall permit Patrons to view only orders that they placed.

6.4 Safety Requirements

SAF-1: The user shall be able to see a list of all ingredients in any menu items, with
ingredients highlighted that are known to cause allergic reactions in more than 0.5
percent of the North American population.

6.5 Availability Requirements

AVL-1: The COS shall be available at least 98% of the time between 5:00 A.M. and midnight
local time and at least 90% of the time between midnight and 5:00 A.M. local time,
excluding scheduled maintenance windows.

6.6 Robustness Requirements

ROB-1: If the connection between the user and the COS is broken prior to a new order being
either confirmed or terminated, the COS shall enable the user to recover an
incomplete order and continue working on it.

Copyright © 2013 by Karl Wiegers and Seilevel

Software Requirements Specification for Cafeteria Ordering System Page 10

Appendix A: Analysis Models

Figure 3. State-transition diagram create event status.

Copyright © 2013 by Karl Wiegers and Seilevel