1.
Introduction
1.1 Purpose
This document walks through what we're building with the Employee Leave Management System (ELMS) — a tool
that lets employees request time off, keeps track of how much leave everyone has left, and gives managers an easy
way to approve or turn down requests.
1.2 Scope
ELMS runs on both web and mobile, so employees can manage their own time off wherever they are. Managers get
a dashboard to keep an eye on requests coming from their team, and HR gets an admin panel for setting leave
policies and pulling reports.
1.3 Definitions, Acronyms, and Abbreviations
A few terms that come up throughout this document:
• ELMS – Employee Leave Management System
• PTO – Paid Time Off
• HR – Human Resources
• UI – User Interface
• API – Application Programming Interface
1.4 References
• IEEE Std 830-1998 – Recommended Practice for Software Requirements Specifications.
• Local labor laws and company policy manuals.
2. Overall Description
2.1 Product Perspective
ELMS is a distributed system that runs across web and mobile. It also needs to talk to a couple of existing corporate
systems — the Payroll System and the Employee Directory (Active Directory/LDAP) — so everything stays in
sync.
2.2 Product Functions
• Registering employees, managing their profiles, and assigning them to departments.
• Tracking leave balances — sick, casual, annual — with balances accruing automatically.
• Letting employees submit leave requests, with the option to attach documents for medical leave.
• A manager dashboard for approving or rejecting requests in real time.
• An HR dashboard for editing policies and generating organization-wide reports.
2.3 User Classes and Characteristics
• Employee: Everyday staff who just need to request time off and check their balance — nothing technical
required.
• Manager: Team leads who need to keep track of their people's schedules and sign off on requests.
• HR Admin: Somewhat tech-savvy users who manage leave policy across the whole company and pull
compliance reports.
• System Admin: The technical folks keeping the platform running and properly configured.
2.4 Operating Environment
• Frontend: Responsive web (HTML5/CSS3/React) and mobile apps for iOS and Android.
• Backend: [Link] / Python (Django) server environment.
• Database: PostgreSQL for relational employee and leave data.
2.5 Design and Implementation Constraints
• Needs to follow local privacy laws (like GDPR), since we're dealing with employees' personal information.
• Has to plug into the company's existing SSO (Single Sign-On) setup.
2.6 Assumptions and Dependencies
• We're assuming every employee has access to either the company intranet or the internet.
• We're also relying on the internal Payroll API staying up at least 99.9% of the time, since that's what keeps
leave deductions in sync.
3. Specific Requirements
3.1 Functional Requirements
FR1: User Authentication & Profile Management
• FR1.1 Login: Users log in with their corporate email through SSO.
• FR1.2 Profile Management: Users can see their department, their supervisor's name, and their contact
details.
FR2: Leave Application & Workflow
• FR2.1 Leave Request: Employees pick a leave type (sick, annual, etc.) and choose their dates.
• FR2.2 Conflict Check: If other team members already have leave booked for the same period, the system
flags it so there are no scheduling surprises.
• FR2.3 Approval Workflow: Once submitted, the request goes straight to the right manager, who gets
notified by email.
FR3: Leave Balance & Reporting
• FR3.1 Real-Time Balance: As soon as a request gets approved, employees see their updated balance right
away.
• FR3.2 Monthly Reports: HR gets an automatic monthly summary of leave activity.
3.2 Non-Functional Requirements (NFRs)
• NFR1 Performance: Submitting a request or approving one should take no more than 2 seconds.
• NFR2 Availability: The system needs to stay up 99.9% of the time, so people can report an emergency
sick day whenever they need to.
• NFR3 Security: Personal data and medical attachments are encrypted at rest using AES-256.
3.3 Interface Requirements
• 3.3.1 User Interfaces (UI): Frontends need to be responsive and accessible, meeting WCAG 2.1 AA
standards.
• 3.3.2 Software Interfaces (SI): An outbound REST connection to Payroll updates paid days automatically
based on approved leave.
•
3.4 Data Requirements & Schema Constraints
This includes a Leave Balance entity, since the DFDs later in this document reference a Leave Balance Database as
its own data store — that needed a matching schema definition here.
Entity Attribute Name Data Type Constraints / Description
Validation
Employee employee_id UUIDv4 Primary Key, Unique ID for the employee.
Unique
name VARCHAR(100) Not Null Employee's full name.
dept_id UUIDv4 Foreign Key Links to the Department table.
Leave Request request_id UUIDv4 Primary Key, Unique ID for the request.
Unique
employee_id UUIDv4 Foreign Key Links to the requesting employee.
status VARCHAR(20) Default: 'Pending' Current state — Pending, Approved, or
Rejected.
Leave Balance balance_id UUIDv4 Primary Key, Unique ID for the balance record.
Unique
employee_id UUIDv4 Foreign Key Links to the employee this balance
belongs to.
leave_type VARCHAR(20) Not Null Sick, Casual, or Annual.
remaining_days DECIMAL(5,2) Not Null, >= 0 Days left for this leave type. This is
what Process 2.1.1 checks and Process
2.2 updates.
last_updated TIMESTAMP Not Null When the balance was last recalculated.
Level 0 DFD: Employee Leave Management System
The Level 0 DFD (Context Diagram) gives a bird's-eye view of how data moves between ELMS and the people who
use it.
Diagram Legend
• [ Box ]: External entities — people or departments.
• ( Circle ): The central process — the system itself.
• ( ) arrow: Data flow, showing which way information is moving.
Visual Representation
Fig: DFD L0
Detailed Component Breakdown
Symbol Type Label Description
Central Circle 1.0 Employee Leave The core piece of software that handles all the leave-
Management System related data and business logic.
Rectangle Employee Staff members who submit leave requests and get updates
on where things stand.
Rectangle Manager Department heads who receive requests and make the call
to approve or reject them.
Rectangle HR Admin Admin users who get the high-level org reports and leave
trends.
Data Flow Mapping (Lining & Symbols)
Here's how information actually travels through the system:
1. Employee Interactions:
• [Employee] → Leave Request → (System): The employee sends over their dates and leave type (sick,
annual, etc.).
• (System) → Status Notification → [Employee]: The system lets the employee know once a decision has
been made.
2. Manager Interactions:
• (System) → Approval Request → [Manager]: The system routes the incoming request to the right
supervisor.
• [Manager] → Approval/Rejection Decision → (System): The manager enters their decision into the
system.
3. HR Admin Interactions:
• (System) → Management Reports → [HR Admin]: The system puts together and sends summaries of
leave balances and department trends.
Level 1 DFD: Employee Leave Management System
The Level 1 DFD breaks the central system down into its main working parts, showing how leave data gets
processed, stored, and eventually turned into reports.
2.1 Process: Processing of Leave Request
This is where a request first comes in and gets routed.
• Inbound Flow: The employee sends in a raw leave request — dates, type, and reason.
• Boundary Output: The system forwards an approval request straight to the manager.
• Internal System Flow: Once processed, the request data moves downstream to update the relevant records.
2.2 Process: Update Leave Balance File
This keeps track of how much leave each person has left — kind of like an inventory count.
• What happens: It takes in the approved leave data from the earlier step.
• Output Flow: It formats that information and writes it into the Leave Balance Database.
2.3 Process: Update Employee History
This process keeps a permanent record of everyone's leave activity, similar to a sales log.
• What happens: It receives the final status — approved or rejected — from the workflow.
• Output Flow: It cleans up the data and saves a permanent entry in the Employee History Database.
2.4 Process: Generate Management Report
This is the analytical piece, pulling data from different places to give leadership something useful.
• Data Retrieval: It reads from two sources at once:
• Current balance info from the Leave Balance Database.
• Historical usage data from the Employee History Database.
• Boundary Output: It combines both streams into one Management Report and sends it over to HR.
Like 2.2 and 2.3, this process is a straightforward linear pipeline — ingest, aggregate, calculate, format — with no
branching or conditional logic, so it doesn't need its own Level 2 diagram.
Fig: DFD L1
Level 2 DFD: Decomposition of Process 2.1 (Processing of Leave
Request)
Processes 2.2 (Update Leave Balance File), 2.3 (Update Employee History), and 2.4 (Generate Management Report)
are all simple, single-path updates with no decision logic, so they don't need a Level 2 breakdown of their own.
Process 2.1 is the one with real internal branching logic, so that's the one decomposed further below:
Process 2.1.1: Validate Leave Eligibility
• Action: When someone submits a request, this step checks the Leave Balance Database to make sure
they've actually got enough days left.
• Flow: If they don't, it's an automatic rejection. If they do, the validated data moves on to the next step.
Process 2.1.2: Route for Approval
• Action: This step figures out who the right manager is based on the employee's department, and routes the
request to their dashboard.
• Flow: Then it waits for the manager's approval or rejection decision.
Process 2.1.3: Finalize Request Status
• Action: Once the decision comes back, this step updates the status and kicks off the notification.
• Flow: It sends a status notification to the employee and passes the finalized data on to the Update Balance
and Update History processes (2.2 and 2.3 in Level 1).
1. Decision Table
This models the logic behind Process 2.1 (Processing of Leave Request) — how the system decides what to do
based on whether there's enough balance, and what the manager says.
Conditions Rule 1 Rule 2 Rule 3 Rule 4
Is Leave Balance Sufficient? Y Y N N
Does Manager Approve? Y N Y N
Actions
Approve Leave & Deduct Balance X
Reject Request X X X
Notify Employee of Status X X X X
2. Decision Tree
Here's that same logic laid out as a visual path:
• Leave Request Submitted
• Is Balance Sufficient?
• NO → Reject Request (Reason: Insufficient Balance) → Notify Employee
• YES → Manager Review
• Approved → Approve Leave, Update Balance, Notify Employee
• Rejected → Reject Request, Notify Employee
3. Structured English
And here's that same logic written out step by step, in plain pseudocode:
Process: Process_Leave_Request
FOR EACH Incoming Leave Request:
FIND Employee_Record in Leave Balance Database
IF Requested_Days <= Remaining_Balance THEN
SEND Approval_Request to Manager
WAIT for Manager_Decision
IF Manager_Decision = "Approved" THEN
UPDATE Leave Balance Database (Subtract Requested_Days)
SET Request_Status to "Approved"
UPDATE Employee History Database
ELSE
SET Request_Status to "Rejected"
ENDIF
ELSE
SET Request_Status to "Rejected" (Reason: Insufficient Balance)
ENDIF
GENERATE Status_Notification to Employee
ENDFOR
Employee Leave Management System — Feasibility Analysis
Technical Feasibility
• Integration Capability: ELMS is built to plug into the company's existing SSO and Active
Directory/LDAP setup, so it fits right into the current IT environment.
• Platform Support: Using [Link] and PostgreSQL lets us support a distributed, multi-platform system
(web and mobile) that can handle real-time balance updates.
• Security: AES-256 encryption covers anything sensitive — medical attachments and personal employee
data especially.
Operational Feasibility
• Workflow Automation: The system follows the same hierarchy companies already use (Employee →
Manager → HR), so it should feel intuitive from day one.
• Conflict Resolution: Real-time checks for overlapping leave help avoid situations where too many people
are out at the same time.
• Self-Service: Giving employees direct access to their PTO balance cuts down on the back-and-forth with
HR.
Economic Feasibility
• Resource Optimization: Automating accruals and monthly reports means a lot less manual bookkeeping
for HR.
• Error Reduction: Automated calculations stop leave balances from going negative, protecting the
company from paying out for time that wasn't actually earned.