Software Requirements Specification (SRS) in Software Engineering - Step-by-Step Execution

Concept Flow - Software Requirements Specification (SRS)

Start: Gather Stakeholder Needs

↓

Analyze and Document Requirements

↓

Organize Requirements into SRS Document

↓

Review and Validate with Stakeholders

↓

Finalize and Approve SRS

↓

Use SRS for Development

The flow shows how stakeholder needs are gathered, analyzed, documented in the SRS, reviewed, and then used for software development.

Execution Sample

Software Engineering

1. Collect user needs
2. Write clear requirements
3. Review with users
4. Finalize SRS document

This sequence outlines the main steps to create a Software Requirements Specification document.

Analysis Table

Step	Action	Input	Output	Notes
1	Gather Stakeholder Needs	Interviews, surveys	List of needs	Start by understanding what users want
2	Analyze and Document Requirements	List of needs	Draft requirements	Translate needs into clear, testable requirements
3	Organize into SRS Document	Draft requirements	Structured SRS document	Arrange requirements logically with sections
4	Review and Validate	SRS draft	Feedback from stakeholders	Ensure requirements are correct and complete
5	Finalize and Approve	Reviewed SRS	Approved SRS document	Sign-off by stakeholders
6	Use SRS for Development	Approved SRS	Development plan	Developers use SRS as guide
7	End	N/A	N/A	Process complete

💡 All steps completed and SRS approved for use in development

State Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	Final
Stakeholder Needs	None	Collected	Analyzed	Documented	Reviewed	Approved	Used in development
SRS Document	None	None	Draft created	Structured draft	Reviewed draft	Final approved	Reference for development

Key Insights - 3 Insights

Why is it important to review the SRS with stakeholders before finalizing?

Reviewing ensures the requirements are accurate and complete, preventing misunderstandings later. This is shown in step 4 of the execution_table where feedback is gathered.

What happens if stakeholder needs are not clearly gathered at the start?

If needs are unclear, the requirements will be incomplete or wrong, causing problems in later steps. Step 1 shows gathering needs is the foundation.

Why must requirements be testable and clear in the SRS?

Clear, testable requirements allow developers and testers to verify the software meets expectations, as emphasized in step 2 where needs are translated into requirements.

Visual Quiz - 3 Questions

Look at the execution_table, what is the output after Step 3?

A List of stakeholder needs

B Structured SRS document

C Feedback from stakeholders

D Approved SRS document

💡 Hint

Check the 'Output' column for Step 3 in the execution_table.

At which step does the SRS document get approved?

A Step 2

B Step 4

C Step 5

D Step 6

💡 Hint

Look for 'Approved SRS document' in the 'Output' column of the execution_table.

If stakeholder feedback is ignored, which step's output is most likely incorrect?

A Step 5

B Step 3

C Step 1

D Step 4

💡 Hint

Consider the importance of review and approval steps in the execution_table.

Concept Snapshot

Software Requirements Specification (SRS):
- Captures all software requirements clearly and completely
- Created by gathering, analyzing, and documenting stakeholder needs
- Reviewed and approved by stakeholders before development
- Serves as a contract and guide for developers
- Must be clear, testable, and organized logically

Full Transcript

The Software Requirements Specification (SRS) process starts by gathering stakeholder needs through interviews and surveys. These needs are analyzed and translated into clear, testable requirements. The requirements are then organized into a structured SRS document. This draft is reviewed with stakeholders to ensure accuracy and completeness. After incorporating feedback, the SRS is finalized and approved. The approved SRS guides the software development process, ensuring the final product meets user expectations.

Practice

1. What is the primary purpose of a Software Requirements Specification (SRS) document?

easy

A. To list the hardware requirements only

B. To provide the final source code of the software

C. To describe the marketing strategy for the software

D. To clearly describe what the software must do and how it should perform

Solution

1. Step 1: Understand the role of SRS

   The SRS defines the software's functions and performance requirements.

