--- # System prepended metadata title: How to Write a Professional Software Requirements Specification (SRS) tags: [Software Engineering, SRS] --- # How to Write a Professional Software Requirements Specification (SRS) ![SRS](https://hackmd.io/_uploads/S135I-jiZl.png) Writing a **professional Software Requirements Specification (SRS)** is not only about the content—it is also about **structure, formatting, clarity, and professionalism**. This guide explains the process **step-by-step**, from document setup to final review. The approach follows common industry standards such as: - IEEE 830 Software Requirements Specification Standard - ISO/IEC/IEEE 29148 Requirements Engineering Standard --- # 1️⃣ Choose the Right Tool and File Setup Most professional SRS documents are written using: - Microsoft Word - Google Docs - LaTeX (very professional for academic reports) For most students and development teams, **Microsoft Word or Google Docs is sufficient**. ## Recommended File Settings **Font Sizes** - Title → 18–20 pt - Headings → 14–16 pt - Text → 11–12 pt **Font Types** - Times New Roman (formal and academic) - Calibri (modern professional) **Document Layout** - Line spacing → 1.15 or 1.5 - Alignment → Justified - Margins → 2.5 cm on all sides --- # 2️⃣ Professional Color Usage Professional SRS documents **avoid using many colors**. Use **two colors at most**. | Element | Recommended Color | |-------|----------------| | Main text | Black | | Headings | Dark blue or black | ### Example Style - Title → Dark Blue - Headings → Bold Black - Text → Black ### Avoid - Bright colors - Colored paragraphs - Background highlights Professional documents should remain **clean and minimal**. --- # 3️⃣ Symbols and Icons (Are They Professional?) Symbols can be used **in moderation**. ## Acceptable - Tables - Numbered lists - Bullet points - Diagrams - UML diagrams ## Avoid - Emojis - Decorative icons - Too many symbols ### Professional Example ``` System Features: • User registration • Login authentication • Course enrollment ``` ### Not Professional ``` ✨ User registration 🔥 Login authentication 🚀 Course enrollment ``` --- # 4️⃣ Standard Structure of an SRS Most SRS documents follow the structure recommended by the **IEEE 830 standard**. --- # 1. Title Page The title page should include: - Project name - Document title - Author name - Version - Date Example: ``` Vehicle Rental Application Software Requirements Specification (SRS) Author: Samer Alaa Abu Zaina Version: 1.0 Date: March 2026 ``` --- # 2. Table of Contents The table of contents should be **automatically generated**. Example structure: ``` 1. Introduction 2. Overall Description 3. System Features 4. External Interface Requirements 5. Non-Functional Requirements 6. System Models 7. Appendices ``` --- # 5️⃣ Section 1 — Introduction Write **short and clear paragraphs**. ## 1.1 Purpose Explain **why the document exists**. Example: > This document describes the functional and non-functional requirements of the Vehicle Rental Application. > It is intended for developers, project managers, and stakeholders. --- ## 1.2 Scope Explain **what the system does**. Example: > The Vehicle Rental Application allows users to search for vehicles, reserve them, and manage rental transactions through a mobile application. --- ## 1.3 Definitions Explain technical terms. | Term | Definition | |-----|------------| | API | Application Programming Interface | | User | Person who rents a vehicle | --- # 6️⃣ Section 2 — Overall Description ## 2.1 Product Perspective Explain how the system fits into the larger environment. Example: > The system is a mobile application developed using Flutter and connected to a backend server via REST APIs. --- ## 2.2 User Classes Describe the different system users. | User Type | Description | |----------|-------------| | Customer | Person who rents vehicles | | Admin | Manages vehicles and users | --- ## 2.3 Operating Environment Example: - Android devices - iOS devices - Internet connection - Cloud database --- # 7️⃣ Section 3 — System Features This is **one of the most important sections**. Each feature should include: - Description - Inputs - Process - Outputs Example: ## 3.1 Vehicle Search **Description** Users can search for vehicles based on location, type, and price. **Inputs** - Location - Vehicle type **Output** - List of available vehicles --- # 8️⃣ Section 4 — External Interface Requirements ## User Interface Explain the application screens. Example: - Login Screen - Vehicle Search Screen - Booking Screen You may also include **UI mockups**. --- ## API Interfaces Example: | API | Method | Description | |----|------|-------------| | /login | POST | User authentication | | /vehicles | GET | Retrieve vehicle list | --- # 9️⃣ Section 5 — Non-Functional Requirements These requirements define the **quality attributes** of the system. ## Performance The system should respond within **2 seconds**. ## Security User passwords must be **encrypted**. ## Usability The application must be **easy to use**. ## Reliability System uptime must be **99% or higher**. --- # 🔟 Section 6 — Diagrams (Highly Recommended) Include diagrams such as: - Use Case Diagram - Sequence Diagram - Database ER Diagram - System Architecture Diagram Common tools used for diagrams: - Draw.io - Lucidchart - Microsoft Visio --- # 11️⃣ Paragraph Writing Style Use: ✔ Short paragraphs ✔ Simple sentences ✔ Active voice ### Good Example > The system allows users to reserve vehicles online. ### Poor Example > The process of vehicle reservation will be performed by the system through a mechanism that allows the user to select a vehicle. --- # 12️⃣ Professional Numbering Always use **hierarchical numbering**. Example: ``` 1 Introduction 1.1 Purpose 1.2 Scope 2 Overall Description 2.1 Product Perspective 2.2 User Classes ``` --- # 13️⃣ Use Tables Instead of Long Text Professional SRS documents prefer **tables for requirements**. Example: | Requirement ID | Description | |---------------|-------------| | FR-1 | User can register | | FR-2 | User can login | | FR-3 | User can rent vehicle | --- # 14️⃣ Version Control Maintain a version history. | Version | Date | Author | Description | |-------|------|------|-------------| | 1.0 | Mar 2026 | Samer | Initial version | --- # 15️⃣ Final Checklist Before Submitting Before submitting your SRS, verify that: - No grammar mistakes exist - Formatting is consistent - Headings are clear - Requirements are numbered - Diagrams are included - Table of contents works properly --- # 16️⃣ Professional Tips ## Tip 1 — Requirements Must Be - Clear - Measurable - Testable ### Bad Example > The system should be fast. ### Good Example > The system should respond within **2 seconds**. --- ## Tip 2 — Each Requirement Should Be Atomic Each requirement should represent **one idea only**. ### Bad User can login and update profile. ### Good FR-1: User can login FR-2: User can update profile --- # Author **Samer Alaa Abu Zaina** Computer Engineering | Flutter Developer GitHub https://github.com/SamerZaina