Assessment Rubric Exemplary Accomplished Developing Beginning Points Available Comments 1. Title, Sections 1-4 of the SRS template are completed and provide meaningful technical specifications for your chosen system. Student effectively completed the assignment. Student partially completed the assignment. The student provided limited and meaningless substance completing the assignment. Student failed to complete the assignment. 50 2. For Appendix B: SA Level 0 DFD or for OO Use Case Diagram are included and correctly model your system. Student effectively completed the assignment. Student partially completed the assignment. The student provided limited and meaningless substance completing the assignment. Student failed to complete the assignment. 20 3. For Appendix B: Level 1 DFD or for OO Detailed use case descriptions are included and correctly model your system. Student effectively completed the assignment. Student partially completed the assignment. The student provided limited and meaningless substance completing the assignment. Student failed to complete the assignment. 20 4. Writing Format Write the paper in APA format. Grammatical, spelling or punctuation—the writing is grammatically correct, clear and concise.  The response is well formulated and easy to read and understand.  Correct terminology was used when needed. See references below: What is Plagiarism and How to Avoid It:  http://www.youtube.com/watch?v=eIsLV9zOOe0 Writing Help: http://apus.libguides.com/c.php?g=241212&p=1603794 Purdue Online Writing Lab: https://owl.english.purdue.edu/owl/resource/560/01/ APA and MLA Citation Game Home Page: http://depts.washington.edu/trio/quest/citation/apa_mla_citation_game/ Student effectively wrote the paper using provided format. Student partially wrote the paper using provided format. Student wrote the paper with limited and meaningless use of provided format Student failed to use provided format. 10 Total 100 Software Requirements Specification for <Project> Version 1.0 approved Prepared by <author> <organization> <date created> Table of Contents iiTable of Contents Revision History ii 1. Introduction 1 1.1 Purpose 1 1.2 Document Conventions 1 1.3 Intended Audience and Reading Suggestions 1 1.4 Product Scope 1 1.5 References 1 2. Overall Description 2 2.1 Product Perspective 2 2.2 Product Functions 2 2.3 User Classes and Characteristics 2 2.4 Operating Environment 2 2.5 Design and Implementation Constraints 2 2.6 User Documentation 2 2.7 Assumptions and Dependencies 3 3. External Interface Requirements 3 3.1 User Interfaces 3 3.2 Hardware Interfaces 3 3.3 Software Interfaces 3 3.4 Communications Interfaces 3 4. System Features 4 4.1 System Feature 1 4 4.2 System Feature 2 (and so on) 4 5. Other Nonfunctional Requirements 4 5.1 Performance Requirements 4 5.2 Safety Requirements 5 5.3 Security Requirements 5 5.4 Software Quality Attributes 5 5.5 Business Rules 5 6. Other Requirements 5 Appendix A: Glossary .

1. Assessment Rubric
Exemplary
Accomplished
Developing
Beginning
Points Available
Comments
1. Title, Sections 1-4 of the SRS template are completed and
provide meaningful technical specifications for your chosen
system.
Student effectively completed the assignment.
Student partially completed the assignment.
The student provided limited and meaningless substance
completing the assignment.
Student failed to complete the assignment.
50
2. For Appendix B: SA Level 0 DFD or for OO Use Case
Diagram are included and correctly model your system.
Student effectively completed the assignment.
Student partially completed the assignment.
The student provided limited and meaningless substance
completing the assignment.
Student failed to complete the assignment.
20
3. For Appendix B: Level 1 DFD or for OO Detailed use case

2. descriptions are included and correctly model your system.
Student effectively completed the assignment.
Student partially completed the assignment.
The student provided limited and meaningless substance
completing the assignment.
Student failed to complete the assignment.
20
4. Writing Format
Write the paper in APA format. Grammatical, spelling or
punctuation—the writing is grammatically correct, clear and
concise. The response is well formulated and easy to read and
understand. Correct terminology was used when needed. See
references below:
What is Plagiarism and How to Avoid It:
http://www.youtube.com/watch?v=eIsLV9zOOe0
Writing Help:
http://apus.libguides.com/c.php?g=241212&p=1603794
Purdue Online Writing Lab:
https://owl.english.purdue.edu/owl/resource/560/01/
APA and MLA Citation Game Home Page:
http://depts.washington.edu/trio/quest/citation/apa_mla_citation
_game/
Student effectively wrote the paper using provided format.
Student partially wrote the paper using provided format.
Student wrote the paper with limited and meaningless use of
provided format
Student failed to use provided format.
10
Total
100

