Software Requirements Specification (SRS) in Software Engineering - Mini Project: Build & Apply

Software Requirements Specification (SRS) Document Creation

📖 Scenario: You are part of a software development team. Your task is to create a clear and organized Software Requirements Specification (SRS) document for a new project. This document will help everyone understand what the software should do.

🎯 Goal: Build a simple SRS document structure step-by-step, including sections for Introduction, Overall Description, Specific Requirements, and Appendices.

📋 What You'll Learn

Create the main sections of an SRS document as dictionary keys

Add a project overview description

List functional requirements as a dictionary

Include a glossary of terms

💡 Why This Matters

🌍 Real World

SRS documents are used in software projects to clearly define what the software must do before development starts.

💼 Career

Understanding how to structure and write SRS documents is important for roles like business analysts, project managers, and software developers.

1

Create the SRS document structure

Create a dictionary called srs_document with these keys: 'Introduction', 'Overall Description', 'Specific Requirements', and 'Appendices'. Set each key's value to an empty dictionary.

Software Engineering

# Create the srs_document dictionary with the required keys and empty dictionaries
# Your code here

Hint

Use a dictionary with the exact keys and empty dictionaries as values.

2

Add project overview to Introduction

Add a key 'Project Overview' with the value 'This project is to develop a user-friendly task management application.' inside the 'Introduction' dictionary of srs_document.

Software Engineering

srs_document = {
    'Introduction': {},
    'Overall Description': {},
    'Specific Requirements': {},
    'Appendices': {}
}
# Add the project overview inside the 'Introduction' dictionary
# Your code here

Hint

Access the 'Introduction' dictionary and add the 'Project Overview' key with the exact text.

3

List functional requirements

Inside the 'Specific Requirements' dictionary of srs_document, create a dictionary called functional_requirements with these exact entries: 'FR1': 'Users can create tasks.', 'FR2': 'Users can edit tasks.', 'FR3': 'Users can delete tasks.'. Then assign this dictionary to the key 'Functional Requirements'.

Software Engineering

srs_document = {
    'Introduction': {
        'Project Overview': 'This project is to develop a user-friendly task management application.'
    },
    'Overall Description': {},
    'Specific Requirements': {},
    'Appendices': {}
}
# Create functional_requirements dictionary and add it to 'Specific Requirements'
# Your code here

Hint

Create a dictionary with the exact keys and values, then assign it to the 'Functional Requirements' key inside 'Specific Requirements'.

4

Add glossary to Appendices

Inside the 'Appendices' dictionary of srs_document, add a key 'Glossary' with a dictionary value containing these exact entries: 'Task': 'An item to be completed.', 'User': 'Person using the application.'.

Software Engineering

srs_document = {
    'Introduction': {
        'Project Overview': 'This project is to develop a user-friendly task management application.'
    },
    'Overall Description': {},
    'Specific Requirements': {
        'Functional Requirements': {
            'FR1': 'Users can create tasks.',
            'FR2': 'Users can edit tasks.',
            'FR3': 'Users can delete tasks.'
        }
    },
    'Appendices': {}
}
# Add the glossary dictionary inside 'Appendices'
# Your code here

Hint

Add a dictionary with the exact glossary terms inside the 'Appendices' dictionary.

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