The document discusses software requirement specifications (SRS), including what an SRS is, when it is useful, and an outline for an SRS template. Some key points: - An SRS formally defines the requirements for software that is to be developed. It serves as a contract between developers and customers. - The SRS describes functional and non-functional requirements, interfaces, design constraints, and other aspects of the software without specifying solutions. - A good SRS template includes sections for introduction, overall description, specific requirements, and appendices. It provides a standardized way to document requirements.

3. Software Requirement
Specification
Template
A Software requirements specification ( S.R.S.)
is a document that is created when a detailed
description of all aspects of the software to be
built must be specified before the project is to
commence. It is important to note that a formal
S.R.S. is not always written . In fact, there are
many instances in which effort expended on an
S.R.S. might be better spent in other software
engineering activities.

4. However, when software is to be
developed by a third party, when a lack of
specification would create severe business
issues, or when a system is extremely
complex or business critical, an S.R.S. may
be justified.
KARL WIEGERS [ Wie03 ]
of Process Impact Inc. has developed a
worthwhile template that can serve as a
guideline for those who must create a
complete S.R.S. . A topic outline follows :-

5. Table of Contents
1) Introduction 2.6 User Documentation
1.1 Purpose 3) System Features
1.2 Document Conventions 4) External Interface
1.3 Intended Audience and Requirements
Reading Suggestions 5) Other Nonfunctional
1.4 Project Scope
Requirements
1.5 References 6) Other Requirements
2) Overall Description
2.1 Product Perspective Appendix A : Glossary
2.2 Product Features Appendix B : Analysis
2.3 User Classes Models
2.4 Operating Environment Appendix C : Issues List
2.5 Design and Implementation

6. Basic Information about Software
Requirements Specification ( A Contract
Document )
 Requirements document is a reference
document.
 SRS document is a contract between
the development team and the
customer.
 Once the SRS document is approved by
the customer, any subsequent
controversies are settled by referring the
SRS document.

7.  The SRS document is known as
black-box specification :
◦ the system is considered as a black
box when internal details are not
known.
◦ only its visible external (i.e.
input/output) behaviour is
documented.
Input
Data
Output
Data

8. Purpose of S.R.S.
 Proper ( systematic )
communication between the
Customer, Analyst, system
developers, maintainers etc.
 Contract between Purchaser and
Supplier firm is the foundation for
the design phase.
 Support system testing activities.
 Support project management.

9.  SRS document concentrates
on:
 what needs to be done
 and it carefully avoids the
solution (“how to do”) aspects.
The SRS document serves as
a contract
between development team and
the customer.
 Should be carefully written

10. Software Requirements
Specification (SRS)
 Defines the customer’s requirements in terms of
:
◦ Function
◦ Performance
◦ External interfaces
◦ Design constraints
 The SRS is the basis of contract between the
purchaser and supplier

11. What is not included in an SRS ?
 Project requirements
 cost, delivery schedules, staffing,
reporting, procedures
 Design solutions
 partitioning of S/W into modules,
choosing data structures
 Product assurance plans
 Quality Assurance procedures
 Configuration Management procedures
 Verification & Validation procedures

12. Benefits of S.R.S.
1) Forces the users to consider their specific
requirements carefully.
2) Enhances communication between the
Purchaser and System developers.
3) Provides a firm foundation for the system
design phase.
4) Enables planning of validation, verification,
and acceptance procedures.
5) Enables project planning e.g. estimates of
cost and time, resource scheduling.
6) Usable during maintenance phase

13. Types of Requirements
Functional requirements
Non functional
requirements
◦Performance requirements
◦Interface requirements
◦Design constraints
◦Other requirements

14. Functional Requirements
 Transformations (inputs, processing,
outputs)
 Requirements for sequencing
(dynamic requirements)
 Data
◦ Inputs and Outputs
◦ Stored data
 Exception handling

15. External Interface Requirements
 User interfaces