3. Software Requirements Specification
for
<Project>
Version 1.0 approved
Prepared by <author>
<organization>
<date created>
Table of Contents
iiTable of Contents
Revision History
ii
1.
Introduction
1
1.1
Purpose
1
1.2
Document Conventions
1
1.3
Intended Audience and Reading Suggestions
1
1.4
Product Scope
1
1.5

4. References
1
2.
Overall Description
2
2.1
Product Perspective
2
2.2
Product Functions
2
2.3
User Classes and Characteristics
2
2.4
Operating Environment
2
2.5
Design and Implementation Constraints
2
2.6
User Documentation
2
2.7
Assumptions and Dependencies
3
3.
External Interface Requirements
3
3.1
User Interfaces
3
3.2
Hardware Interfaces
3
3.3

5. Software Interfaces
3
3.4
Communications Interfaces
3
4.
System Features
4
4.1
System Feature 1
4
4.2
System Feature 2 (and so on)
4
5.
Other Nonfunctional Requirements
4
5.1
Performance Requirements
4
5.2
Safety Requirements
5
5.3
Security Requirements
5
5.4
Software Quality Attributes
5
5.5
Business Rules
5
6.
Other Requirements
5
Appendix A: Glossary

6. 5
Appendix B: Analysis Models
5
Appendix C: To Be Determined List
6
Revision History
Name
Date
Reason For Changes
Version
1. Introduction
1.1 Purpose
<Identify the product whose software requirements are specified
in this document, including the revision or release number.
Describe the scope of the product that is covered by this SRS,
particularly if this SRS describes only part of the system or a
single subsystem.>
1.2 Document Conventions
<Describe any standards or typographical conventions that were
followed when writing this SRS, such as fonts or highlighting
that have special significance. For example, state whether
priorities for higher-level requirements are assumed to be
inherited by detailed requirements, or whether every
requirement statement is to have its own priority.>
1.3 Intended Audience and Reading Suggestions

7. <Describe the different types of reader that the document is
intended for, such as developers, project managers, marketing
staff, users, testers, and documentation writers. Describe what
the rest of this SRS contains and how it is organized. Suggest a
sequence for reading the document, beginning with the
overview sections and proceeding through the sections that are
most pertinent to each reader type.>
1.4 Product Scope
<Provide a short description of the software being specified and
its purpose, including relevant benefits, objectives, and goals.
Relate the software to corporate goals or business strategies. If
a separate vision and scope document is available, refer to it
rather than duplicating its contents here.>
1.5 References
<List any other documents or Web addresses to which this SRS
refers. These may include user interface style guides, contracts,
standards, system requirements specifications, use case
documents, or a vision and scope document. Provide enough
information so that the reader could access a copy of each
reference, including title, author, version number, date, and
source or location.>
2. Overall Description
2.1 Product Perspective
<Describe the context and origin of the product being specified
in this SRS. For example, state whether this product is a follow-
on member of a product family, a replacement for certain
existing systems, or a new, self-contained product. If the SRS
defines a component of a larger system, relate the requirements
of the larger system to the functionality of this software and
identify interfaces between the two. A simple diagram that
shows the major components of the overall system, subsystem
interconnections, and external interfaces can be helpful.>

8. 2.2 Product Functions
<Summarize the major functions the product must perform or
must let the user perform. Details will be provided in Section 3,
so only a high level summary (such as a bullet list) is needed
here. Organize the functions to make them understandable to
any reader of the SRS. A picture of the major groups of related
requirements and how they relate, such as a top level data flow
diagram or object class diagram, is often effective.>
2.3 User Classes and Characteristics
<Identify the various user classes that you anticipate will use
this product. User classes may be differentiated based on
frequency of use, subset of product functions used, technical
expertise, security or privilege levels, educational level, or
experience. Describe the pertinent characteristics of each user
class. Certain requirements may pertain only to certain user
classes. Distinguish the most important user classes for this
product from those who are less important to satisfy.>
2.4 Operating Environment
<Describe the environment in which the software will operate,
including the hardware platform, operating system and versions,
and any other software components or applications with which
it must peacefully coexist.>
2.5 Design and Implementation Constraints
<Describe any items or issues that will limit the options
available to the developers. These might include: corporate or
regulatory policies; hardware limitations (timing requirements,
memory requirements); interfaces to other applications; specific
technologies, tools, and databases to be used; parallel
operations; language requirements; communications protocols;
security considerations; design conventions or programming
standards (for example, if the customer’s organization will be
responsible for maintaining the delivered software).>