2. Step 2: Eliminate unrelated options

   Options about source code, hardware only, or marketing do not match the SRS purpose.

3. Final Answer:

   To clearly describe what the software must do and how it should perform -> Option D

4. Quick Check:

   SRS = Software functions and performance [OK]

Hint: SRS = What & how software works, not code or marketing [OK]

Common Mistakes:

• Confusing SRS with source code documentation
• Thinking SRS only lists hardware needs
• Assuming SRS is for marketing plans

2. Which of the following is a correct characteristic of a good SRS document?

easy

A. It is clear, complete, and consistent

B. It is ambiguous and open to interpretation

C. It contains only high-level marketing goals

D. It is written only after coding is complete

Solution

1. Step 1: Identify qualities of a good SRS

   A good SRS must be clear, complete, and consistent to avoid confusion.

2. Step 2: Reject incorrect traits

   Ambiguity, marketing-only content, or writing after coding contradict good SRS practices.

3. Final Answer:

   It is clear, complete, and consistent -> Option A

4. Quick Check:

   Good SRS = Clear & complete [OK]

Hint: Good SRS is clear and complete, never ambiguous [OK]

Common Mistakes:

• Believing ambiguity is acceptable
• Confusing SRS with marketing documents
• Writing SRS after coding instead of before

3. Consider this excerpt from an SRS:
"The system shall allow users to log in using a username and password."
What type of requirement is this?

medium

A. Performance requirement

B. Functional requirement

C. Design constraint

D. Usability requirement

Solution

1. Step 1: Identify the requirement type

   The statement describes a specific function the system must perform: user login.

2. Step 2: Match to requirement categories

   Functional requirements describe what the system should do; performance relates to speed, design constraints limit design choices, usability relates to ease of use.

3. Final Answer:

   Functional requirement -> Option B

4. Quick Check:

   Login feature = Functional requirement [OK]

Hint: Functions = Functional requirements, not performance or design [OK]

Common Mistakes:

• Confusing functional with performance requirements
• Thinking login is a design constraint
• Assuming login relates only to usability

4. A software team wrote this SRS statement:
"The system shall respond to user input within 5 seconds."
However, users report delays longer than 5 seconds. What is the likely issue?

medium

A. The SRS is ambiguous about response time

B. The requirement is not testable

C. The system does not meet the performance requirement

D. The requirement is a design constraint, not a performance metric

Solution

1. Step 1: Analyze the SRS statement

   The statement sets a performance requirement: respond within 5 seconds.

2. Step 2: Interpret user feedback

   Users experiencing delays longer than 5 seconds means the system fails to meet this requirement.

3. Final Answer:

   The system does not meet the performance requirement -> Option C

4. Quick Check:

   Delays > 5s = Performance failure [OK]

Hint: If system is slow, it fails performance requirements [OK]

Common Mistakes:

• Thinking the SRS is ambiguous when it is clear
• Assuming requirement is untestable
• Confusing performance requirement with design constraint

5. You are tasked with writing an SRS for a new mobile app. Which approach best ensures the SRS helps build the right software efficiently?

hard

A. Include detailed functional and non-functional requirements with clear acceptance criteria

B. Write only high-level goals and leave details for developers to decide

C. Focus mainly on the user interface design and ignore backend requirements

D. Use vague language to allow flexibility during development

Solution

1. Step 1: Identify best SRS writing practice

   A good SRS includes detailed functional and non-functional requirements with clear acceptance criteria to guide development.

2. Step 2: Evaluate other options

   High-level goals only, ignoring backend, or vague language lead to misunderstandings and inefficiency.

3. Final Answer:

   Include detailed functional and non-functional requirements with clear acceptance criteria -> Option A

4. Quick Check:

   Detailed & clear SRS = Efficient, correct software [OK]

Hint: Clear, detailed requirements avoid errors and speed development [OK]

Common Mistakes:

• Writing vague or incomplete requirements
• Ignoring backend or non-functional needs
• Leaving details to developers without guidance