Software Requirement Specification (SRS): Characteristics, Format & IEEE Standards
Before developers start designing or coding software, everyone involved in the project needs a clear understanding of what the software is expected to do. A Software Requirements Specification provides that common understanding by documenting the required functions, interfaces, constraints and quality expectations of the software.
A Software Requirements Specification (SRS) is a structured document that describes what a software system is expected to do, the services it must provide, the constraints under which it must operate and the quality requirements it should satisfy.
In simple words, an SRS answers: “What exactly should this software do?”
Why Does SRS Feel Difficult to Students?
The definition of SRS is easy. The difficult part begins when students see terms such as functional requirements, non-functional requirements, interfaces, constraints, traceability, verification, IEEE format and requirement characteristics together.
The easiest way to understand SRS is to imagine that a customer gives a software project to a development company.
The customer knows what problem needs to be solved, while developers need exact details before they can build the solution.
The customer explains what is needed.
The analyst studies and organises those needs.
The SRS records them in a clear and structured form so that developers, testers, managers and customers can refer to the same requirements.
SRS Full Form
SRS stands for:
A formal description of the requirements that software should satisfy.
What is a Software Requirement?
Before understanding the complete SRS, we should understand the word requirement.
A software requirement describes a capability, behaviour, quality or constraint that the software must satisfy.
“The system shall allow a registered student to download the examination admit card.”
This is a software requirement because it clearly describes one capability expected from the system.
Requirement vs SRS
| Basis | Requirement | SRS |
|---|---|---|
| Meaning | One specific need or condition | Complete structured collection of software requirements |
| Example | User shall be able to reset password | Document containing login, security, performance, interface and other requirements |
| Scope | Small | Entire software system or defined software scope |
Purpose of an SRS Document
The main purpose of SRS is to establish a clear understanding of software requirements before major design and development work begins.
Defines Software Scope
It makes clear what is included in the software and what is outside the agreed scope.
Guides Developers
Developers use requirements to understand what functions and behaviour must be implemented.
Supports Testing
Testers use requirements to determine whether the finished software behaves as expected.
Reduces Misunderstanding
Customers, analysts and developers can refer to the same documented expectations.
Supports Planning
Clear requirements help estimate effort, resources, cost and schedule.
Controls Changes
Requirement changes can be tracked and reviewed more systematically.
Who Uses the SRS?
SRS is not written only for programmers. Several project stakeholders may depend on it.
Customer
Checks whether the documented requirements represent the actual business need.
Business Analyst
Collects, analyses, organises and clarifies requirements.
Developer
Uses requirements as input while designing and implementing software.
Tester
Uses requirements while preparing verification and validation activities.
Project Manager
Uses the scope and requirements while planning resources, schedule and effort.
Maintenance Team
Uses the document to understand the intended behaviour when the system is changed later.
Where Does SRS Fit in the SDLC?
The SRS is normally prepared during the requirements engineering or requirement analysis stage of software development.
In practice, requirements may continue to evolve, especially in iterative and Agile development. Therefore, the requirements documentation may also be updated through controlled changes during the project.
Types of Requirements in an SRS
A strong SRS normally contains more than a list of software features. It should capture several types of requirements.
1. Functional Requirements
Functional requirements describe what the software must do.
They describe functions, services, calculations, processing and system behaviour.
- The system shall allow users to log in using registered credentials.
- The system shall allow an administrator to create student accounts.
- The system shall generate monthly attendance reports.
- The system shall calculate the total order amount.
- The system shall send a password-reset link to the registered email address.
2. Non-Functional Requirements
Non-functional requirements describe the quality, performance and operational expectations of the system.
Instead of describing only what the system does, they often describe how well it should perform or what constraints it must satisfy.
Performance
Response time, processing speed, throughput and capacity.
Security
Authentication, authorization, confidentiality and protection requirements.
Reliability
Expected dependable operation and failure-related requirements.
Availability
How frequently and for how long the system should remain available.
Usability
Expectations related to ease of learning and use.
Maintainability
Requirements that support future correction and modification.
“The system shall display the search results within 2 seconds for 95% of requests under the specified normal operating load.”
3. External Interface Requirements
Interface requirements define how the software interacts with users, hardware, other software systems or communication services.
User Interface
Describes important interaction requirements between users and the system.
Hardware Interface
Describes interactions with hardware devices when applicable.
Software Interface
Describes communication with other software, databases or external services.
Communication Interface
Describes communication-related requirements such as protocols or network interactions, where relevant to the project.
4. Constraints
Constraints place limits on how the software or project can operate.
- The system must operate on an approved organisational platform.
- Only authorised staff may access administrative functions.
- The software must follow applicable data-protection requirements.
- The application must integrate with an existing institutional system.
5. Assumptions and Dependencies
Assumptions describe conditions that are expected to be true but are not fully controlled by the software.
Dependencies describe external items on which the software relies.
An online payment application may depend on an external payment service. If that service is unavailable, some payment functions may also become unavailable.
Characteristics of a Good SRS
The classic IEEE 830-1998 guidance is still frequently taught in software engineering courses because it describes eight important characteristics of a good SRS.
These characteristics are:
1. Correct
Every documented requirement should represent a genuine requirement that the intended software must satisfy.
2. Unambiguous
Each requirement should have only one clear interpretation.
3. Complete
Important functions, responses, constraints, interfaces and required behaviour should not be missing.
4. Consistent
Requirements should not conflict with one another or use contradictory terminology.
5. Ranked for Importance or Stability
Requirements may be classified according to importance, priority or expected stability.
6. Verifiable
It should be possible to check whether the software satisfies each requirement.
7. Modifiable
The SRS should be organised so requirements can be changed cleanly without creating unnecessary inconsistency.
8. Traceable
Requirements should be identifiable and capable of being traced to their source and to later development or verification work.
Understanding SRS Characteristics with Examples
Correct Requirement
A requirement is correct when it accurately represents the actual stakeholder need.
If students are genuinely required to log in before accessing examination results, the requirement stating this behaviour is correct.
Unambiguous Requirement
Avoid words that can have different meanings for different people.
What does “quickly” mean? One second? Five seconds? Twenty seconds?
Complete Requirement Set
If the software requires user registration, the SRS should not explain only registration and forget related behaviour such as validation, confirmation, errors and applicable account rules.
Consistent Requirements
Users must create passwords containing at least 8 characters.
Requirement B:All user passwords must contain exactly 6 characters.
These two requirements conflict, so the SRS is inconsistent.
Verifiable Requirement
“The application shall have an excellent interface.”
“Excellent” is subjective and difficult to verify directly.
Define measurable usability criteria relevant to the project so that they can be evaluated using a stated test or review method.
Traceable Requirement
A traceable requirement normally has a unique identifier.
FR-LOGIN-01 — The system shall authenticate registered users using valid credentials.
This identifier can later be referenced by design documents, development tasks and test cases.
Easy Memory Trick for Good SRS Characteristics
Correct – Unambiguous – Complete – Consistent – Ranked – Verifiable – Modifiable – Traceable
Instead of trying to remember all eight randomly, divide them into groups:
Quality: Correct, Unambiguous, Complete, Consistent
Management: Ranked, Modifiable, Traceable
Testing: Verifiable
IEEE Standards for Software Requirements Specification
This part is important because many university notes still refer to IEEE 830, while modern requirements engineering uses a newer international standard.
Earlier IEEE recommended practice specifically focused on Software Requirements Specifications and became widely used in software engineering education.
The 1998 edition described qualities of a good SRS and provided example SRS structures. This is the version commonly mentioned in university textbooks and examination questions.
Requirements engineering guidance was later brought into the ISO/IEC/IEEE 29148 family of standards covering requirements processes and requirements-related information across systems and software life cycles.
This is the current published international requirements-engineering standard discussed in this article.
If your university syllabus specifically asks for “IEEE 830 SRS format”, write the classical IEEE 830-style answer expected by the syllabus.
If you are discussing present-day standards, mention that IEEE 830-1998 has been superseded and that the modern requirements-engineering reference is ISO/IEC/IEEE 29148:2018.
What is ISO/IEC/IEEE 29148:2018?
ISO/IEC/IEEE 29148:2018 is an international standard dealing with requirements engineering for systems and software.
It addresses requirements-related processes and information across the life cycle, rather than treating requirements only as one document prepared once at the beginning.
It also provides guidance related to the construction and characteristics of requirements, requirements engineering activities and requirements information items.
IEEE 830 is often remembered mainly as the traditional SRS recommended practice.
ISO/IEC/IEEE 29148 provides a broader modern requirements engineering framework.
Traditional IEEE 830-Style SRS Format
There is no need to panic when you see the SRS format. At a high level, it can be understood in three major sections:
The exact headings can be tailored according to the project and the required documentation approach. The important point is that requirements should remain clear, organised and verifiable.
Section 1: Introduction of SRS
The Introduction explains why the document exists and what software product or scope it describes.
1.1 Purpose
This section explains the purpose of the SRS and may identify the intended audience.
“This document specifies the software requirements for the College Library Management System intended for students, librarians and authorised administrators.”
1.2 Scope
Scope explains what the software will provide and defines its boundaries.
It may include major objectives, benefits and high-level functions.
Stakeholders expecting features that were never actually included in the approved software scope.
1.3 Definitions, Acronyms and Abbreviations
Technical terms and abbreviations that may be unclear to readers should be defined.
SRS: Software Requirements Specification
Admin: Administrator
API: Application Programming Interface
1.4 References
This section identifies relevant documents, policies, standards or other sources referenced while defining the requirements.
1.5 Overview
The overview briefly explains how the remaining SRS document is organised.
Section 2: Overall Description
Overall Description provides a high-level understanding of the software before detailed requirements are introduced.
2.1 Product Perspective
This explains how the proposed software fits into its environment.
It may identify whether the product is:
- A completely new independent system
- A replacement for an existing system
- A component of a larger system
- An application integrated with external services
2.2 Product Functions
This provides a high-level summary of the important functions.
- User login
- Book search
- Book issue
- Book return
- Fine calculation
- Member management
- Report generation
2.3 User Characteristics
Different users may have different knowledge, permissions and needs.
| User | Main Role | Typical Access |
|---|---|---|
| Student | Search and use library services | Limited user functions |
| Librarian | Manage issue and return operations | Operational functions |
| Administrator | Manage users and configuration | Administrative functions |
2.4 Constraints
This section documents important limitations that affect the software.
2.5 Assumptions and Dependencies
This records relevant assumptions and external dependencies that can affect the software or its requirements.
Section 3: Specific Requirements
This is normally the most detailed and important part of the SRS.
Here we describe exactly what the software must do and the quality or constraints it must satisfy.
Using Unique Requirement IDs
Each important requirement should have a unique identifier so that it can be discussed and traced easily.
FR-01 — User Registration
FR-02 — User Login
FR-03 — Search Book
NFR-01 — Performance Requirement
NFR-02 — Security Requirement
A project may use another naming system. The main purpose is to keep identifiers unique and stable enough for traceability.
Why “Shall” is Commonly Used in Requirements
Requirements are often written using a form such as:
The purpose is to express a required capability clearly and consistently.
“The system shall lock the user account after the configured number of consecutive failed authentication attempts.”
Whatever terminology the project chooses, the meanings of mandatory, recommended and optional statements should remain clear and consistent.
Keep Requirements Atomic
An atomic requirement expresses one main requirement rather than combining several unrelated requirements into one sentence.
“The system shall allow users to log in, update the profile, upload documents, reset passwords and generate reports.”
This statement contains several different requirements.
FR-01 — The system shall allow registered users to authenticate.
FR-02 — The system shall allow authenticated users to update permitted profile information.
FR-03 — The system shall allow authorised users to upload supported documents.
FR-04 — The system shall provide a password-reset process.
Practical Requirement Writing Format
A project may use a structured requirement record similar to this:
| Field | Example |
|---|---|
| Requirement ID | FR-AUTH-01 |
| Title | User Authentication |
| Description | The system shall authenticate a registered user using valid credentials. |
| Source | Approved stakeholder requirement |
| Priority | High |
| Verification | Functional test |
| Related Requirement | NFR-SEC-01 |
Good Requirement vs Bad Requirement
| Weak Requirement | Problem | Better Direction |
|---|---|---|
| The app should be fast. | “Fast” is undefined. | Define measurable response criteria. |
| The interface should be user-friendly. | Subjective wording. | Define measurable usability expectations. |
| Maybe users can export reports. | Uncertain requirement. | Decide whether export is required. |
| The system shall normally be secure. | “Normally” and “secure” are too vague alone. | Specify required security controls and conditions. |
| The website should support many users. | “Many” cannot be tested. | Define expected load and performance targets. |
How is an SRS Prepared?
Understand the Business Problem
First understand why the software is needed and what problem it should solve.
Identify Stakeholders
Identify users, customers, administrators, managers and other people or systems that influence the requirements.
Elicit Requirements
Collect requirements using suitable methods such as interviews, observation, workshops, existing documents, questionnaires, prototypes and discussions.
Analyse Requirements
Remove unclear statements, resolve conflicts, identify missing information and understand priorities.
Define Scope
Clearly identify what is included in the software and what is outside the scope.
Classify Requirements
Organise functional requirements, non-functional requirements, interfaces, constraints and data-related requirements.
Assign Requirement IDs
Give important requirements unique identifiers for traceability.
Write Clear Requirements
Use specific, understandable and testable statements.
Review the SRS
Check completeness, consistency, ambiguity, feasibility and verifiability.
Validate with Stakeholders
Confirm that the SRS represents the intended needs before using it as the main requirements baseline or agreed reference.
Requirement Elicitation vs Requirement Analysis vs SRS
| Activity | Main Question | Purpose |
|---|---|---|
| Requirement Elicitation | What do stakeholders need? | Collect requirements |
| Requirement Analysis | Are the collected requirements clear and feasible? | Study, refine and resolve requirements |
| SRS | How will the agreed software requirements be documented? | Record requirements in a structured form |
SRS vs Software Design Document
This difference is extremely important.
Design = HOW
| Basis | SRS | Design Document |
|---|---|---|
| Main Focus | What software should satisfy | How the solution will be designed |
| Contains | Requirements and constraints | Architecture and design decisions |
| Prepared Around | Requirements engineering | Design stage |
| Main Audience | Stakeholders, analysts, developers, testers | Developers, architects and technical team |
SRS vs BRD
A Business Requirements Document and an SRS can overlap in some organisations, but their emphasis is generally different.
| Basis | BRD | SRS |
|---|---|---|
| Focus | Business needs and objectives | Software requirements |
| Detail | Usually higher level | Usually more detailed software-specific requirements |
| Main Question | Why and what does the business need? | What must the software satisfy? |
SRS vs Use Case
A use case normally explains an interaction or goal involving an actor and the system. An SRS is broader and may contain many functional requirements, non-functional requirements, constraints and interface requirements.
Use cases can therefore support the requirements documented in an SRS rather than replacing the complete specification.
What is Requirement Traceability?
Traceability means being able to follow a requirement through related project information.
Forward Traceability
Helps track a requirement toward later stages such as design, implementation and testing.
Backward Traceability
Helps identify where a requirement came from or why a particular feature exists.
Requirement Traceability Matrix (RTM)
A Requirement Traceability Matrix can be used to map requirements to related project elements such as test cases.
| Requirement ID | Requirement | Priority | Test Case | Status |
|---|---|---|---|---|
| FR-01 | User Login | High | TC-LOGIN-01 | Verified |
| FR-02 | Password Reset | High | TC-RESET-01 | Verified |
| FR-03 | Generate Report | Medium | TC-REPORT-01 | Pending |
Simple SRS Example: Library Management System
Now let us combine the concepts into a simple example.
1. Purpose
The purpose of the Library Management System is to support the management of library members, books, issue operations, returns and related records.
2. Scope
The system will allow authorised users to manage library activities and students to search permitted book information.
3. Users
- Student
- Librarian
- Administrator
4. Functional Requirements
FR-01: The system shall allow registered users to authenticate.
FR-02: The system shall allow users to search books using supported search fields.
FR-03: The system shall allow an authorised librarian to issue an available book to an eligible member.
FR-04: The system shall record returned books.
FR-05: The system shall calculate the applicable overdue fine according to the configured rule.
5. Non-Functional Requirements
NFR-01: The system shall enforce access permissions according to assigned user roles.
NFR-02: Performance targets shall be defined for normal operating load and verified using agreed test conditions.
6. Assumption
Users will have access to the supported network environment required to use the system.
SRS Review Checklist
Before an SRS is accepted, reviewers should check whether the requirements are clear enough to support design, development and testing.
Common Mistakes While Writing SRS
Mistake 1: Using Vague Words
Words such as fast, easy, user-friendly, sufficient, efficient and flexible can become ambiguous if they are not supported by measurable criteria.
Mistake 2: Mixing Requirement and Design
SRS should primarily describe required behaviour and constraints. Unnecessary implementation decisions should not be added as requirements unless they are genuine project constraints.
Mistake 3: Combining Too Many Requirements
One giant sentence may contain several independent requirements and become difficult to trace or test.
Mistake 4: Ignoring Non-Functional Requirements
Software may provide all required features but still fail because performance, security, usability or reliability expectations were never defined.
Mistake 5: Writing Requirements That Cannot Be Tested
If nobody can determine whether the requirement has been satisfied, the wording needs improvement.
Mistake 6: Duplicate Requirements
Repeating the same requirement in multiple sections can cause inconsistency when one copy is changed and another is forgotten.
Mistake 7: Missing Requirement IDs
Without stable identifiers, discussion, change tracking and test mapping become more difficult.
Mistake 8: Writing SRS After Coding
An SRS written only to match software that has already been built loses much of its value as a requirements communication and planning document.
Advantages of Software Requirements Specification
Clear Understanding
Gives stakeholders a common reference for required software behaviour.
Better Planning
Helps teams understand scope before estimating development effort.
Supports Testing
Test scenarios can be derived from clear and verifiable requirements.
Reduces Rework
Early clarification can prevent misunderstandings from becoming expensive changes later.
Controls Scope
Makes it easier to recognise when a requested feature is outside the agreed requirements.
Supports Maintenance
Future teams can understand the intended behaviour and requirement history more easily.
Limitations and Challenges of SRS
SRS is useful, but creating a strong specification requires time and continuous stakeholder involvement.
- Requirements may change during development.
- Stakeholders may not know all requirements at the beginning.
- Large SRS documents can become difficult to maintain.
- Ambiguous language can create misunderstanding.
- Conflicting stakeholder needs may require negotiation.
- Keeping requirements and test evidence traceable requires discipline.
- An outdated SRS can become misleading if changes are not maintained properly.
Is SRS Used in Agile Development?
Yes, requirements documentation can still exist in Agile projects, but the form and level of detail may differ from a traditional large specification prepared completely before development starts.
Agile teams may document requirements using:
- User stories
- Acceptance criteria
- Product backlog items
- Models and diagrams
- Interface specifications
- Non-functional requirement records
- Supporting requirement documents
Agile does not mean “no requirements”. It changes how requirements may be discovered, documented, prioritised and updated.
Relationship Between SRS and Software Testing
Good requirements make testing easier because the expected result is clear.
Requirement: “The system shall reject authentication when the supplied password is incorrect.”
Test: Enter a registered username with an incorrect password.
Expected Result: Authentication is rejected according to the specified behaviour.
SRS and Requirement Change Management
Requirements can change because of new business needs, laws, user feedback, technical limitations or project discoveries.
Therefore, requirement changes should be controlled rather than silently inserted into the document.
Exam-Oriented Definition of SRS
A Software Requirements Specification (SRS) is a structured document that describes the functional requirements, non-functional requirements, interfaces, constraints and other important requirements of a software system. It provides a common reference for customers, analysts, developers and testers during software development.
2 Marks Question: What is SRS?
SRS stands for Software Requirements Specification. It is a document that describes what a software system must do and the requirements and constraints it must satisfy.
5 Marks Question: Characteristics of a Good SRS
The classical IEEE 830 characteristics of a good SRS are:
- Correct
- Unambiguous
- Complete
- Consistent
- Ranked for importance and/or stability
- Verifiable
- Modifiable
- Traceable
5 Marks Question: Explain SRS Format
A commonly taught IEEE 830-style SRS structure contains three major sections:
- Introduction: Purpose, scope, definitions, references and overview.
- Overall Description: Product perspective, functions, user characteristics, constraints, assumptions and dependencies.
- Specific Requirements: Detailed functional, interface, performance, data, quality and other requirements.
10 Marks Question: Explain SRS in Detail
For a long-answer question, write the answer in this order:
- Define SRS.
- Explain its purpose.
- Explain functional requirements.
- Explain non-functional requirements.
- Explain external interface requirements.
- Explain characteristics of a good SRS.
- Explain IEEE-style SRS structure.
- Mention requirement traceability.
- Give one practical example.
- Write advantages and conclusion.
Important IEEE Exam Note
Many university questions still use phrases such as:
“Explain IEEE standard SRS format.”
In that case, write the classical IEEE 830-style structure that your syllabus expects.
For an updated answer, you can add one final sentence:
IEEE 830-1998 was superseded, and modern requirements engineering is covered by ISO/IEC/IEEE 29148.
Important Differences for Quick Revision
| Concept | Main Question |
|---|---|
| Feasibility Study | Should we build the software? |
| Requirement Elicitation | What do stakeholders need? |
| Requirement Analysis | Are those requirements clear, consistent and feasible? |
| SRS | What requirements must the software satisfy? |
| Software Design | How will the solution be structured? |
| Testing | Does the implemented software satisfy the required behaviour? |
Quick Revision Notes
- SRS stands for Software Requirements Specification.
- It documents what software is required to do and the constraints or qualities it must satisfy.
- Functional requirements describe software functions and behaviour.
- Non-functional requirements describe qualities and constraints such as performance, security, reliability and usability.
- External interface requirements describe interaction with users, hardware, software or communication interfaces.
- Traditional IEEE 830 characteristics include Correct, Unambiguous, Complete, Consistent, Ranked, Verifiable, Modifiable and Traceable.
- Traditional SRS structure commonly contains Introduction, Overall Description and Specific Requirements.
- SRS should describe requirements rather than unnecessarily fixing design details.
- Important requirements should have unique IDs.
- A strong requirement should be clear and verifiable.
- Traceability connects stakeholder needs, requirements and later project work.
- RTM stands for Requirement Traceability Matrix.
- IEEE 830-1998 is historically important but has been superseded.
- ISO/IEC/IEEE 29148:2018 is the current published international requirements-engineering standard discussed here.
- Easy memory: SRS = WHAT, Design = HOW.
Frequently Asked Questions
What is SRS in Software Engineering?
SRS stands for Software Requirements Specification. It is a structured document describing the requirements that a software system must satisfy.
What is the full form of SRS?
The full form of SRS is Software Requirements Specification.
Why is SRS important?
SRS gives stakeholders a common understanding of software requirements and supports design, development, testing, planning and future maintenance.
What are the characteristics of a good SRS?
The classical IEEE 830 characteristics are Correct, Unambiguous, Complete, Consistent, Ranked for importance and/or stability, Verifiable, Modifiable and Traceable.
What are functional requirements?
Functional requirements describe services, functions and behaviour that the software must provide.
What are non-functional requirements?
Non-functional requirements describe qualities or constraints such as performance, security, reliability, availability and usability.
What are the main sections of an SRS?
A commonly taught traditional structure contains Introduction, Overall Description and Specific Requirements, with relevant subsections.
What is IEEE 830?
IEEE 830 was the IEEE Recommended Practice for Software Requirements Specifications and is still widely discussed in software engineering education.
Is IEEE 830 still the current SRS standard?
No. IEEE 830-1998 has been superseded. Modern requirements-engineering guidance is provided through ISO/IEC/IEEE 29148.
What is ISO/IEC/IEEE 29148:2018?
It is an international standard covering requirements engineering processes, requirements information and guidance for systems and software requirements.
What is requirement traceability?
Requirement traceability is the ability to connect a requirement with its source and related project work such as design elements and verification activities.
What is an RTM?
RTM stands for Requirement Traceability Matrix. It is used to map requirements to related items such as test cases.
What is the difference between SRS and software design?
SRS primarily describes what the software must satisfy, while software design describes how the technical solution will be organised and implemented.
Can SRS be used in Agile projects?
Requirements documentation can still be used in Agile projects, although teams may maintain requirements incrementally using user stories, acceptance criteria, backlog items, models and supporting specifications.
What makes a requirement verifiable?
A requirement is verifiable when there is a practical method for determining whether the implemented software satisfies it.
Conclusion
A Software Requirements Specification is one of the most important outputs of requirements engineering because it converts stakeholder needs into a structured description of what the software is expected to satisfy.
A strong SRS does more than list features. It describes functional requirements, non-functional requirements, interfaces, constraints, assumptions and other information needed to understand the expected software behaviour.
Students should especially remember the traditional characteristics of a good SRS: Correct, Unambiguous, Complete, Consistent, Ranked, Verifiable, Modifiable and Traceable.
It is also important to understand the standards correctly. IEEE 830 remains important from an academic and historical point of view because many university syllabi still teach its SRS format. However, modern requirements engineering is addressed through the ISO/IEC/IEEE 29148 standard family.
SRS = What should the software satisfy?
Design = How will we build the solution?
Testing = Did we satisfy the requirement?
