0% found this document useful (0 votes)
61 views14 pages

Srssss

The document describes a cafeteria ordering system that allows patrons to view menus, order meals, and have them delivered within a specified time window. It outlines the normal flow and exceptions of ordering a single meal, as well as alternative flows for ordering multiple or identical meals. It also covers registering for payroll deduction and modifying menus.

Uploaded by

Aleeza Anjum
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
61 views14 pages

Srssss

The document describes a cafeteria ordering system that allows patrons to view menus, order meals, and have them delivered within a specified time window. It outlines the normal flow and exceptions of ordering a single meal, as well as alternative flows for ordering multiple or identical meals. It also covers registering for payroll deduction and modifying menus.

Uploaded by

Aleeza Anjum
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 14

Software

Requirements Specification for Cafeteria Ordering System


Page
4
Copyright © 2002 by Karl E. Wiegers. All Rights Reserved.
Description:
A Patron accesses the Cafeteria Ordering System from the corporate
intranet or from
home, optionally views the menu for a specific date,
selects food items, and places an order for a meal to be delivered to a
specified location within a specified 15
-
minute time window.
Preconditions:
1.
Patron is logged into COS.
2.
Patron is registered for m
eal payments by payroll deduction.
Postconditions:
1.
Meal order is stored in COS with a status of “accepted”.
2.
Inventory of available food items is updated to reflect items in this
order.
3.
Remaining delivery capacity for the requested time window is
updated t
o reflect this delivery request.
Normal Flow:
1.0 Order a Single Meal
1.
Patron asks to view menu for a specified date.
2.
System displays menu of available food items and the daily special.
3.
Patron selects one or more food items from menu.
4.
Patron indicates that
meal order is complete.
5.
System displays ordered menu items, individual prices, and total
price, including any taxes and delivery charge.
6.
Patron confirms meal order or requests to modify meal order (back to
step 3).
7.
System displays available delivery times
for the delivery date.
8.
Patron selects a delivery time and specifies the delivery location.
9.
Patron specifies payment method.
10.
System confirms acceptance of the order.
11.
System sends Patron an e
-
mail confirming order details, price, and
delivery instructions.
12.
System stores order in database, sends e
-
mail to notify Cafeteria
Staff, sends food item information to Cafeteria Inventory System, and
updates available delivery times.
Alternative Flows:
1.1 Order multiple meals
(branch after step 4)
1.
Patron asks to orde
r another meal.
2.
Return to step 2.
1.2 Order multiple identical meals
(after step 3)
1.
Patron requests a specified number of identical meals.
2.
Return to step 4.
1.3. Order the daily special
(after step 2)
1.
Patron orders the daily special from the menu.
2.
Return
to step 5.
Exceptions:
1.0.E.1 Current time is after order cutoff time
(at step 1)
1.
System informs Patron that it’s too late to place an order for today.
2a.
Patron cancels the meal order.
2b.
System terminates use case.
3a.
Patron requests to select a
nother date.
3b.
System restarts use case.
1.0.E.2 No delivery times left
(at step 1)
Software
Requirements Specification for Cafeteria Ordering System
Page
5
Copyright © 2002 by Karl E. Wiegers. All Rights Reserved.
1.
System informs Patron that no delivery times are available for the
meal date.
2a.
Patron cancels the meal order.
2b.
System terminates use case.
3.
Patron requests to
pick the order up at the cafeteria (skip steps 7
-
8).
1.2.E.1 Can’t fulfill specified number of identical meals
(at step 1)
1.
System informs Patron of the maximum number of identical meals it
can supply.
2.
Patron changes number of identical meals ordered or c
ancels meal
order.
Includes:
None
Priority:
High
Frequency of Use:
Approximately 400 users, average of one usage per day
Business Rules:
BR
-
1, BR
-
2, BR
-
3, BR
-
4, BR
-
8, BR
-
11, BR
-
12, BR
-
33
Special
Requirements:
1.
Patron shall be able to cancel the meal or
der at any time prior to
confirming the order.
2.
Patron shall be able to view all meals he ordered within the previous
six months and repeat one of those meals as the new order, provided
that all food items are available on the menu for the requested
deliver
y date. (Priority = medium)
Assumptions:
1.
Assume that 30 percent of Patrons will order the daily special
(source: previous six months of cafeteria data).
Notes and Issues:
1.
The default date is the current date if the Patron is using the system
before today
’s order cutoff time. Otherwise, the default date is the
next day that the cafeteria is open.
2.
If Patron doesn’t want to have the meal delivered, the precondition
requiring registration for payroll deduction is not applicable.
3.
Peak usage load for this use c
ase is between 8:00am and 10:00am
local time.
3.5
Register for Payroll Deduction
Use Case ID:
5
Use Case Name:
Register for Payroll Deduction
Created By:
Karl Wiegers
Last Updated By:
Chris Zambito
Date Created:
October 21, 2002
Date Last Updated:
Octobe
r 31, 2002
Actors:
Patron, Payroll System
Description:
Cafeteria patrons who use the Cafeteria Ordering System and have meals
delivered must be registered for payroll deduction. For noncash
purchases made through the COS, the cafeteria will issue a payme
nt
request to the Payroll System, which will deduct the meal costs from the
next scheduled employee paycheck or payday direct deposit.
Preconditions:
Patron is logged into COS.
Postconditions:
Patron is registered for payroll deduction.
Normal Flow:
5.0
Register for Payroll Deduction
1.
Patron requests to register for payroll deduction.
Software
Requirements Specification for Cafeteria Ordering System
Page
6
Copyright © 2002 by Karl E. Wiegers. All Rights Reserved.
2.
System invokes Authenticate User’s Identity use case.
3.
System asks Payroll System if Patron is eligible to register for payroll
deduction.
4.
Payroll System confirms that Patron
is eligible.
5.
System informs Patron that he is eligible for payroll deduction.
6.
System asks Patron to confirm his desire to register for payroll
deduction.
7.
Patron confirms desire to register for payroll deduction.
8.
System asks Payroll System to establish pay
roll deduction for Patron.
9.
Payroll System confirms that payroll deduction is established.
10.
System informs Patron that payroll deduction is established and
provides confirmation number of the registration transaction.
Alternative Flows:
None
Exceptions:
5.
0.E.1 Patron identity authentication fails
(at step 2)
1.
System gives user two more opportunities for correct identity
authentication.
2a.
If authentication is successful, Patron proceeds with use case.
2b.
If authentication fails after three tries, Syste
m notifies Patron, logs
invalid authentication attempt, and terminates use case.
5.0.E.2 Patron is not eligible for payroll deduction
(at step 4)
1.
System informs Patron that he is not eligible for payroll deduction
and gives the reason why.
2.
System te
rminates use case.
5.0.E.3 Patron is already enrolled for payroll deduction
(at step 4)
1.
System informs Patron that he is already registered for payroll
deduction.
2.
System terminates use case.
Includes:
Authenticate User’s Identity
Priority:
High
F
requency of Use:
Once per employee on average
Business Rules:
BR
-
86 and BR
-
88 govern an employee’s eligibility to enroll for payroll
deduction.
Special
Requirements:
1.
User authentication is performed per corporate standards for medium
-
security application
s.
Assumptions:
None
Notes and Issues:
1.
Expect high frequency of executing this use case within first 2 weeks
after system is released.
3.11
Modify Menu
Use Case ID:
11
Use Case Name:
Modify Menu
Created By:
Karl Wiegers
Last Updated By:
Date Created:
O
ctober 21, 2002
Date Last Updated:
Actors:
Menu Manager
Description:
The cafeteria Menu Manager may modify the menu of available food
Software
Requirements Specification for Cafeteria Ordering System
Page
7
Copyright © 2002 by Karl E. Wiegers. All Rights Reserved.
items and prices for a specified date to reflect changes in availability or
prices or to define daily meal specials.
P
reconditions:
Menus already exist in the system.
Postconditions:
Modified menu has been saved.
Normal Flow:
11.0 Edit Existing Menu
1.
Menu Manager requests to view the menu for a specific date.
2.
System displays the menu.
3.
Menu Manager modifies the menu to ad
d new food items, remove or
change food items, create or change a meal special, or change prices.
4.
Menu Manager requests to save the modified menu.
5.
System saves modified menu.
Alternative Flows:
None
Exceptions:
11.0.E.1 No menu exists for specified date
(at step 1)
1.
System informs Menu Manager that no menu exists for the specified
date.
2.
System asks Menu Manager if he would like to create a menu for the
specified date.
3a.
Menu Manager says yes.
3b.
System invokes Create Menu use case.
4a.
Menu Manage
r says no.
4b.
System terminates use case.
11.0.E.2 Date specified is in the past
(at step 1)
1.
System informs Menu Manager that the menu for the requested date
cannot be modified.
2.
System terminates use case.
Includes:
Create Menu
Priority:
High
Frequenc
y of Use:
Approximately 20 times per week by one user
Business Rules:
BR
-
24
Special
Requirements:
1.
The Menu Manager may cancel out of the menu modification
function at any time. If the menu has been changed, the system shall
request confirmation of the ca
ncellation.
Assumptions:
1.
A menu will be created for every official Process Impact business
day, including weekends and holidays in which employees are
scheduled to be on site.
Notes and Issues:
1.
Certain food items will not be deliverable, so the menu pres
ented to
the Patrons of the Cafeteria Ordering System for delivery will not
always exactly match the menu available for pickup in the cafeteria.
The menu shall indicate which items may not be delivered. The
system shall not permit a Patron to order those i
tems for delivery.
Software
Requirements Specification for Cafeteria Ordering System
Page
8
Copyright © 2002 by Karl E. Wiegers. All Rights Reserved.
4.
External Interface Requirements
4.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
[4].
UI
-
2:
The system shall provide a hel
p link from each displayed HTML page to explain how
to use that page.
UI
-
3:
The Web pages shall permit complete navigation and food item selection using the
keyboard alone, in addition to using mouse and keyboard combinations.
4.2
Hardware Interfaces
No hardwa
re interfaces have been identified.
4.3
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 cur
rent 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 for payroll deduction.
SI
-
2.2:
To allow a Patron to unregister for payr
oll deduction.
SI
-
2.3:
To check whether a patron is registered 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.
4.4
Communications Interfaces
CI
-
1:
The Cafeteria Ordering System shall send an e
-
mail message to the Patron to confirm
acceptance of an order, price, and delivery instructions.
C
I
-
2:
The Cafeteria Ordering System shall send an e
-
mail message to the Patron to report
any problems with the meal order or delivery after the order is accepted.
Software
Requirements Specification for Cafeteria Ordering System
Page
9
Copyright © 2002 by Karl E. Wiegers. All Rights Reserved.
5.
Other Nonfunctional Requirements
5.1
Performance Requirements
PE
-
1:
The system shall accommodate 4
00 users during the peak usage time window of
8:00am to 10:00am local time, with an est
i
mated average session duration of 8
minutes.
PE
-
2:
All Web pages generated by the system shall be fully downloadable in no more than
10 seconds over a 40KBps modem conn
ection.
PE
-
3:
Responses to queries shall take no longer than 7 seconds to load onto the screen after
the user submits the query.
PE
-
4:
The system shall display confirmation messages to users within 4 seconds after the
user submits information to the syst
em.
5.2
Safety Requirements
No safety requirements have been identified.
5.3
Security Requirements
SE
-
1:
All network transactions that involve financial information or personally identifiable
information shall be encrypted per BR
-
33.
SE
-
2:
Users shall be required
to log in to the Cafeteria Ordering System for all operations
except viewing a menu.
SE
-
3:
Patrons shall log in according to the restricted computer system access policy per
BR
-
35.
SE
-
4:
The system shall permit only cafeteria staff members who are on the l
ist of
authorized Menu Managers to create or edit menus, per BR
-
24.
SE
-
5:
Only users who have been authorized for home access to the corporate Intranet may
use the COS from non
-
company locations.
SE
-
6:
The system shall permit Patrons to view only their own
previously placed orders, not
orders placed by other Patrons.
5.4
Software Quality Attributes
Availability
-
1:
The Cafeteria Ordering System shall be available to users on the corporate Intranet
and to dial
-
in users 99.9% of the time between 5:00am and midnigh
t local time and
95% of the time between midnight and 5:00am local time.
Robustness
-
1:
If the connection between the user and the system is broken prior to an order being
either confirmed or canceled, the Cafeteria Ordering System shall enable the user to
recover an incomplete order.
Appendix A: Data Dictionary
delivery instruction
=
+
+
+
+
patron name
patron phone number
meal date
delivery location
delivery time window
Software
Requirements Specification for Cafeteria Ordering System
Page
10
Copyright © 2002 by Karl E. Wiegers. All Rights Reserved.
delivery location
=
* building and room to which an ordered meal is to be delivered
*
delivery time
window
=
* 15
-
minute range during which an ordered meal is to be delivered;
must begin and end on quarter
-
hour intervals *
employee ID
=
* company ID number of the employee who placed a meal order; 6
-
character numeric string *
food it
em description
=
* text description of a food item on a menu; maximum 100 characters *
food item price
=
* pre
-
tax cost of a single unit of a menu food item, in dollars and cents
*
meal date
=
* the date the meal is to be delivered or picked up; format
MM/DD/YYYY; default = current date if the current time is before the
order cutoff time, else the next day; may not be prior to the current date
*
meal order
=
+
+
+
+
+
meal order number
order date
meal date
1:m{ordered food item}
delivery instruction
m
eal order status
meal order number
=
* a unique, sequential integer that the system assigns to each accepted
meal order; initial value is 1 *
meal order status
=
[ incomplete | accepted | prepared | pending delivery | delivered |
canceled ] * see state
-
transition diagram in Appendix B *
meal payment
=
+
+
payment amount
payment method
(payroll deduction transaction number)
menu
=
+
+
menu date
1:m{menu food item}
0:1{special}
menu date
=
* the date for which a specific menu of food items is availa
ble; format
MM/DD/YYYY *
menu food item
=
+
food item description
food item price
Software
Requirements Specification for Cafeteria Ordering System
Page
11
Copyright © 2002 by Karl E. Wiegers. All Rights Reserved.
order cutoff time
=
* the time of day before which all orders for that date must be placed *
order date
=
* the date on which a patron placed a meal order; format
MM/DD
/YYYY *
ordered food item
=
+
menu food item
quantity ordered
patron
=
+
+
+
+
patron name
employee ID
patron phone number
patron location
patron e
-
mail
patron e
-
mail
=
*e
-
mail address of the employee who placed a meal order; 50 character
alphanumeri
c*
patron location
=
* building and room numbers of the employee who placed a meal
order; 50 character alphanumeric *
patron name
=
* name of the employee who placed a meal order; 30 character
alphanumeric *
patron phone number
=
* telephone number of
the employee who placed a meal order; format
AAA
-
EEE
-
NNNN xXXXX for area code, exchange, number, and
extension *
payment amount
=
* total price of an order in dollars and cents, calculated per BR
-
12 *
payment method
=
[ payroll deduction | cash ] * othe
rs to be added beginning with release
2*
payroll deduction
transaction number
=
*8
-
digit sequential integer number that the Payroll System assigns to
each payroll deduction transaction that it accepts *
quantity ordered
=
* the number of units of eac
h food item that the Patron is ordering;
default = 1; maximum = quantity presently in inventory *
special
=
+
special description
special price
* the Menu Manager may define one or more special meals for each
menu, with a particular combination of food i
tems at a reduced price *
special description
=
* text description of a daily special meal; maximum 100 characters *
special price
=
* cost of a single unit of a daily special meal, in dollars and cents

You might also like