Association of Intelligent Minds

Software Requirements Specification

Project: Smart Leave Tracking System

Version: 1.0 Approved

Prepared by: Association of Intelligent Minds

Date: August 2025

1
Table of Contents
1. Introduction
1.1 Purpose
1.2 Project Scope
1.3 References

2. Overall Description
2.1 Product Perspective
2.2 Product Features
2.3 User Classes and Characteristics
2.4 Operating Environment
2.5 Design and Implementation Constraints
2.6 User Documentation
2.7 Assumptions and Dependencies

3. System Features
3.1 Role-based Login
3.2 Student Leave Application
3.3 Faculty Leave Approval & Tracking
3.4 Exception Handling
3.5 Dashboards by Role

4. External Interface Requirements

4.1 User Interfaces
4.2 Hardware Interfaces
4.3 Software Interfaces
4.4 Communications Interfaces

5. Other Nonfunctional Requirements

5.1 Performance Requirements
5.2 Safety Requirements
5.3 Security Requirements
5.4 Software Quality Attributes

6. Other Requirements
6.1 Database Requirements
6.2 Legal and Regulatory Requirements
6.3 Accessibility and Internationalization

7. Appendices
Appendix A: Glossary
Appendix B: Analysis Models
Appendix C: Issues List

2
8. Minutes of Meeting (MoM)
8.1 Meeting Summary Table
8.2 Enhancement & Clarification Log

9. Version Control
9.1 Version History Table

10. Testing Details

10.1 Unit Testing
10.2 Integration Testing
10.3 User Acceptance Testing (UAT)
10.4 Bug Tracking Summary

11. Alumni Inputs

11.1 Suggestions from Alumni
11.2 Implemented Enhancements

3
1. Introduction
1.1 Purpose

The purpose of the Smart leave tracking system is to simplify and automate leave applications for students
and provide an efficient approval and tracking mechanism for faculty. It ensures reduces paperwork and maintains a
digital record of leave requests.

1.2 Project Scope

The Smart Leave Tracking System is designed to replace traditional paper-based leave registers with a
web-based solution that enhances efficiency and transparency. Student leave application submission with
date and reason.

In Scope:

• Online leave application submission by students (date and reason ).

• Faculty approval/rejection of leave requests.
• Leave history tracking (class-wise, department-wise).
• Dashboards for students (status tracking) and faculty (pending requests and reports).
• Secure role-based login for students and faculty.
• Records can be exported for attendance/academic reports.

Out of Scope:

• Faculty leave application and approval workflow (system is focused only on student leave).
• Notifications (email/SMS alerts for approval/rejection are not part of this version).
• Multi-institution deployment (the system is designed for use in a single institution setup).

1.3 References
Below are the references used during the preparation and development of the Smart Leave Tracking System:

• Institution’s student leave policies and regulations.

• Existing manual leave application process used in colleges.

• Academic literature on student information management systems.

• Comparable leave tracking systems used in educational institutions.

2. Overall Description
2.1 Product Perspective
The Smart Leave Tracking System is a web-based application designed to digitize the student leave
application and approval process in educational institutions. It eliminates manual registers and paperwork by providing
an online portal where students can apply for leave and faculty can review, approve, or reject requests. The system
maintains a centralized database, making it easy to track leave records for academic monitoring.

4
2.2 Product Features

The system provides the following key features:

• Role-based login for students, faculty, and administrators.

• Online leave application by students with reason, duration.
• Faculty approval/rejection of student leave requests.
• Leave history tracking for individual students and departments.
• Dashboards for students (status updates) and faculty (pending approvals).
• Records can be exported for attendance/academic reports.

2.3 User Classes and Characteristics

The system supports multiple user types, each with a specific level of access:

User Class Characteristics

Student Apply for leave and track leave approval status , leave balance and leave
history.

Faculty / HOD Review, approve, or reject student leave applications and track student leave
records

2.4 Operating Environment

The platform is developed using the below key technical requirements:

• Frontend: HTML, CSS, JavaScript

• Backend: PHP.
• Database: MySQL.
• Hardware: Works on PCs, laptops, and mobile devices without internet access.
2.5 Design and Implementation Constraints

● Secure login and role-based access must be implemented.

● Data privacy must be ensured for student leave records.
● Limited to a single institution setup in the initial release.

2.6 User Documentation

The following user documentation will be provided along with the platform:
• Student Guide: Instructions for submitting leave applications and checking approval status.
• Faculty Guide: Instructions for reviewing and approving/rejecting leave requests.

5
 2.7 Assumptions and Dependencies

• Students and faculty will have valid login credentials provided by the institution.

• Faculty members will be responsible for timely approval/rejection of student requests.

• Leave policies will be defined by the institution and implemented accordingly.

3. System Features
3.1 Role-based Login

The system provides separate logins for students and faculty.

• Students can only apply for leave and track their own requests and leave balances.

• Faculty can view, approve, or reject leave requests, monitor student leave records and leave
balances.

3.2 Student Leave Application

• Students can apply for leave by entering details such as leave type, dates, and reason.

• Submitted requests are forwarded to the assigned faculty for approval.

• Students can track the real-time status (Pending / Approved / Rejected).

• Students can view their own leave balance.

3.3 Faculty Leave Approval & Tracking

• Faculty members receive leave requests from the students.

• They can review, approve, or reject requests directly through their dashboard.

• They can view the students leave balances.

• Leave records are automatically updated upon approval.

3.4 Exception Handling

• The system validates applications to prevent overlapping dates or invalid entries.

• Faculty give the reason for rejection.

6
3.5 Dashboards by Role

• Student Dashboard: Student Dashboard: Displays leave application form, submitted requests,
leave balance and approval history.

• Faculty Dashboard: Shows pending leave requests, student leave history and leave balances.

4. External Interface Requirements

4.1 User Interfaces

The system provides a web-based interface accessible from desktops, laptops, and mobile devices.

• Login Page: Role-based authentication (Student, Faculty).

• Student Interface: Leave application form, leave history, status updates and leave balance .
• Faculty Interface: Pending requests list, approve/reject options, student leave history and leave
balances.
• Design Goal: Simple, responsive, and user-friendly UI with minimal clicks for key actions.

Key UI Features:

• Login Page: Session-based login with reset option, styled in institute branding colors ( blue with
white contrast).
• Student Dashboard: Clean tabular layout to view own leave request, history, and leave balances,
with search and year filters for quick access.
• Faculty Dashboard: Tools for approve/reject leave requests, managing student leave history, search
and year filters for quick access. and exporting records through pdf.
• Top Navigation Bar: Fixed header with institute logo, brand title, and right-aligned menu links,
ensuring consistent access to all sections.
• Color Indicators (Status Tags):

• Green: Approved
• Red: Rejected
• Orange: Pending
o Timer & Actions: Prominent buttons with hover animations and countdown box styled for
visibility.
o Accessibility: Optimized for desktop and mobile with responsive breakpoints, hover states,
and keyboard-friendly focus indicators.
o Design Style: Consistent branding through a deep blue + cream palette, applied to headers,
buttons, tables, and navigation menus.

4.2 Hardware Interfaces

There are no direct hardware-level interfaces required for Smart Leave Tracking System.
However, the following are expected for a smooth experience:

● User Devices: PC, Laptop, or Tablet with a modern browser.

7
 ● Input Devices: Keyboard and mouse or touchscreen.

4.3 Software Interfaces

• Web Browser: Chrome, Firefox, Edge.

• Backend: PHP/MySQL (or equivalent relational database).

• Server: Apache/Nginx with support for PHP 7.4+ or higher.

4.4 Communications Interfaces

The platform uses internet-based communication protocols for server and client interaction:

• Protocol: HTTP/HTTPS for secure communication between client and server.

• Authentication: Encrypted password-based login system with role verification.

• Data Access: Controlled database queries via secure APIs.

5. Other Nonfunctional Requirements

5.1 Performance Requirements

• The system should support at least 100 concurrent users without performance degradation.
• Database queries must be optimized for fast access to student and leave data.

5.2 Safety Requirements

• Regular database backups must be maintained to prevent data loss.

• System should have a fail-safe mode in case of unexpected shutdowns, ensuring no data corruption.

• Access to system settings should be restricted to administrators only.

5.3 Security Requirements

• User authentication is role-based (Student, Faculty, Admin).

• All passwords are stored in Database.
• Sensitive data like student details must be transmitted only via HTTPS.
• Session timeouts and auto-logout must be implemented for inactive users.
• Faculty actions (approval/rejection) must be logged for accountability.

5.4 Software Quality Attribute

The following attributes define the quality standards expected from the platform:
8
 Attribute Description

Usability Simple, intuitive, and responsive interface for all user roles.