9. 2.6 User Documentation
<List the user documentation components (such as user
manuals, on-line help, and tutorials) that will be delivered along
with the software. Identify any known user documentation
delivery formats or standards.>
2.7 Assumptions and Dependencies
<List any assumed factors (as opposed to known facts) that
could affect the requirements stated in the SRS. These could
include third-party or commercial components that you plan to
use, issues around the development or operating environment, or
constraints. The project could be affected if these assumptions
are incorrect, are not shared, or change. Also identify any
dependencies the project has on external factors, such as
software components that you intend to reuse from another
project, unless they are already documented elsewhere (for
example, in the vision and scope document or the project
plan).>
3. External Interface Requirements
3.1 User Interfaces
<Describe the logical characteristics of each interface between
the software product and the users. This may include sample
screen images, any GUI standards or product family style guides
that are to be followed, screen layout constraints, standard
buttons and functions (e.g., help) that will appear on every
screen, keyboard shortcuts, error message display standards,
and so on. Define the software components for which a user
interface is needed. Details of the user interface design should
be documented in a separate user interface specification.>
3.2 Hardware Interfaces
<Describe the logical and physical characteristics of each
interface between the software product and the hardware
components of the system. This may include the supported

10. device types, the nature of the data and control interactions
between the software and the hardware, and communication
protocols to be used.>
3.3 Software Interfaces
<Describe the connections between this product and other
specific software components (name and version), including
databases, operating systems, tools, libraries, and integrated
commercial components. Identify the data items or messages
coming into the system and going out and describe the purpose
of each. Describe the services needed and the nature of
communications. Refer to documents that describe detailed
application programming interface protocols. Identify data that
will be shared across software components. If the data sharing
mechanism must be implemented in a specific way (for
example, use of a global data area in a multitasking operating
system), specify this as an implementation constraint.>
3.4 Communications Interfaces
<Describe the requirements associated with any communications
functions required by this product, including e-mail, web
browser, network server communications protocols, electronic
forms, and so on. Define any pertinent message formatting.
Identify any communication standards that will be used, such as
FTP or HTTP. Specify any communication security or
encryption issues, data transfer rates, and synchronization
mechanisms.>
4. System Features
<This template illustrates organizing the functional
requirements for the product by system features, the major
services provided by the product. You may prefer to organize
this section by use case, mode of operation, user class, object
class, functional hierarchy, or combinations of these, whatever
makes the most logical sense for your product.>
4.1 System Feature 1

11. <Don’t really say “System Feature 1.” State the feature name in
just a few words.>
4.1.1
Description and Priority
<Provide a short description of the feature and indicate whether
it is of High, Medium, or Low priority. You could also include
specific priority component ratings, such as benefit, penalty,
cost, and risk (each rated on a relative scale from a low of 1 to a
high of 9).>
4.1.2
Stimulus/Response Sequences
<List the sequences of user actions and system responses that
stimulate the behavior defined for this feature. These will
correspond to the dialog elements associated with use cases.>
4.1.3
Functional Requirements
<Itemize the detailed functional requirements associated with
this feature. These are the software capabilities that must be
present in order for the user to carry out the services provided
by the feature, or to execute the use case. Include how the
product should respond to anticipated error conditions or
invalid inputs. Requirements should be concise, complete,
unambiguous, verifiable, and necessary. Use “TBD” as a
placeholder to indicate when necessary information is not yet
available.>
<Each requirement should be uniquely identified with a
sequence number or a meaningful tag of some kind.>
REQ-1:

