Skip to main content
  1. Resources/
  2. Study Materials/
  3. Information & Communication Technology Engineering/
  4. ICT Semester 5/
  5. Software Engineering (4353202)/

2 mins· ·
Milav Dabgar
Author
Milav Dabgar
Experienced lecturer in the electrical and electronic manufacturing industry. Skilled in Embedded Systems, Image Processing, Data Science, MATLAB, Python, STM32. Strong education professional with a Master’s degree in Communication Systems Engineering from L.D. College of Engineering - Ahmedabad.
Lecture 12: Software Requirement Specification (SRS)

Lecture 12: Software Requirement Specification (SRS)

Unit 3: Requirement Analysis and Design (4353202)

Lecture Agenda

  • Recap of Requirement Gathering and Analysis
  • What is an SRS?
  • Purpose and Importance of the SRS
  • Characteristics of a Good SRS
  • Standard SRS Template (IEEE 830)
  • Key Takeaways

Recap of Requirement Gathering and Analysis

In the last lecture, we discussed how to gather requirements using various techniques and the importance of analyzing them for completeness, consistency, and clarity.

What is an SRS?

A Software Requirement Specification (SRS) is a detailed document that describes what a software system should do. It is the main output of the requirement analysis phase.

It serves as a contract between the development team and the customer.

Purpose and Importance of the SRS

  • Communication: Provides a clear and common understanding of the requirements among all stakeholders.
  • Foundation for Design: Guides the design and development teams.
  • Basis for Testing: Forms the basis for writing test cases.
  • Project Management: Helps in project planning, estimation, and tracking.
  • Reduces Development Effort: A well-written SRS can prevent rework and reduce development costs.

Characteristics of a Good SRS

  • Correct: Every requirement stated is one that the software shall meet.
  • Unambiguous: Every requirement has only one interpretation.
  • Complete: Includes all significant requirements, whether relating to functionality, performance, design constraints, attributes, or external interfaces.
  • Consistent: No two requirements conflict with each other.
  • Ranked for Importance and/or Stability: Requirements are prioritized.
  • Verifiable: There exists some finite cost-effective process with which a person or machine can check that the software product meets the requirement.
  • Modifiable: Its structure and style are such that any changes to the requirements can be made easily, completely, and consistently.
  • Traceable: The origin of each requirement is clear, and it facilitates the referencing of each requirement in future development.

Standard SRS Template (Based on IEEE 830)

  1. Introduction
    • Purpose
    • Scope
    • Definitions, Acronyms, and Abbreviations
    • References
    • Overview
  2. Overall Description
    • Product Perspective
    • Product Functions
    • User Characteristics
    • Constraints
    • Assumptions and Dependencies
  3. Specific Requirements
    • External Interface Requirements
    • Functional Requirements
    • Non-Functional Requirements
    • Database Requirements
  4. Appendices

Key Takeaways

  • The **SRS** is a critical document that formally defines the software to be built.
  • It serves as a **contract** and a **communication tool** for all stakeholders.
  • A good SRS must be **correct, complete, unambiguous, verifiable, and modifiable**.
  • Following a standard template like **IEEE 830** helps in creating a comprehensive SRS.

Next Lecture

Topic: Functional Requirements

Q & A

Questions & Discussion