How to Write an SRS Document
for University Projects

What is an SRS Document?

A Software Requirements Specification (SRS) is a comprehensive document that describes what a software system will do and how it will be expected to perform. It acts as the definitive blueprint for the development process, outlining functional requirements (features the system must have), non-functional requirements (security, performance constraints), user interfaces, and system constraints.

The Standard IEEE SRS Structure

If your module handbook does not provide an explicit template, you should default to the standard IEEE format. A professional academic SRS contains three primary sections:

1. Introduction

This section sets the context for the entire project.

• 1.1 Purpose: Define the purpose of the SRS and specify the intended audience (e.g., developers, project supervisors, client).
• 1.2 Scope: Explicitly state what the software *will* do and what it *will not* do. Establish clear boundaries.
• 1.3 Definitions and Acronyms: Provide a glossary of all technical terms used in the document (e.g., API, CRUD, JWT).
• 1.4 References: List all documents, academic papers, and websites referenced during the requirements gathering phase.

2. Overall Description

This section describes the general factors that affect the product and its requirements.

• 2.1 Product Perspective: Is this a standalone desktop app, a web portal, or a mobile app connecting to a REST API?
• 2.2 User Characteristics: Describe the target users. Are they technical admins or standard non-technical consumers? Define your User Personas here.
• 2.3 Operating Environment: Specify the hardware and software platforms (e.g., AWS Linux EC2 instance, iOS 16+, Chrome Browser).
• 2.4 Assumptions and Dependencies: List any factors that must be true for the project to succeed (e.g., "The university's third-party authentication API remains active").

3. Specific Requirements

This is the core of the document where you detail every single technical requirement. This section usually takes up 70% of your total page count.

Functional Requirements

List exactly what the system should do, usually broken down by feature or User Story.

• Use the "Shall" format: "The system shall allow..."
• Assign a unique ID to every requirement for traceability (e.g., FR-01, FR-02).
• Map these directly to your Use Case Diagrams.

Non-Functional Requirements (NFRs)

Describe how the system operates, rather than what it does. Common categories include:

• Performance: e.g., "The API must return a response within 200ms."
• Security: e.g., "All passwords must be hashed using bcrypt."
• Reliability: e.g., "The system should have a 99% uptime."

External Interface Requirements

Describe the APIs, physical hardware interfaces, and User Interfaces (UI mockups/wireframes usually go here).