How to Write an SRS Document for Your Final Year Project

Why the SRS Matters More Than You Think

Most students treat the SRS as paperwork to get out of the way before "real" development starts. Supervisors read it differently — it's usually the first evidence of whether you actually understand the problem you're solving, before they've seen a single line of code.

The Core Sections

• Introduction — purpose, scope, and intended audience of the document
• Overall description — the product perspective, user classes, and assumptions
• Functional requirements — what the system must do, written as specific, testable statements
• Non-functional requirements — performance, security, usability constraints
• External interface requirements — UI, APIs, hardware if relevant

Common Mistakes

• Writing requirements as vague goals ("the system should be fast") instead of testable statements ("the system shall return search results within 2 seconds")
• Copying a generic SRS template without adapting section content to your actual project
• Describing the solution instead of the requirement — requirements say what, not how
• Skipping non-functional requirements entirely, which supervisors specifically look for

Requirements say what the system must do — not how you plan to build it.

A Simple Way to Write Testable Requirements

Use "the system shall [do X] when [condition Y]" as a template for every functional requirement. It forces you to be specific about triggers and outcomes, which is exactly what makes a requirement testable — and exactly what a supervisor is checking for.

Getting It Right the First Time

Every FYP package at ProjectPilotHub includes SRS and design documentation prepared to match your department's requirements — not a generic template, but one scoped to your actual project.