SRS template for your final year project (free Word download)

A complete software requirements specification template for FYP groups: numbered functional requirements, use case tables, non-functional requirements you can actually test, and a traceability matrix. Download it, fill the placeholders, delete the grey notes.

Check your department first. If your FYP office gives you its own SRS format, that one wins. This template follows the IEEE 830 structure that many department formats are based on, so its sections will map across with little effort.

Download SRS template (Word)   Preview as PDF

9 pages, A4, Times New Roman 12 pt. A grey note under each heading says what to write there.

What is inside the template

Section What you write Ready in the template
Cover Project title, group members, registration numbers, supervisor, department, session Cover page and revision history table
1. Introduction Purpose, scope, definitions, references, document overview Definitions table and reference list
2. Overall description Product perspective, main functions, user classes, operating environment, constraints, assumptions User classes table with an example row
3. External interfaces Screens, hardware, third party APIs, communication protocols Software interfaces table
4. Functional requirements Numbered statements that start with “The system shall”, grouped by module Requirement tables with three worked examples
5. Use cases Use case diagram and one description per use case Use case description table, filled as an example
6. Non-functional requirements Performance, security, usability, availability, maintainability, portability Table with a “how it will be checked” column
7. Data requirements Main entities and their key attributes Entity table
8. Traceability matrix Which use case and test case covers each requirement Matrix with sample rows
Appendices Work plan and supervisor approval Schedule and signature tables

Fill it in this order, not top to bottom

Writing the SRS in page order means rewriting the introduction three times. This order saves most of that work:

  1. User classes (2.3). Every requirement belongs to someone, so list who uses the system first.
  2. Functional requirements (4). Go module by module and number each one as you write it: FR-01, FR-02.
  3. Use cases (5). Group related requirements into use cases and fill one description table for each.
  4. Non-functional requirements (6). Give each one a number or a condition someone can check.
  5. Interfaces and environment (2.4 and 3). By now you know which APIs, devices and platforms you need.
  6. Introduction and scope (1). Write these last, when you know exactly what the system does.
  7. Traceability matrix (8). Fill the test case column once your test document exists.

Requirements that pass review

Vague requirements are the most common reason an SRS comes back from a supervisor. The fix is the same every time: one behaviour per line, a number wherever there is a quantity, and nothing about which tool you will use to build it.

Weak Better Why it is better
The system should be user friendly. NFR-03: A first time user shall complete a booking in under 2 minutes without help. You can time it with real users and write pass or fail.
The system shall manage students. FR-07: The system shall allow the admin to add, edit and deactivate a student record. One clear behaviour, one ID, one test.
The system will be secure. NFR-02: Passwords shall be stored as salted hashes, never in plain text. Anyone can check it by opening the users table.
The app shall use Firebase to send notifications. FR-12: The system shall notify a patient 24 hours before an appointment. A requirement says what happens. The tool belongs in your design document.

The use case description table

Every use case in your diagram needs one of these. The template has it ready to copy, with this example filled in.

Field Example
Use case ID UC-01
Name Book appointment
Actor Patient
Related requirements FR-01, FR-02, FR-03
Preconditions Patient is logged in
Main flow 1. Patient selects a doctor. 2. System shows free slots. 3. Patient picks a slot and confirms. 4. System saves the booking and sends a confirmation.
Alternate flow 2a. No free slots: the system offers the next available date.
Postconditions Booking is stored and the slot is no longer available.

Before you submit

  • Every requirement has an ID, and no ID appears twice.
  • Each functional requirement starts with “The system shall” and describes one behaviour.
  • Every non-functional requirement has a number or a condition that can be checked.
  • Every use case in the diagram has a description table that lists its related requirements.
  • The scope matches your approved proposal. If it changed, the revision history says so.
  • The table of contents is updated: right-click it in Word and choose Update Field.
  • All grey guidance notes, and the template line on the cover, are deleted.

SRS template questions

Is this template based on IEEE 830?

Yes. It follows the IEEE 830 layout of introduction, overall description and specific requirements, with a use case section and a traceability matrix added because FYP committees usually ask for both. IEEE 830 was later replaced by ISO/IEC/IEEE 29148, which keeps the same core sections.

How long should an FYP SRS be?

There is no standard length, so ask your FYP coordinator what they expect. Coverage matters more than page count: every feature in your approved proposal should appear as at least one numbered requirement, and every use case in the diagram needs its description table.

What is the difference between the proposal and the SRS?

The proposal argues that the project is worth doing and can be finished in time. The SRS states exactly what the system will do, precisely enough that someone could test it. Our FYP proposal format guide covers the first one.

Can I use this if my department has its own template?

Use your department’s template for the layout and this one as a writing guide. The guidance notes and the worked examples apply to any SRS format.

Which tool should I use for the use case diagram?

draw.io (free, runs in the browser), StarUML, Lucidchart and Visual Paradigm all work. Export the diagram as an image and paste it into section 5.1.

Does the template work in Google Docs?

Yes. Upload the .docx to Google Drive and open it with Google Docs. The headings and tables carry over; rebuild the contents page with Insert, then Table of contents.