Scribd
Upload
196 views10 pages

Software Requirements Specification: Version 1.0 Approved

This document is a software requirements specification (SRS) for a project. It provides an overview of the purpose and scope of the project, describes the major functions and operating environment of the software, outlines the key system features and functional requirements, and identifies other non-functional requirements around performance, security, and quality. Appendices include a glossary, any relevant analysis models, and a list of items yet to be determined.

Uploaded by

Linto Varghese
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
196 views10 pages

Software Requirements Specification: Version 1.0 Approved

This document is a software requirements specification (SRS) for a project. It provides an overview of the purpose and scope of the project, describes the major functions and operating environment of the software, outlines the key system features and functional requirements, and identifies other non-functional requirements around performance, security, and quality. Appendices include a glossary, any relevant analysis models, and a list of items yet to be determined.

Uploaded by

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

SOFTWARE REQUIREMENTS

SPECIFICATION

for

<Project>

Version 1.0 approved

Prepared by <author>

<Organization>

January 10, 2017

1
Contents

2
Revision History
Name Date Reason For Changes Version
21 22 23 24
31 32 33 34

3
1 Introduction
1.1 Purpose
<Identify the product whose software requirements are specified in this document, in-
cluding the revision or release number. Describe the scope of the product that is cov-
ered 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


<Describe the different types of reader that the document is intended for, such as de-
velopers, 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 Project 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 specifica-
tions, use case documents, or a vision and scope document. Provide enough information

4
so that the reader could access a copy of each reference, including title, author, version
number, date, and source or location.>

5
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 compo-
nent 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.>

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 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 appli-
cations with which it must peacefully coexist.>

2.4 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 tech-
nologies, 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).>

6
2.5 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).>

7
3 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.>

3.1 System Feature 1


<Don’t really say “System Feature 1.” State the feature name in just a few words.>

3.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).>

3.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.>

3.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 mean-
ingful tag of some kind.>
REQ-1: REQ-2:

3.2 System Feature 2 (and so on)

8
4 Other Nonfunctional Requirements
4.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.>

4.2 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.>

4.3 Software Quality Attributes


<Specify any additional quality characteristics for the product that will be important
to either the customers or the developers. Some to consider are: adaptability, avail-
ability, correctness, flexibility, interoperability, maintainability, portability, reliability,
reusability, robustness, testability, and usability. Write these to be specific, quantita-
tive, and verifiable when possible. At the least, clarify the relative preferences for various
attributes, such as ease of use over ease of learning.>

9
5 Other Requirements
<Define any other requirements not covered elsewhere in the SRS. This might include
database requirements, internationalization requirements, legal requirements, reuse ob-
jectives for the project, and so on. Add any new sections that are pertinent to the
project.>

5.1 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.>

5.2 Appendix B: Analysis Models


<Optionally, include any pertinent analysis models, such as data flow diagrams, class
diagrams, state-transition diagrams, or entity-relationship diagrams.>

5.3 Appendix C: To Be Determined List


<Collect a numbered list of the TBD (to be determined) references that remain in the
SRS so they can be tracked to closure.>

10

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy