Experiment 2
Question: Creating a Software Requirements Specification (SRS) Document:
Objective: Develop a comprehensive SRS document for a hypothetical software project.
Procedure: Conduct requirement analysis, distinguish between functional and non-
functional requirements and document them according to IEEE standards.
Expected Outcome: A well-documented SRS that includes all the requirements and
specifications for a software project.
Result:
Software Requirements Specification (SRS)
For: online Leave Management System.
Version: 1.0
Date: 14 August 2025
Prepared by: Piyush Khanduri,Pawan Kumar,Pratish Kumar,Praveen Negi.
1. Introduction
1.1 Purpose:
The purpose of this document is to outline the requirements for the development of an Online
Leave Management System designed for college use. This system aims to streamline the
process of applying for, approving, and tracking leave requests by students, faculty, and
administrators. It will reduce manual paperwork, improve efficiency, and provide centralized
access to leave data. The system will be web-based, accessible via browsers, and built using
standard technologies such as PHP, MySQL, and HTML/CSS. Key users include students
(who can apply for leave), faculty (who approve/reject leave), and administrators (who oversee
the system). Terms like LMS (Leave Management System), UI (User Interface), and DBMS
(Database Management System) are used throughout this document. The document follows the
IEEE SRS standard and includes all necessary functional and non-functional requirements to
guide the development team through the system’s implementation.
1.2 Scope:
The Online Leave Management System will allow students to apply for [Link] system will
serve:
Admin – To monitor the overall leave records, To review and approve/reject leave
requests.
Employee – To request for leave.
The system will reduce paperwork, speed up the leave approval process, and maintain digital
records for easy access and reporting. It will be a web-based system accessible on both
desktop and mobile browsers.
1.3 Definitions, Acronyms, and Abbreviations:
LMS – Leave Management System
UI – User Interface
DBMS – Database Management System
SRS – Software Requirements Specification
SQL – Structured Query Language
1.4 References:
IEEE Std 830-1998: IEEE Recommended Practice for Software Requirements Specifications
MySQL Server Official Documentation
.NET Manual ([Link])
UML 2.5 Specifications
1.5 Overview
This document contains a complete description of the Online Leave Management System,
including functional and non-functional requirements, system models, and design constraints.
It will serve as a reference throughout the software development life cycle to ensure all user
and system requirements are clearly understood and implemented correctly.
2. Overall Description
2.1 Product Perspective
The CMS will be an independent application accessible via modern web browsers. It
will connect to a centralized database server to store and manage all data.
High-Level Architecture Diagram (Text Representation):
2.2 Product Functions
Major functions:
Employee registration & records
Leave management
Leave Tracking
New User approval processing
2.3 User Classes and Characteristics
Administrator: High access privileges, manages users and system settings
Employee: Limited privileges,Apply for leaves and registration
2.4 Operating Environment
Platform: Web-based (.NET,CShtml,MVC, MySQL Server)
Server: Apache
Database: MySQL Server
Browsers: Chrome, Firefox, Edge
2.5 Design and Implementation Constraints
Must comply with data protection regulations
SSL/TLS encryption for all data transfers
2.6 Assumptions and Dependencies
Unique login credentials for all users
Firm IT infrastructure supports hosting requirements
3. Specific Requirements
3.1 Functional Requirements
FR1: Employee Authentication & Authorization
Employee must log in with a unique username and password
Role-based access control
FR2: Employee Management
Assign leaves(Casual,medical, maternity )
Assign unique Employee IDs
FR3: New Employee Management
User credentials such as name, phone number, gamil.
Request for Approval from user.
FR4: Leave Management
Leave application can be done by employees (from and to date).
Reason for leave should be well defined.
FR5: Admin Management
Admin have high privileges.
Approve or deny new employee request
Approve or deny leave request.
3.2 Non-Functional Requirements
NFR1: Performance
Average response time ≤ 2 seconds for key operations
NFR2: Security
SSL encryption for all communications
Password hashing
NFR3: Usability
Simple, responsive UI
NFR4: Reliability
System uptime ≥ 99%
NFR5: Maintainability
Modular architecture for easy updates
4. System Models
4.1 Use Case Diagram (Text Representation)
Actors:
- Admin
- Employee
- New User
Use Cases:
Admin: Manage new employee request, Manage Leaves.
Employee: Request for leaves.
New User: Request for approval.
4.2 Data Flow Diagram (DFD)
Level 0:
Level 1 (Example – Leave Management):
Input: Employee request for leave such as Casual, medical or maternity leave ,
also the date should be defined.
Process: Request will be stored in the data base.
Output: Request will be heard by the Admin and based in the reason the request
will be either approved or denied.
4.3 ER Diagram (Text Representation)
Entities & Relationships:
Employee (Employee_ID, Name, DOB, Gamil, Phone no.)
Admin (Admin_ID, Name, Gamil, Phone no.)
New User ( Name, Gmail,Phone [Link])
Leave (Employee_ID, Reason,To_date,From_date,Status)
Relationships:
Admin ↔ Employee (One-to-Many)
Admin↔ New User (One-to-Many)
5. Data Dictionary
6. Appendices
Gantt Chart – Development schedule
Hardware Requirements –
Production Server
CPU: Quad-core 2.5 GHz or higher
Memory: 8 GB RAM minimum (16 GB recommended)
Storage:
o 250 GB SSD for OS and application files
o 500 GB SSD or RAID-1 array for database and backups
Network:
o 1 Gbps NIC for internal LAN traffic
o 100 Mbps Internet uplink
Power:
o UPS with at least 30 minutes runtime
o Redundant power supply (if available)
Development & Testing Server
CPU: Dual-core 2.0 GHz
Memory: 4 GB RAM
Storage: 100 GB SSD
Network: 100 Mbps NIC
Backup: Local snapshots or daily database dumps
Client Workstations
CPU: Dual-core 1.8 GHz or higher
Memory: 4 GB RAM
Storage: 50 GB free disk space
Browser support: Latest Chrome, Firefox, or Edge
Network: 10 Mbps or higher
Mobile Access
Any smartphone or tablet with:
o iOS 12+ or Android 8+
o Built-in browser (Chrome, Safari)
o Stable Wi-Fi or 4G/LTE connection
Test Cases
Functional Test Cases
- TC-FR1-01 (FR1) – Valid Employee Login
Steps:
1. Go to the login page
2. Enter a real username/password
3. Click “Login”
Expected: You land on your dashboard and see your name at the top.
- TC-FR1-02 (FR1) – Invalid Employee Login
Steps:
1. Go to the login page
2. Enter a wrong password
3. Click “Login”
Expected: An “Invalid credentials” error pops up.
- TC-FR4-01 (FR4)– Apply for Leave
Steps:
1. Log in as an employee
2. Click “Apply Leave”
3. Choose leave type (e.g., Casual), set from/to dates, add a reason
4. Hit “Submit”
Expected: A confirmation message saying your request was sent.
- TC-FR5-01 (FR5) – Admin Approves Leave
Steps:
1. Log in as admin
2. Open “Pending Requests”
3. Click “Approve” next to an employee’s leave
Expected: Request status flips to “Approved” and an email notification is sent.
- TC-FR3-01 (FR3) – New User Registration
Steps:
1. Open the Sign-Up page
2. Fill in name, email, phone, password
3. Click “Submit”
Expected: You see “Registration pending approval.”
Non-Functional Test Cases
- TC-NFR1-01 (NFR1)– Dashboard Load Time
Scenario: Simulate ~50 users hitting the dashboard concurrently.
Expected: Average load time stays under 2 seconds.
- TC-NFR2-01 (NFR2) – HTTPS Enforcement
Steps: Try to open the app over `[Link]
Expected: You’re auto-redirected to `[Link] with no certificate warnings.
- TC-NFR3-01 (NFR3) – Mobile UI Responsiveness
Steps: View the leave form on a phone, rotate the device, then submit.
Expected: Layout adapts (no horizontal scroll) and submission works.
- TC-NFR4-01 (NFR4) – System Uptime
Scenario: Monitor availability over 30 days.
Expected: System stays up at least 99% of the time.
✅Expected Outcome:
This document meets IEEE SRS standards and clearly defines all requirements for the
College Management System. It distinguishes functional vs non-functional
requirements, includes diagrams, and provides sufficient detail for implementa
