An SRS template Adapted from IEEE 830
1. Introduction
overview to help the reader understand how the SRS is organized
and how to use it.
1.1 Purpose
Identify the product or application whose requirements are
specified in this document, including the revision or release
number.
1.2 Document Conventions
• Describe any standards or typographical conventions, including text
styles, highlighting, or significant notations.
• For instance, state whether the priority shown for a high-level
requirement is inherited by all its detailed requirements or whether
every functional requirement statement is to have its own priority
rating.
An SRS template Adapted from IEEE 830
1.3 Intended Audience and Reading Suggestions
• List the different readers to whom the SRS is directed.
• Suggest a sequence for reading the document that is
most appropriate for each type of reader.
1.4 Project Scope
• Short description of the software being specified and
its purpose.
• Relate the software to user or corporate goals and to
business objectives and strategies.
• If a separate vision and scope document is available,
refer to it rather than duplicating its contents here.
An SRS template Adapted from IEEE 830
1.5 References
• List any documents or other resources to which this SRS refers,
including hyperlinks to them if possible.
• These might include user interface style guides, contracts,
standards, system requirements specifications, use-case
documents, or the SRS for a related product.
• Provide enough information so that the reader can access each
reference, including its title, author, version number, date, and
source or location (such as network folder or URL).
2. Overall Description
• This section presents a high-level overview of the product and the
environment in which it will be used, the anticipated product users,
and known constraints, assumptions, and dependencies.
An SRS template Adapted from IEEE 830
2.1 Product Perspective
• Describe the product's context and origin.
• Is it the next member of a growing product family, the next version of a
mature system, a replacement for an existing application, or an entirely
new product?
• If this SRS defines a component of a larger system, state how this software
relates to the overall system and identify major interfaces between the
two.
2.2 Product Features
• List the major features the product contains or the significant functions
that it performs.
• Details will be provided in Section 3 of the SRS, so you need only a highlevel summary here. A picture of the major groups of requirements and
how they are related, such as a top-level data flow diagram, a use-case
diagram, or a class diagram, might be helpful.
An SRS template Adapted from IEEE 830
2.3 User Classes and Characteristics
• Identify the various user classes that you anticipate will use
this product and describe their pertinent characteristics.
• User classes represent a subset of the stakeholders
described in the vision and scope document.
2.4 Operating Environment
• Describe the environment in which the software will
operate, including the hardware platform, the operating
systems and versions, and the geographical locations of
users, servers, and databases.
• List any other software components or applications with
which the system must peacefully coexist.
An SRS template Adapted from IEEE 830
2.5 Design and Implementation Constraints
• Describe any factors that will restrict the options available to the
developers and the rationale for each constraint.
• Specific technologies, tools, programming languages, and databases that
must be used or avoided.
• Restrictions because of the product's operating environment, such as the
types and versions of Web browsers that will be used.
• Backward compatibility with earlier products.
• Hardware limitations such as timing requirements, memory or processor
restrictions, size, weight, materials, or cost.
• Existing user interface conventions to be followed when enhancing an
existing product.
• Standard data interchange formats such as XML.
An SRS template Adapted from IEEE 830
2.6 User Documentation
• List the user documentation components that will be delivered
along with the executable software.
• These could include user manuals, online help, and tutorials.
• Identify any required documentation delivery formats, standards, or
tools.
2.7 Assumptions and Dependencies
• An assumption is a statement that is believed to be true in the
absence of proof or definitive knowledge.
• Problems can arise if assumptions are incorrect, are not shared, or
change, so certain assumptions will translate into project risks.
• One SRS reader might assume that the product will conform to a
particular user interface convention, whereas another assumes
something different.
An SRS template Adapted from IEEE 830
• Identify any dependencies the project has on external factors
outside its control, such as the release date of the next version of
an operating system or the issuing of an industry standard.
• If you expect to integrate into the system some components that
another project is developing, you depend upon that project to
supply the correctly operating components on schedule.
3. System Features
• The template in Figure 10-1 is organized by system feature, which is
just one possible way to arrange the functional requirements.
• Other organizational options include by use case, mode of
operation, user class, stimulus, response, object class, or functional
hierarchy (IEEE 1998b).
An SRS template Adapted from IEEE 830
• Combinations of these elements are also
possible, such as use cases within user classes.
3.x System Feature X
• State the name of the feature in just a few
words, such as "3.1 Spell Check."
• Repeat subsections 3.x.1 through 3.x.3 for
each system feature.
An SRS template Adapted from IEEE 830
3.x.1 Description and Priority
• Provide a short description of the feature and
indicate whether it is of high, medium, or low
priority.
3.x.2 Stimulus/Response Sequences
• List the sequences of input stimuli (user actions,
signals from external devices, or other triggers)
and system responses that define the behaviors
for this feature.
• These stimuli correspond to the initial dialog
steps of use cases or to external system events.
An SRS template Adapted from IEEE 830
3.x.3 Functional Requirements
• Itemize the detailed functional requirements
associated with this feature.
• These are the software capabilities that must be
present for the user to carry out the feature's
services or to perform a use case.
• Describe how the product should respond to
anticipated error conditions and to invalid inputs
and actions.
• Uniquely label each functional requirement.
An SRS template Adapted from IEEE 830
4. External Interface Requirements
• According to Richard Thayer (2002), "External
interface requirements specify hardware,
software, or database elements with which a
system or component must interface...."
• This section provides information to ensure
that the system will communicate properly
with external components.
An SRS template Adapted from IEEE 830
4.1 User Interfaces
• Describe the logical characteristics of each user interface that the
system needs.
• References to GUI standards or product family style guides that are
to be followed.
• Standards for fonts, icons, button labels, images, color schemes,
field tabbing sequences, and the like.
• Screen layout or resolution constraints.
• Standard buttons, functions, or navigation links that will appear on
every screen, such as a help button.
• Shortcut keys.
• Layout standards to facilitate software localization.
• Accommodations for visually impaired users.
An SRS template Adapted from IEEE 830
• Document the user interface design details, such
as specific dialog box layouts, in a separate user
interface specification, not in the SRS.
4.2 Hardware Interfaces
• Describe the characteristics of each interface
between the software and hardware components
of the system.
• This description might include the supported
device types, the data and control interactions
between the software and the hardware, and the
communication protocols to be used.
An SRS template Adapted from IEEE 830
4.3 Software Interfaces
• Describe the connections between this product and other software
components (identified by name and version), including databases,
operating systems, tools, libraries, and integrated commercial
components.
• State the purpose of the messages, data, and control items
exchanged between the software components.
• Describe the services needed by external software components and
the nature of the inter-component communications.
• Identify data that will be shared across software components. If the
data-sharing mechanism must be implemented in a specific way,
such as a global data area, specify this as a constraint.
An SRS template Adapted from IEEE 830
4.4 Communications Interfaces
• State the requirements for any communication functions
the product will use, including e-mail, Web browser,
network communications protocols, and electronic forms.
• Define any pertinent message formatting.
• Specify communication security or encryption issues, data
transfer rates, and synchronization mechanisms.
5. Other Nonfunctional Requirements
• This section specifies nonfunctional requirements other
than external interface requirements, which appear in
section 4, and constraints, recorded in section 2.5.
An SRS template Adapted from IEEE 830
5.1 Performance Requirements
• State specific performance requirements for various system
operations.
• Explain their rationale to guide the developers in making
appropriate design choices.
• For instance, stringent database response time demands might lead
the designers to mirror the database in multiple geographical
locations for faster query responses.
• Specify the number of transactions per second to be supported,
response times, computational accuracy, and timing relationships
for real-time systems.
• You could also specify memory and disk space requirements,
concurrent user loads, or the maximum number of rows stored in
database tables.
An SRS template Adapted from IEEE 830
• Quantify the performance requirements as
specifically as possible—for example, "95
percent of catalog database queries shall be
completed within 3 seconds on a single-user
1.1-GHz Intel Pentium 4 PC running Microsoft
Windows XP with at least 60 percent of the
system resources free."
An SRS template Adapted from IEEE 830
5.2 Safety Requirements
• Safety and security are examples of quality attributes,
which are more fully addressed in section 5.4.
• In this section, specify those requirements that are
concerned with possible loss, damage, or harm that could
result from the use of the product (Leveson 1995).
• Define any safeguards or actions that must be taken, as
well as potentially dangerous actions that must be
prevented.
• Identify any safety certifications, policies, or regulations to
which the product must conform.
• Examples of safety requirements are
An SRS template Adapted from IEEE 830
• SA-1 The system shall terminate any operation within 1 second if
the measured tank pressure exceeds 95 percent of the specified
maximum pressure.
• SA-2 The radiation beam shield shall remain open only through
continuous computer control. The shield shall automatically fall into
place if computer control is lost for any reason.
5.3 Security Requirements
• Specify any requirements regarding security, integrity, or privacy
issues that affect access to the product, use of the product, and
protection of data that the product uses or creates.
• Security requirements normally originate in business rules, so
identify any security or privacy policies or regulations to which the
product must conform.
An SRS template Adapted from IEEE 830
• Alternatively, you could address these
requirements through the quality attribute called
integrity.
• Following are sample security requirements:
• SE-1 Every user must change his initially assigned
login password immediately after his first
successful login. The initial password may never
be reused.
• SE-2 A door unlock that results from a successful
security badge read shall keep the door unlocked
for 8.0 seconds.
An SRS template Adapted from IEEE 830
5.4 Software Quality Attributes
• State any additional product quality characteristics that
will be important to either customers or developers.
• These characteristics should be specific, quantitative,
and verifiable.
• Indicate the relative priorities of various attributes,
such as ease of use over ease of learning, or portability
over efficiency.
• A rich specification notation (such as Planguage)
clarifies the needed levels of each quality much better
than can simple descriptive statements.
An SRS template Adapted from IEEE 830
6. Other Requirements
• Define any other requirements that are not covered elsewhere in
the SRS.
• Examples include internationalization requirements (currency, date
formatting, language, international regulations, and cultural and
political issues) and legal requirements.
• You could also add sections on operations, administration, and
maintenance to cover requirements for product installation,
configuration, startup and shutdown, recovery and fault tolerance,
and logging and monitoring operations.
• Add any new sections to the template that are pertinent to your
project.
• Omit this section if all your requirements are accommodated in
other sections.
An SRS template Adapted from IEEE 830
Appendix A: Glossary
• Define any specialized terms that a reader needs
to know to properly interpret the SRS, including
acronyms and abbreviations.
• Spell out each acronym and provide its definition.
Appendix B: Analysis Models
• This optional section includes or points to
pertinent analysis models such as data flow
diagrams, class diagrams, state-transition
diagrams, or entity-relationship diagrams.
An SRS template Adapted from IEEE 830
Appendix C: Issues List
• This is a dynamic list of the open requirements
issues that remain to be resolved.
• Issues could include items flagged as TBD,
pending decisions, information that is needed,
conflicts awaiting resolution, and the like.
• This doesn't necessarily have to be part of the
SRS, but some organizations always attach a
TBD list to the SRS.