Reliability System should perform accurately and consistently under expected

load.

Scalability Should support growth in number of students/faculties without system

redesign.

Maintainability Modular code structure for easy updates and bug fixes.

6. Other Requirements
6.1 Database Requirements

• The system must maintain a centralized relational database (e.g., MySQL).

• Users Table – Stores student, faculty, and admin login details (with encrypted passwords).
• Leave Requests Table – Contains student leave applications with status
(Pending/Approved/Rejected).

• The database must support data integrity constraints (e.g., no overlapping leave for same student,
proper foreign keys).

• Regular backups should be scheduled (daily/weekly) to avoid data loss.

6.2 Legal and Regulatory Requirements

• The system must comply with institutional policies regarding student attendance and leave
management.

• Only authorized faculty and administrators can view or modify student leave data.

• The system must maintain audit trails for accountability.

6.3 Accessibility and Internationalization

• The interface must be accessible to users with basic digital literacy.

• The system should be responsive for both desktop and mobile devices.

• Language support: English as default, with flexibility to add local languages if required.
9
 • Font sizes and colors should follow readability standards for visually impaired users.

7. Appendices
Appendix A: Glossary

Term Definition

Leave Request A digital application submitted by a student to seek approval for absence.

Approval The action taken by faculty to accept a leave request.

Rejection The action taken by faculty to deny a leave request.

Role-Based Different permissions for Students and Faculty.

Access

Dashboard The homepage shown to users after login based on their role

Appendix B: Analysis Models

1. Entity Relationship Diagram (ERD):

Entities: Students, Faculty, Leave Requests, Leave Types (Casual, Medical, On-Duty, etc),
Leave Status (Pending, Approved, Rejected)

o Relationships:
▪ Student → Apply Leave, Track Leave Status, View History and Leave Balance.
▪ Faculty → Approve/Reject Leave, View Student Records, Generate Reports.

2. Data Flow Model :

o Student submits leave request → Stored in Database → Faculty reviews → Decision stored →
Status updated to Student.

Appendix C: Issues List

• Issue 1: Students may apply for overlapping leave periods.

Resolution: Add validation to check existing leave dates before submission.

• Issue 2: Delayed faculty response to leave requests.

10
 Resolution: Implement automated reminders/notifications for pending approvals.

• Issue 3: Data privacy concerns for student information.

Resolution: Ensure secure authentication, encrypted passwords, and role-based access control.

8. Minutes of Meeting (MoM)

8.1 Meeting Summary Table

Meeting Date Conducted By Attendees Key Topics Discussed Next Steps / Action Items

ID

Enhancement & Clarification Log

Entry ID Date Raised By Topic / Concern Clarified or Enhanced Updated Section/Feature

11
9. Version Control
9.1 Version History Table

Version Date Author / Team Changes / Enhancements Made Status

12
10. Testing Details
10.1 Unit Testing

Verify individual modules of the system work correctly.

Module Test Case Status

Student leave request form validation, leave history retrieval

Faculty approve/reject function, comment logging

10.2 Integration Testing

Ensure modules interact properly and data flows seamlessly.

Integration Scenarios:

Integrated Modules What Was Verified Status

Login ↔ Dashboard Routing Correct redirection, session validation, and role-

based access (Student/Faculty).

Student Leave Form ↔ Database Leave request submission stored correctly, with
validation for overlapping dates.

Faculty Approval ↔ Student View Approved/rejected leave status updated and visible
instantly on student dashboard.

10.3 User Acceptance Testing (UAT)

UAT involves testing the system in real-world conditions with actual users to validate the platform meets the
expectations.

UAT Sessions:

Conducted Test Objective Feedback Action Taken

With

13
 Students Apply for leave, check
status, view history and
leave balance.

Faculty Members Approve/reject leave, add

remarks, and track requests.

Alumni Review Reviewed design and testing

logic for improvements.

Admin & HOD Full system walkthrough

with reporting functions.

10.4 Bug Tracking Summary

A summary of key bugs found during development and testing, along with their resolution status.

Bug ID Module Affected Bug Description Severity Status

11. Alumni Inputs

11.1 Suggestions from Alumni

During feedback sessions with alumni who had previous experience with academic tech platforms, several
valuable suggestions were provided:

Alumni Suggestion / Concern

14
11.2 Implemented Enhancements
Based on feasibility and value to users, the following enhancements were accepted and implemented:

Enhancement Linked Feature Status

15