Software requirements specification

24,752 views

Published on

The Software Requirements Document
Sometimes Called Software Requirements Specification (SRS)

What is an SRS?

SRS is the official statement of what the system developers should implement.
SRS is a complete description of the behavior of the system to be developed.
SRS should include both a definition of user requirements and a specification of the system requirements.
The SRS fully describes what the software will do and how it will be expected to perform.

What is the purpose of an SRS?

The SRS precisely defines the software product that will be built.
SRS used to know all the requirements for the software development and thus that will help in designing the software.
It provides feedback to the customer.

Users of a Requirements Document,

Structure of the Requirements Document:

A number of large organizations, such as the US Department of Defense and the IEEE, have defined standards for requirements documents.
The most widely known standard is IEEE/ANSI 830-1998 (IEEE, 1998).
This IEEE standard suggests the following structure for requirements documents:

Structure Explained

1. INTRODUCTION
Purpose
Describe the purpose of the SRS, not the purpose of the software being developed.
Intended audience for SRS.
Scope
Describe application of software (benefits, objectives).
Explain what software will (not) do.


Structure Explained

1. INTRODUCTION
Definitions/acronyms/abbreviations
Definitions of terms and abbreviations that are used in the SRS.
E.g.
User: The person operating and/or using the software system.
References
A complete list of all documents referenced elsewhere in the SRS.
Specify the sources from which the references can be obtained.
Overview
Brief description of rest of SRS.
How the SRS is organized






Structured Explained

2. OVERALL DESCRIPTION
Product Perspective
If the product is independent and totally self-contained, it should be stated here.
Describe the functions of each component of the larger system or project, and identify interfaces.
Product Functions
Provide a summary of the functions that the software will perform.
Block diagrams showing the different functions and their relationships can be helpful.

User Characteristics
Describe those general characteristics of the eventual users of the product that will affect the specific requirements.




Structured Explained

2. OVERALL DESCRIPTION
Constraints
Provide a general description of any other items that will limit the developer's options for designing the system.
E.g.
1. The software system will run under Windows.
2. All code shall be written in Java.

Assumptions and Dependencies
List and description of each of the factors that affect the requirements stated in the SRS.

Structured Explained

2. OVERALL DESCRIPTION
Apportioning Of Requirements
Identify requirements that may be delayed until future versions of the system.



Published in: Education
0 Comments
28 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
24,752
On SlideShare
0
From Embeds
0
Number of Embeds
26
Actions
Shares
0
Downloads
1,425
Comments
0
Likes
28
Embeds 0
No embeds

No notes for slide

Software requirements specification

  1. 1. 6.5 The SoftwareRequirements DocumentSometimes Called Software Requirements Specification (SRS)
  2. 2. What is an SRS• SRS is the official statement of what the systemdevelopers should implement.• SRS is a complete description of the behavior of thesystem to be developed.• SRS should include both a definition of userrequirements and a specification of the systemrequirements.• The SRS fully describes what the software will do andhow it will be expected to perform.
  3. 3. What is the purpose of anSRS?• The SRS precisely defines the software product thatwill be built.• SRS used to know all the requirements for thesoftware development and thus that will help indesigning the software.• It provides feedback to the customer.
  4. 4. Users of a RequirementsDocument
  5. 5. Users of a RequirementsDocument
  6. 6. Structure of The RequirementsDocumentA number of large organizations, such as the USDepartment of Defense and the IEEE, have definedstandards for requirements documents.The most widely known standard is IEEE/ANSI 830-1998(IEEE, 1998).This IEEE standard suggests thefollowing structure for requirements documents:
  7. 7. Structure Explained1.INTRODUCTION Purpose Describe the purpose of the SRS, not the purpose of the software beingdeveloped. Intended audience for SRS. Scope Describe application of software (benefits, objectives). Explain what software will (not) do.
  8. 8. Structure Explained1.INTRODUCTION Definitions/acronyms/abbreviations Definitions of terms and abbreviations that are used in the SRS.E.g.User: The person operating and/or using the software system. References A complete list of all documents referenced elsewhere in the SRS. Specify the sources from which the references can be obtained. Overview Brief description of rest of SRS. How the SRS is organized
  9. 9. Structured Explained2.OVERALL DESCRIPTION Product Perspective If the product is independent and totally self-contained, it should be statedhere. Describe the functions of each component of the larger system orproject, and identify interfaces. Product Functions Provide a summary of the functions that the software will perform. Block diagrams showing the different functions and their relationshipscan be helpful. User Characteristics Describe those general characteristics of the eventual users of the productthat will affect the specific requirements.
  10. 10. Structured Explained2.OVERALL DESCRIPTION Constraints Provide a general description of any other items that will limit thedevelopers options for designing the system.E.g.1. The software system will run under Windows.2. All code shall be written in Java. Assumptions and Dependencies List and description of each of the factors that affect the requirementsstated in the SRS.
  11. 11. Structured Explained2.OVERALL DESCRIPTION Apportioning Of Requirements Identify requirements that may be delayed until future versions of thesystem.
  12. 12. Structured Explained3.SPECIFIC REQUIREMENTS External Interface Requirements The characteristics that the software must support for each humaninterface to the software product.E.g.1. Required screen formats2. Page layout and content of any reports or menus.3. Network Protocols Performance Requirements Capacity1. No. of simultaneous users2. Processing requirements for normal and peak loads
  13. 13. Structured Explained3.SPECIFIC REQUIREMENTS1. Response Time2. System priorities for users and functions. Design Constraints Specify design constrains imposed by other standards, companypolicies, hardware limitation, etc. that will impact this software project.
  14. 14. Characteristics of a good SRS• Correct : Every requirement given in SRS is arequirement of the software.• Unambiguous: Every requirement hasexactly one interpretation.• Complete: Includes allfunctional, performance, design, externalinterface requirements; definition of theresponse of the software to all inputs.• Consistent: Internal consistency.• Ranked importance: Essential vs. desirable.
  15. 15. Characteristics of a good SRS• Verifiable: A requirement is verifiable if and only ifthere exists some finite cost effective process withwhich a person or machine can check that the SWmeets the requirement.• Modifiable: SRS must be structured to permit effectivemodifications (e.g. don’t be redundant, keeprequirements separate)• Traceable: Origin of each requirement is clear.

×