CSE Senior Design
System Requirements Specification
Format and Content Guide
What follows is a specification of the format and content of an acceptable Systems
Requirements Specification for CSE Senior Design products. Note: the format and
content specified herein is NOT the same as the CSE Senior Design System
Requirements Specifications/Documents generated prior to Fall 2015.
The primary use of this is to provide a complete definition of each item listed in your
Product Backlog. Essentially, therefore, this document is a formalization of your
Product Backlog and will, therefore, continue to evolve throughout the life of the
product until the final deliverable date at the end of Senior Design 2. As
requirements evolve, this document and the product backlog must be updated to
reflect the current state of product definition.
For consistency and evaluation by the instructor, font size, document layout/format,
section numbering, and section headings must be as described herein.
System Requirements Specification
[Insert Product Name Here in Header]
Department of Computer Science and Engineering
The University of Texas at Arlington
Team: [Insert Team Name]
Project: [Insert Project Name]
Team Members:
[Insert Member 1 Name]
[Insert Member 2 Name]
[Insert Member 3 Name]
[Etc.]
[Insert date of this version in footer]
[page #]
[Insert team name in footer]
System Requirements Specification
[Insert Product Name Here in Header]
Table of Contents
[Generate a Table of Contents for the document here]
[Insert date of this version in footer]
[page #]
[Insert team name in footer]
System Requirements Specification
[Insert Product Name Here in Header]
Document Revision History
Revision Revision
Number Date
Description
Rationale
This table provides a continuous record of document versions and
must contain an entry for every version of this document that is
published for review outside of your team. Revision numbering
instructions:


The version of the document submitted as each update to
the product backlog should increment according to the
Sprint number.
For example, the versions associated with Sprint 1 are all
numbered 1.x, where x is an iteration of the document
during Sprint 1.
[Insert date of this version in footer]
[page #]
[Insert team name in footer]
System Requirements Specification
[Insert Product Name Here in Header]
List of Figures
Figure #
Title
Page #
S-x
Title of Figure S-x goes here
#
S-y
Title of Figure S-y goes here
#
(etc.)
[Insert date of this version in footer]
[page #]
[Insert team name in footer]
System Requirements Specification
[Insert Product Name Here in Header]
List of Tables
Figure #
Title
Page #
1
Title of Table 1 goes here
#
2
Title of Table 2 goes here
#
(etc.)
[Insert date of this version in footer]
[page #]
[Insert team name in footer]
System Requirements Specification
[Insert Product Name Here in Header]
1. Product Vision
[This section provides a high-level statement of your product concept – what it is intended to do and
how it is intended to be used. Include in this header paragraph, a brief synopsis of what is described
here. For example, this header paragraph might say something like:
“This section describes the purpose, use and intended user audience for the Suchandsuch product.
Suchandsuch is a thingamajig that performs … lotsofstuff. Users of Suchandsuch will be able to do
…whatever.”]
1.1
Purpose and Use
[This is where you describe in a brief, yet clear and concise, manner what your product should do and
how you expect it should be used.]
1.2
Intended Audience
[This is where you describe the intended audience(s) of your product – if this product were to be made
available publically/commercially, what class/type of consumer will use/buy it?]
[Include as Figure 1-1 a conceptual drawing/graphic that shows the key components of your product.]
[Insert date of this version in footer]
[page #]
[Insert team name in footer]
System Requirements Specification
[Insert Product Name Here in Header]
In the sections that follow titled “2. Requirements/Features/Functions”, you will describe the features,
functions and other specifications that are requirements for your product.
Paragraph 3.Y A concise title for the requirement (e.g. “Box Color”)
Paragraph 3.Y.1 A detailed user story associated with this requirement/feature/function. E.g.:
“The user should be able to view the surrounding area of the map. The area should be
viewable with all roads and points of interest indicated by textual descriptions.” (Note that
it is acceptable and advisable to include drawings/graphics in the description if it aids
understanding of the requirement.)
Paragraph 3.Y.2 Acceptance criteria associated with this requirement/feature/function. E.g.:
Criteria 1: Verify that the user can view the dates associated with the sales of an item.
Criteria 2: Verify that the dates are displayed as dd/mm/yyyy
Criteria 3: Verify that the item name is correctly associated with the SKU that is shown.
Paragraph 3.Y.3 The priority of this requirement relative to other specified requirements. The
requirements should be ordered in this section of your document in order of priority as specified by
the Product Owner (note that this will change/evolve through the life of the product. Use the
following priorities:
Priority 1 - Critical (must have or product is a failure);
Priority 2 - High (very important to customer acceptance, desirability);
Priority 3 - Moderate (should have for proper product functionality);
Priority 4 - Low (nice to have, will include if time/resource permits); or
Paragraph 3.Y.4 Estimated relative effort associated with implementing this
requirement/feature/function completely, as specified. Note that the estimate includes all tasks
associated with completing the requirement, including design, implementation and test. Use the
following adjectives to quantify your effort estimate:
Small – considered relatively simple and can be finished quickly (hours/days)
Medium – easily understood and requiring minimal skill level, but may require
longer to complete (days/weeks)
Large – hard to implement, due either to technology, skill or time required (weeks)
Very Large – must learn new skills and deploy unfamiliar technologies to accomplish
as specified (weeks/months)
Use the format shown in the following sections of this document guide for each specified requirement.
[Insert date of this version in footer]
[page #]
[Insert team name in footer]
System Requirements Specification
[Insert Product Name Here in Header]
2. Requirements, Features and Functions
[This section establishes, clearly and concisely, the “look and feel” of the product, what each potential
end-user should expect the product do and/or not do, as well as other features considered essential by the
product owner. Each requirement specified in this section is associated with a specific customer need,
as determined by the Product Owner, which will be satisfied by the product. Note that if a requirement
appears here your assumption is that it will be done. If a requirement/feature/function is not shown here,
it should not be included in the product.
IMPORTANT NOTE: DO NOT neglect to include packaging, performance, safety and other
requirements that are important to the customer. Packaging requirements are those requirements that
identify how the delivered product will be packaged for delivery to the end-user; or how it will "look"
when finished and delivered. For example, you might specify that the software required for operation
will be pre-loaded on the hard drive, delivered on CD/DVD, or available via download from a central
site. Software might be customer installable, or not, etc. Hardware components could be all in a single
package, provided as a "bag of parts" to be assembled/installed by the user, painted a certain color, logos
affixed, etc. Performance requirements are those features that define what the customer expects in terms
of “how well it does what it is supposed to do.” For example, if it is battery-operated, how long will the
battery last? Or if it is processing or data acquisition dependent, how long should specific operations
take to complete? Safety requirements are those requirements relative to safe operation, use and
maintenance of the product. Other requirements are features/functions that may not necessarily be enduser visible, but are non-the-less important to your customer. For example, the customer may have
specific requirements about how maintainable the code or hardware is after it is delivered. Are there
specific test points, code commentary, or module naming requirements that are required?]
2.1
[Enter a Concise Requirement Name]
2.1.1 Story: [provide a concise story associated with this requirement, in clear and easily
understandable language.]
2.1.2 Acceptance Criteria: [specify all acceptance criteria for this product as agreed with the
Product Owner]
2.1.3 Priority: [specify the priority of this requirement]
2.1.4 Effort: [specify effort required to complete the requirement]
2.2
[Enter another Concise Requirement Name]
2.2.1 Story: [provide a concise story associated with this requirement, in clear and easily
understandable language.]
[Insert date of this version in footer]
[page #]
[Insert team name in footer]
System Requirements Specification
[Insert Product Name Here in Header]
2.1.2 Acceptance Criteria: [specify all acceptance criteria for this product as agreed with the
Product Owner]
2.2.3 Priority: [specify the priority of this requirement]
2.2.4 Effort: [specify effort required to complete the requirement]
2.3
[Enter a Concise Requirement Name]
2.2.1 Story: [provide a concise story associated with this requirement, in clear and easily
understandable language.]
2.2.2 Acceptance Criteria: [specify all acceptance criteria for this product as agreed with the
Product Owner]
2.2.3 Priority: [specify the priority of this requirement]
2.2.4 Effort: [specify effort required to complete the requirement]
2.4
[Enter a Concise Requirement Name]
2.4.1 Story: [provide a concise story associated with this requirement, in clear and easily
understandable language.]
2.4.2 Acceptance Criteria: [specify all acceptance criteria for this product as agreed with the
Product Owner]
2.4.3 Priority: [specify the priority of this requirement]
2.4.4 Effort: [specify effort required to complete the requirement]
[2.5 ETC.]
[Insert date of this version in footer]
[page #]
[Insert team name in footer]
System Requirements Specification
[Insert Product Name Here in Header]
3. Future Items
[In this section, you will list all requirements that are required, but must be relegated to a later release of
the product. These are those customer-specified features/functions that were considered/discussed and
but will NOT be addressed in the “released” version of the product at the end of the defined timeframe
due to constraints of budget, time, skills, technology, feasibility analysis, etc. These will be listed in the
same format as requirement in section 3 above. Note that this section will evolve as you learn more
about what the customer really expects and what you are capable of completing in the specified
timeframe.]
[Insert date of this version in footer]
[page #]
[Insert team name in footer]
System Requirements Specification
[Insert Product Name Here in Header]
4. Feasibility Assessment
[In this last section you will critically analyze the feasibility of successful fulfillment of the requirements
specified in section 2. This is one of the most difficult and important parts of the requirement analysis
process-difficult because you must critically analyze and assess the probability of success given project
constraints, and important because stakeholders have the obligation and right to understand this
probability before moving ahead with the project as specified. Note that this assessment is at a point in
time, so is necessarily based on your judgment and critical analysis of what you currently know. (For
purposes of this class, you will complete this analysis after the first sprint for the draft SRS deliverable,
and update it for the end-of-semester SRS deliverable.)
Feasibility analysis, as used here, consists of an assessment of the following six components:
1. Research analysis: How much research has to be done to thoroughly understand the
requirements and the work required to complete them? Is the research effort reasonable to
accomplish within the constraints of the project?
2. Technical analysis: Is there “invention” involved, or is the technology straightforward and
readily available? Can any hardware/mechanical devices be purchased or fabricated for your
prototype?
3. Cost analysis: What are your expected product costs? Can this be done with the budget you
have available to you? Are there other sources available to offset costs?
4. Resource analysis: What skill are needed? Does your team have or have access to the
appropriate skills to complete the requirements? Are there skills/knowledge that can be provided
by a third party (for example and mechanical designer or circuit layout expert)?
5. Schedule analysis: Do you expect to be able to accomplish everything required within the
specified timeframe? What is the size of the product that you expect to develop? Do your
metrics require a specified amount of time each week for the team members? What velocity per
sprint is required?
6. Scope analysis: Given the above, is the overall scope of what you are trying do reasonable?
[Insert date of this version in footer]
[page #]
[Insert team name in footer]