◦ e.g. if display terminal used, specify
required screen formats, menus, report
layouts, function keys
 Hardware interfaces
◦ characteristics of the interface between the
SW product and HW components of the
system
 Software interfaces
◦ specify the use of other SW products eg.
OS, DBMS, other SW packages

16. Other Requirements
 Security
 Safety
 Environmental
 Reusability
 Training
 ...

17. SRS Prototype Outline
[ IEEE SRS Standard ]
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms and Abbreviations
1.4 References
1.5 Overview

18. SRS - Introduction Section
 Purpose
◦ delineate the purpose of the particular SRS
◦ specify the intended audience for the SRS
 Scope
◦ identify the S/W products to be produced by name
◦ explain what the S/W product will do, and if
necessary, what it will not do
◦ describe the application of the S/W being
specified. i.e. benefits, objectives, goals as
precisely as possible
 Overview
◦ describe what the rest of the SRS contains
◦ how the SRS is organized

19. SRS Prototype Outline
[ IEEE SRS Standard ]
2. General description
2.1 Product perspective
2.2 Product function summary
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and dependencies

20. Product Functions
 Provide a summary of functions the SW will
perform
 The functions should be organized in such a
way that they are understandable by the user
User Characteristics
 Describe the general characteristics of the
eventual users of the product. (such as
educational level, experience and technical
expertise )

21. SRS Prototype Outline
[ IEEE SRS Standard ]
3. Specific Requirements
- Functional requirements
- External interface requirements
- Performance requirements
- Design constraints
- Attributes e.g. security, availability,
maintainability, transferability/conversion
- Other requirements
Appendices
Index

22. Functional Requirements
 Introduction
o describe purpose of the function and the
approaches and techniques employed
 Inputs and Outputs
o sources of inputs and destination of
outputs
o quantities, units of measure, ranges of
valid inputs and outputs
o timing

23. Functional Requirements
 Processing
◦ validation of input data
◦ exact sequence of operations
◦ responses to abnormal situations
◦ any methods (eg. equations, algorithms)
to be used to transform inputs to outputs

24. External Interface Requirements
 User interfaces
 Hardware interfaces
 Software interfaces
 Communications interfaces
 Other requirements
◦ database: frequency of use, accessing
capabilities, static and dynamic organization,
retention requirements for data
◦ operations: periods of interactive and
unattended operations, backup, recovery
operations

25. Appendices
 Not always necessary
 It may include:
◦ sample I/O formats
◦ DFD, ERD documents
◦ results of user surveys, cost analysis
studies
◦ supporting documents to help readers of
SRS

26. Characteristics of a Good SRS
 Unambiguous
 Complete
 Verifiable
 Consistent
 Modifiable
 Traceable
 Usable during the Operation
and Maintenance phase

27. Modifiable
 Structure and style of SRS is such that
changes to requirements can be made
easily, completely and consistently.
◦ SRS organisation -- table of contents,
index, explicit cross-referencing
◦ no redundancy

28. Traceable
 An SRS is traceable if the origin of each
requirement is clear and it facilitates the
referencing of each requirement in
future.
 Backward traceability
◦ requirement explicitly referencing its source
in previous documents
 Foward traceability
◦ each requirement has a unique name or
reference number and it can be traced to
design documents, program

29. Examples of Bad SRS
Documents
Unstructured Specifications:
◦ Narrative essay --- one of the worst types of
specification document:
 Difficult to change,
 difficult to be precise,
 difficult to be unambiguous,
 scope for contradictions, etc.
 Presence of text containing information
irrelevant to the problem.
aspects important to proper solution of the
problem are omitted

30.  Contradictions :
◦Contradictions might arise
if the same thing described
at several places in different
ways
 Wishful Thinking :
◦Descriptions of aspects
for which realistic solutions
will be hard to find

31. SRS Review
 Formal Review done by Users,
Developers, Managers, Operations
personnel
 To verify that S.R.S. confirms to the
actual user requirements
 To detect defects early and correct
them.