12. REQ-2:
4.2 System Feature 2 (and so on)
5. Other Nonfunctional Requirements
5.1 Performance Requirements
<If there are performance requirements for the product under
various circumstances, state them here and explain their
rationale, to help the developers understand the intent and make
suitable design choices. Specify the timing relationships for real
time systems. Make such requirements as specific as possible.
You may need to state performance requirements for individual
functional requirements or features.>
5.2 Safety Requirements
<Specify those requirements that are concerned with possible
loss, damage, or harm that could result from the use of the
product. Define any safeguards or actions that must be taken, as
well as actions that must be prevented. Refer to any external
policies or regulations that state safety issues that affect the
product’s design or use. Define any safety certifications that
must be satisfied.>
5.3 Security Requirements
<Specify any requirements regarding security or privacy issues
surrounding use of the product or protection of the data used or
created by the product. Define any user identity authentication
requirements. Refer to any external policies or regulations
containing security issues that affect the product. Define any
security or privacy certifications that must be satisfied.>
5.4 Software Quality Attributes
<Specify any additional quality characteristics for the product
that will be important to either the customers or the developers.

13. Some to consider are: adaptability, availability, correctness,
flexibility, interoperability, maintainability, portability,
reliability, reusability, robustness, testability, and usability.
Write these to be specific, quantitative, and verifiable when
possible. At the least, clarify the relative preferences for
various attributes, such as ease of use over ease of learning.>
5.5 Business Rules
<List any operating principles about the product, such as which
individuals or roles can perform which functions under specific
circumstances. These are not functional requirements in
themselves, but they may imply certain functional requirements
to enforce the rules.>
6. Other Requirements
<Define any other requirements not covered elsewhere in the
SRS. This might include database requirements,
internationalization requirements, legal requirements, reuse
objectives for the project, and so on. Add any new sections that
are pertinent to the project.>
Appendix A: Glossary
<Define all the terms necessary to properly interpret the SRS,
including acronyms and abbreviations. You may wish to build a
separate glossary that spans multiple projects or the entire
organization, and just include terms specific to a single project
in each SRS.>
Appendix B: Analysis Models
<Optionally, include any pertinent analysis models, such as data
flow diagrams, class diagrams, state-transition diagrams, or
entity-relationship diagrams.>
Appendix C: To Be Determined List

14. <Collect a numbered list of the TBD (to be determined)
references that remain in the SRS so they can be tracked to
closure.>
Copyright © 1999 by Karl E. Wiegers. Permission is granted to
use, modify, and distribute this document.
Software Requirements Specification
for
Cafeteria Ordering System, Release 1.0
Version 1.0 approved
Prepared by Karl Wiegers
Process Impact
November 4, 2002
Table of Contents
iiTable of Contents
Revision History
ii
1.
Introduction
1
1.1
Purpose
1
1.2
Project Scope and Product Features
1

15. 1.3
References
1
2.
Overall Description
1
2.1
Product Perspective
1
2.2
User Classes and Characteristics
1
2.3
Operating Environment
2
2.4
Design and Implementation Constraints
2
2.5
User Documentation
2
2.6
Assumptions and Dependencies
2
3.
System Features
2
3.1
Order Meals
2
3.2
Create, View, Modify, and Delete Meal Subscriptions
6
3.3
Register for Meal Payment Options
6

16. 3.4
Request Meal Delivery
6
3.5
Create, View, Modify, and Delete Cafeteria Menus
6
4.
External Interface Requirements
6
4.1
User Interfaces
6
4.2
Hardware Interfaces
7
4.3
Software Interfaces
7
4.4
Communications Interfaces
7
5.
Other Nonfunctional Requirements
7
5.1
Performance Requirements
7
5.2
Safety Requirements
8
5.3
Security Requirements
8
5.4
Software Quality Attributes
8

17. Appendix A: Data Dictionary and Data Model
8
Appendix B: Analysis Models
12
Revision History
Name
Date
Reason For Changes
Version
Karl Wiegers
10/21/02
initial draft
1.0 draft 1
Karl Wiegers
11/4/02
baseline following changes after inspection
1.0 approved1. Introduction
1.1 Purpose
This SRS describes the software functional and nonfunctional
requirements for release 1.0 of the Cafeteria Ordering System
(COS). This document is intended to be used by the members of
the project team that will implement and verify the correct
functioning of the system. Unless otherwise noted, all
requirements specified here are high priority and committed for
release 1.0.
1.2 Project Scope and Product Features
The Cafeteria Ordering System will permit Process Impact
employees to order meals from the company cafeteria on-line to
be delivered to specified campus locations. A detailed project
description is available in the Cafeteria Ordering System Vision
and Scope Document [1]. The section in that document titled
“Scope of Initial and Subsequent Releases” lists the features

