SHIFA TAMEER-E-MILLAT

UNIVERSITY

Assignment 1
Software Requirement Specification
(SRS DOCUMENT)

for

Project Title

Version 1.0

By
Student Name 1 SP18-BSE-xxx
Student Name 2 SP18-BSE-xxx

Submmitted to
Habib Un Nisa

Bachelor of Science in Software Engineering (20xx-20xx)

 Revision History

Name Date Reason for Changes Version

2
 Table of Contents

1. Introduction 1
1.1 Purpose 1
1.2 Scope 1
1.3 Definitions, Acronyms, Abbreviations 1
1.4 Reference Documents 1
1.4 Overview 1
2. Requirement Identifying Technique 1
3. Functional Requirements 1
3.1 Feature <ID: Title> /Use case <ID: Title> 2
3.1.1 Functional Requirement <ID: Title> 2
4. Non-Functional Requirements 2
4.1 Reliability 3
4.2 Usability 3
4.3 Performance 3
4.4 Security 3
5. References 3

3
1. Introduction
The introduction of the Software Requirements Specification (SRS) should provide an overview of
the entire SRS. It should include the purpose, scope, modules and overview of the SRS.

1.1Purpose
Identify the product or application whose requirements are specified in this document. Describe the
different types of reader that the document is intended for, such as developers, project managers,
marketing staff, users, testers, and documentation writers.

1.2Scope
Provide a short description of the software being specified and its purpose. Relate the software to user
or project goals and to project objectives. Provide a high-level summary of the major features the
software contains or the significant functions that it performs.

1.3Definitions, Acronyms, and Abbreviations

List the defintions, acronyms and abbreviations used in the proposed project.

1.4Reference Documents
This subsection should describe the reference documents used to create this SRS. For example, IEEE
standard for SRS.

1.5Overview
This subsection should describe what the rest of the SRS contains and explain how the document is
organized.

2. Requirement Identifying Technique

This section describes the requirements identifying technique(s) which further help to derive functional
requirements specification. The selection of the technique(s) will depend on the type of project.

3. Functional Requirements
This section describes the functional requirements of the system expressed in the natural language
style. This section is typically organized by feature as a system feature name and specific functional
requirements associated with this feature. It is just one possible way to arrange them. Other
organizational options include arranging functional requirements by use case, process flow, mode of
operation, user class, stimulus, and response depend on what kind of technique has been used to
understand functional requirements. Hierarchical combinations of these elements are also possible,
such as use cases within user classes. For further detail see Chapter 10 “Documenting the
requirements”. Let consider the feature scheme as an example.

3.1 Feature <ID: Title> /Use case <ID: Title>

4
Provide the feature details or the use case description through which the following set of functional
requirements are mapped and derived.

3.1.1 Functional Requirement <ID: Title>

Itemize the specific functional requirements associated with each feature. These are the software
capabilities that must be implemented 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, as described earlier. You can create multiple
attributes for each functional requirement, such as source , rationale, business rule, dependencies, etc.
Note: Use any of these attributes to support the understanability and completeness of the functional
requirement, where it is required.
The following template is required to write functional requirements. For further detail see Chapter 11”
Writing excellent requirements”.

Identifier FR-1
Title Title of requirement
Requirement Description of requirement which may be written either from the user or
system perspective e.g.
If written in a user perspective
The [user class or actor name] shall be able to [do something] [to some
object] [qualifying conditions, response time, or quality statement].
If written in a system perspective
[optional precondition] [optional trigger event] the system shall [expected
system response]
Source Where this requirement comes from (who originate it)
Rationale The motivation behind the requirement
Business Rule Any restriction, policy, the rule that the particular requirement must be
fulfilled through its functional behavior
Dependencies Requirements ID that is dependent on this requirement
Priority High/Medium/Low

4. Non-Functional Requirements
This section specifies nonfunctional requirements other than constraints, which are recorded in section
2.3, and external interface requirements, which will appear in section 7. These quality requirements
should be specific, quantitative, and verifiable. Chapter 14 “beyond functionality” presents more
information about these quality attribute requirements and many examples. The following are some
examples of documenting guidelines.

5
4.1 Reliability
Requirements about how often the software fails. The measurement is often expressed in MTBF (mean
time between failures). The definition of a failure must be clear. Also, don't confuse reliability with
availability which is quite a different kind of requirement. Be sure to specify the consequences of
software failure, how to protect from failure, a strategy for error detection, and a strategy for
correction.

4.2 Usability
Usability requirements deal with ease of learning, ease of use, error avoidance and recovery, the
efficiency of interactions, and accessibility. The usability requirements specified here will help the user
interface designer create the optimum user experience.
Example:

USE-1: The COS shall allow a user to retrieve the previous meal ordered with a single interaction.

4.3 Performance
State specific performance requirements for various system operations. If different functional
requirements or features have different performance requirements, it’s appropriate to specify those
performance goals right with the corresponding functional requirements, rather than collecting them in
this section.
Example:

PER-1: 95% of webpages generated by the COS shall download completely within 4 seconds from the
time the user requests the page over a 20 Mbps or faster Internet connection.

4.4 Security
One or more requirements about protection of your system and its data. The measurement can be
expressed in a variety of ways (effort, skill level, time, ...) to break into the system. Do not discuss
solutions (e.g. passwords) in a requirements document.

5. References
List any documents or other resources to which this SRS refers, if any. These might include user
interface style guides, standards, system requirements specifications, interface specifications, or the
SRS for a related product. The following are a few examples of different resources.

Book
Author(s). Book title. Location: Publishing company, year, pp.
Example:
W.K. Chen. Linear Networks and Systems. Belmont, CA: Wadsworth, 1993, pp. 123-35.

Article in a Journal
Author(s). “Article title”. Journal title, vol., pp, date.
Example:
G. Pevere. “Infrared Nation.” The International Journal of Infrared Design, vol. 33, pp. 56-99, Jan. 1979.

6
Articles from Conference Proceedings (published)
Author(s). “Article title.” Conference proceedings, year, pp.
Example:
D.B. Payne and H.G. Gunhold. “Digital sundials and broadband technology,” in Proc. IOOC-ECOC, 1986, pp.
557-998.

World Wide Web

Author(s)*. “Title.” Internet: complete URL, date updated* [date accessed].
M. Duncan. “Engineering Concepts on Ice. Internet: www.iceengg.edu/staff.html, Oct. 25, 2000 [Nov. 29,
2003].