18. that are scheduled for full or partial implementation in this
release.
1.3 References
1. Wiegers, Karl. Cafeteria Ordering System Vision and Scope
Document,
www.processimpact.com/projects/COS/COS_vision_and_scope.
doc
2. Wiegers, Karl. Process Impact Intranet Development
Standard, Version 1.3,
www.processimpact.com/corporate/standards/PI_intranet_dev_st
d.doc
3. Zambito, Christine. Process Impact Business Rules Catalog,
www.processimpact.com/corporate/policies/PI_business_rules.d
oc
4. Zambito, Christine. Process Impact Internet Application User
Interface Standard, Version 2.0,
www.processimpact.com/corporate/standards/PI_internet_ui_std
.doc
2. Overall Description
2.1 Product Perspective
The Cafeteria Ordering System is a new system that replaces the
current manual and telephone processes for ordering and
picking up lunches in the Process Impact cafeteria. The context
diagram in Figure 1 illustrates the external entities and system
interfaces for release 1.0. The system is expected to evolve over
several releases, ultimately connecting to the Internet ordering
services for several local restaurants and to credit and debit
card authorization services.
2.2 User Classes and Characteristics
Patron (favored)

19. A Patron is a Process Impact employee at the corporate campus
in Clackamas, Oregon, who wishes to order meals to be
delivered from the company cafeteria. There are about 600
potential Patrons, of which an estimated 400 are expected to use
the Cafeteria Ordering System an average of 4 times per week
each (source: current cafeteria usage data). Patrons will
sometimes order multiple meals for group events or guests. An
estimated 90 percent of orders will be placed using the
corporate Intranet, with 10 percent of orders being placed from
home. All Patrons have Intranet access from their offices. Some
Patrons will wish to set up meal subscriptions, either to have
the same meal to be delivered every day or to have the day’s
meal special delivered automatically. A Patron must be able to
override a subscription for a specific day.
Cafeteria Staff
The Process Impact cafeteria currently employs about 20
Cafeteria Staff, who will receive orders from the Cafeteria
Ordering System, prepare meals, package them for delivery,
print delivery instructions, and request delivery. Most of the
Cafeteria Staff will need to be trained in the use of the
computer, the Web browser, and the Cafeteria Ordering System.
Menu Manager
The Menu Manager is a cafeteria employee, perhaps the
cafeteria manager, who is responsible for establishing and
maintaining daily menus of the food items available from the
cafeteria and the times of day that each item is available. Some
menu items may not be available for delivery. The Menu
Manager will also define the cafeteria’s daily specials. The
Menu Manager will need to edit the menus periodically to
reflect planned food items that are not available or price
changes.

20. Meal Deliverer
As the Cafeteria Staff prepare orders for delivery, they will
print delivery instructions and issue delivery requests to the
Meal Deliverer, who is either another cafeteria employee or a
contractor. The Meal Deliverer will pick up the food and
delivery instructions for each meal and deliver it to the Patron.
The Meal Deliverers’ primary interactions with the system will
be to reprint the delivery instructions on occasion and to
confirm that a meal was (or was not) delivered.2.3 Operating
Environment
OE-1:
The Cafeteria Ordering System shall operate with the following
Web browsers: Microsoft Internet Explorer versions 5.0 and 6.0,
Netscape Communicator version 4.7, and Netscape versions 6
and 7.
OE-2:
The Cafeteria Ordering System shall operate on a server running
the current corporate approved versions of Red Hat Linux and
Apache WebServer.
OE-3:
The Cafeteria Ordering System shall permit user access from
the corporate Intranet and, if a user is authorized for outside
access through the corporate firewall, from an Internet
connection at the user’s home.
2.4 Design and Implementation Constraints
CO-1:
The system’s design, code, and maintenance documentation
shall conform to the Process Impact Intranet Development
Standard, Version 1.3 [2].
CO-2:
The system shall use the current corporate standard Oracle

21. database engine.
CO-3:
All HTML code shall conform to the HTML 4.0 standard.
CO-4:
All scripts shall be written in Perl.
2.5 User Documentation
UD-1:
The system shall provide an online hierarchical and cross-linked
help system in HTML that describes and illustrates all system
functions.
UD-2:
The first time a new user accesses the system and on user
demand thereafter, the system shall provide an online tutorial to
allow users to practice ordering meals using a static tutorial
menu. The system shall not store meals ordered using this
template in the database or place orders for such meals with the
cafeteria.
2.6 Assumptions and Dependencies
AS-1:
The cafeteria is open for breakfast, lunch, and dinner every
company business day in which employees are expected to be on
site.
DE-1:
The operation of the COS depends on changes being made in the
Payroll System to accept payment requests for meals ordered
with the COS.
DE-2:
The operation of the COS depends on changes being made in the
Cafeteria Inventory System to update the availability of food

22. items as COS orders are accepted.
3. System Features
3.1 Order Meals
3.1.1
Description and Priority
A cafeteria Patron whose identity has been verified may order
meals either to be delivered to a specified company location or
to be picked up in the cafeteria. A Patron may cancel or change
a meal order if it has not yet been prepared. Priority = High.
3.1.2
Stimulus/Response Sequences
Stimulus:
Patron requests to place an order for one or more meals.
Response:
System queries Patron for details of meal(s), payment, and
delivery instructions.
Stimulus:
Patron requests to change a meal order.
Response:
If status is “Accepted,” system allows user to edit a previous
meal order.
Stimulus:
Patron requests to cancel a meal order.
Response:
If status is “Accepted, ”system cancels a meal order.
3.1.3

23. Functional Requirements
Order.Place:
The system shall let a Patron who is logged into the Cafeteria
Ordering System place an order for one or more meals.
Order.Place.Register:
The system shall confirm that the Patron is registered for
payroll deduction to place an order.
Order.Place.Register.No
If the Patron is not registered for payroll deduction, the system
shall give the Patron options to register now and continue
placing an order, to place an order for pickup in the cafeteria
(not for delivery), or to exit from the COS.
Order.Place.Date:
The system shall prompt the Patron for the meal date (see BR-
8).
Order.Place.Date.Cutoff:
If the meal date is the current date and the current time is after
the order cutoff time, the system shall inform the patron that
it’s too late to place an order for today. The Patron may either
change the meal date or cancel the order.
Order.Deliver.Select:
The Patron shall specify whether the order is to be picked up or
delivered.
Order.Deliver.Location:
If the order is to be delivered and there are still available
delivery times for the meal date, the Patron shall provide a valid
delivery location.
Order.Deliver.Notimes:
The system shall notify the Patron if there are no available

24. delivery times for the meal date. The Patron shall either cancel
the order or indicate that the Patron will pick up the order in the
cafeteria.
Order.Deliver.Times:
The system shall display the remaining available delivery times
for the meal date. The system shall allow the Patron to request
one of the delivery times shown, to change the order to be
picked up in the cafeteria, or to cancel the order.
Order.Menu.Date:
The system shall display a menu for the specified date.
Order.Menu.Available:
The menu for the current date shall display only those food
items for which at least one unit is available in the cafeteria’s
inventory.
Order.Units.Food:
The system shall allow the Patron to indicate the number of
units of each menu item that he wishes to order.
Order.Units.Multiple:
The system shall permit the user to order multiple identical
meals, up to the fewest available units of any menu item in the
order.
Order.Units.TooMany:
If the Patron orders more units of a menu item than are
presently in the cafeteria’s inventory, the system shall inform
the Patron of the maximum number of units of that food item
that he can order.
Order.Units.Change:
If the available inventory cannot fulfill the number of units
ordered, the Patron may change the number of units ordered,
change the number of identical meals being ordered, or cancel
the meal order.

25. Order.Confirm.Display:
When the Patron indicates that he does not wish to order any
more food items, the system shall display the food items
ordered, the individual food item prices, and the payment
amount, calculated per BR-12.
Order.Confirm.Prompt:
The system shall prompt the Patron to confirm the meal order.
Order.Confirm.Not:
If the Patron does not confirm the meal order, the Patron may
either edit or cancel the order.
Order.Confirm.More:
The system shall let the Patron order additional meals for the
same or for different date. BR-3 and BR-4 pertain to multiple
meals in a single order.
Order.Pay.Method:
When the Patron indicates that he is done placing orders, the
system shall ask the user to select a payment method.
Order.Pay.Deliver:
See BR-11.
Order.Pay.Pickup:
If the meal is to be picked up in the cafeteria, the system shall
let the Patron choose to pay by payroll deduction or by paying
cash at the time of pickup.
Order.Pay.Details:
The system shall display the food items ordered, payment
amount, payment method, and delivery instructions.
Order.Pay.Confirm:
The Patron shall either confirm the order, request to edit the
order, or request to cancel the order.

26. Order.Pay.Confirm.Deduct:
If the Patron confirmed the order and selected payment by
payroll deduction, the system shall issue a payment request to
the Payroll System.
Order.Pay.Confirm.OK:
If the payment request is accepted, the system shall display a
message confirming acceptance of the order with the payroll
deduction transaction number.
Order.Pay.Confirm.NG:
If the payment request is rejected, the system shall display a
message with the reason for the rejection. The Patron shall
either cancel the order, or change the payment method to cash
and request to pick up the order at the cafeteria.
Order.Done:
When the Patron has confirmed the order, the system shall do
the following as a single transaction:
Order.Done.Store
Assign the next available meal order number to the meal and
store the meal order with an initial status of “Accepted.”
Order.Done.Inventory:
Send a message to the Cafeteria Inventory System with the
number of units of each food item in the order.
Order.Done.Menu:
Update the menu for the current order’s order date to reflect any
items that are now out of stock in the cafeteria inventory.
Order.Done.Times:
Update the remaining available delivery times for the date of
this order.

27. Order.Done.Patron:
Send an e-mail message to the Patron with the meal order and
meal payment information.
Order.Done.Cafeteria:
Send an e-mail message to the Cafeteria Staff with the meal
order information.
Order.Done.Failure:
If any step of Order.Done fails, the system shall roll back the
transaction and notify the user that the order was unsuccessful,
along with the reason for failure.
Order.Previous.Period:
The system shall permit the Patron to view any meals he has
ordered within the previous six months. [Priority = Medium]
Order.Previous.Reorder:
The Patron may reorder any meal he had ordered within the
previous six months, provided that all food items in that order
are available on the menu for the meal date. [Priority =
Medium]
[functional requirements for changing and canceling meal
orders are not provided in this example]3.2 Create, View,
Modify, and Delete Meal Subscriptions
[details not provided in this example]
3.3 Register for Meal Payment Options
[details not provided in this example]
3.4 Request Meal Delivery
[details not provided in this example]
3.5 Create, View, Modify, and Delete Cafeteria Menus
[details not provided in this example]
4. External Interface Requirements

28. 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 help 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 hardware 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 current date.

29. 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 payroll 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.
CI-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.
5. Other Nonfunctional Requirements

30. 5.1 Performance Requirements
PE-1:
The system shall accommodate 400 users during the peak usage
time window of 8:00am to 10:00am local time, with an
estimated 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 connection.
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 system.
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.

31. SE-4:
The system shall permit only cafeteria staff members who are
on the list 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 midnight 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 and Data Model
delivery instruction
=
+
+

32. +
+
patron name
patron phone number
meal date
delivery location
delivery time window
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 item description
=
* text description of a food item on a menu; maximum 100

33. 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}

34. delivery instruction
meal 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
=
+

35. +
menu date
1:m{menu food item}
0:1{special}
menu date
=
* the date for which a specific menu of food items is available;
format MM/DD/YYYY *
menu food item
=
+
food item description
food item price
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

36. =
+
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 alphanumeric *
patron location
=
* building and room numbers of the employee who placed a
meal order; 50 character alphanumeric *
patron name

37. =
* 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 ] * others 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 each food item that the Patron is
ordering; default = 1; maximum = quantity presently in
inventory *
special
=

38. +
special description
special price
* the Menu Manager may define one or more special meals for
each menu, with a particular combination of food items 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 *
Appendix B: Analysis Models
Figure 1
Context diagram for release 1.0 of the Cafeteria Ordering
System.
�Cafeteria�Ordering�System

39. �Patron
Payroll�System
Menu�Manager
Meal�Deliverer
Cafeteria�Staff
delivery request
payroll deduction registration request
payment�request
menu contents

40. delivery request
payment request
meal order
menu
meal order
meal subscription
payroll deduction registration
Cafeteria�Inventory�System
food item orders

41. food item availability information
payroll deduction response
meal status�update
Patron
Meal Order
Meal Payment
Menu
Menu Food Item
Ordered Food Item

42. paying
placing
choosing
containing
containing
1
1
m
1

43. 1
1
m
m
m
m
Figure 2
Partial data model for release 1.0 of the Cafeteria Ordering
System.
Incomplete

44. Pending Delivery
Delivered
Accepted
Prepared
Canceled
Meal Deliverer delivers meal
Patron refuses delivery because order is incorrect
Patron cancels; charge payment
Cafeteria Staff prepares food

45. Cafeteria Staff requests delivery
System accepts completed order
Patron cancels; do not charge
Patron cancels; do not charge
Figure 3
State-transition diagram for meal order status.
Copyright © 2002 by Karl E. Wiegers. All Rights Reserved.
Preliminary Requirements Document
Assignment Instructions
Purpose
The purpose of this assignment is for you to prepare an SRS
(Software Requirements Specification) for the Case Study.
Directions
1. Use the attached SRS template to create a preliminary draft
of a Software Requirements Specification for the Case Study

46. proposed in your Week 2 Case Study.
2. Name your SRS like SRSDraftLastnameFirstname
3. Complete the Title Page, Sections 1, 2, 3, and 4. Do not
change the formatting of the SRS template but rather just add
your content and remove the instructions in the angle brackets
<> after you have completed the section.
4. For the Appendix B Analysis Models you will choose
whether you want to use the Structured Analysis and Design
Technique or the Object oriented Analysis and Design
Technique.
4.1 If you choose to use the Structured Analysis and Design
Technique, you will develop a Level 0 Context DFD (Data Flow
Diagram) and a Level 1 DFD for your Case Study. See the
Lessons for information on how to create these models.
4.2 If you choose to use the Object oriented Analysis and
Design Technique, you will develop a Use Case Diagram and
Detailed Description for the Use Cases for your Case Study. See
the Lessons for information on how to create these models.
5. For an example SRS see the Cafeteria Ordering System SRS
at https://imokymas.files.wordpress.com/2014/02/cos_srs.doc.
SRS Specification
Use this template for your SRS: srs_template-ieee.doc.
Document should follow APA guidelines and include references
at end of paper and in paper citations:
APA Example
Grading Rubric
Your submission will be graded using the following grading
Rubric.
Preliminary SRS Rubric.docx
NOTE: This assignment has the classroom TII (TurnItIn) feature
turned on. This means that once your assignment has been
submitted to this area, it will automatically be submitted to
Turnitin.com database to generate an Originality Report with an

47. Originality Index. It takes anywhere from a minute to 24 hours
(or longer) for this report to be generated and returned to the
classroom assignment area. Check often to see if the report has
been generated.
The acceptable criteria for the Originality Index in this course
is a maximum of 15%. Which means 15% of the submitted paper
has been matched with sources in the database and hence is not
original to the student's work. A 0% match index is ideal and
should be aimed for. In addition to the 15% maximum overall
match allowance, each of your cited sources should not exceed
2%. The bibliography section of your paper is excluded from
the match index by your professor after the report has been
generated by filtering this portion in the report. However, each
cited source must not exceed 2%.
A report exceeding 15% Match Index will get a grade of 0 and
be reported for plagiarism. Any individual source of more than
2% match will reduce the paper grade by the difference of the
match and 2%. So for example, a paper with overall match
index of say 5% (which is acceptable for the overall match
criteria of 15% max) with an individual source matched at say
4% (which is not acceptable for an individual source criteria of
2% max) will result in a 2% reduction from the paper score of
100%. You can resubmit your paper up to 5 times to get your
originality score down before grading is done at the end of the
week.