HRMS Software Requirements Specification (SRS)

This document defines the functional and non-functional requirements for a custom Human Resource Management System (HRMS) delivered as a web app and mobile app.

1. Document purpose

The purpose of this SRS is to provide a build-ready functional foundation for designing, developing, testing, and launching a custom HRMS platform.

2. Product overview

The HRMS platform will centralize employee data, HR operations, manager approvals, and employee self-service across web and mobile experiences.

Product goals

• Reduce manual HR operations
• Improve employee self-service
• Enable mobile-first daily actions such as attendance and leave
• Standardize approval workflows
• Support future expansion into payroll, recruitment, and performance management

3. Target users

3.1 Super Admin

• Manages company configuration
• Controls modules, permissions, policies, and integrations

3.2 HR Admin

• Manages employee records, leave rules, attendance policies, onboarding, payroll setup, and documents

3.3 Manager

• Approves leave and attendance requests
• Reviews team attendance and employee performance
• Monitors direct reports

3.4 Employee

• Uses self-service tools for profile updates, attendance, leave, documents, and payslips

3.5 Recruiter

• Manages job openings, candidates, interview stages, and offers

3.6 Finance/Payroll User

• Runs payroll, validates deductions, and exports payment files and payroll reports

4. Product scope

In scope for MVP

• Authentication and role-based access
• Employee profile management
• Department and designation management
• Attendance tracking
• Leave management
• Employee self-service
• Notifications
• Admin and manager dashboards
• Mobile attendance and leave workflows
• Basic reports and exports

In scope for Phase 2

• Recruitment and applicant tracking
• Onboarding workflows
• Payroll and payslips
• Performance management
• E-signature integrations
• Advanced analytics
• Asset management

Out of scope for MVP

• Full tax engine for multiple countries
• Advanced workforce planning
• Deep accounting integrations
• AI-assisted policy answering
• Custom workflow builder for admins

5. Assumptions and dependencies

• Organizations may operate across multiple branches
• Mobile apps will support both Android and iOS
• Internet access is required for most operations, with limited offline caching for selected mobile views
• Payroll compliance rules may vary by country and require later localization
• Third-party integrations such as biometric devices, SMS, email, and e-signature services may be added in later phases

6. System modules

1. Authentication and access control
2. Organization setup
3. Employee management
4. Attendance and time tracking
5. Leave management
6. Employee self-service
7. Notifications and announcements
8. Reports and dashboards
9. Recruitment
10. Onboarding
11. Payroll
12. Performance management
13. Documents and policy management
14. Settings and audit logs

7. Functional requirements

7.1 Authentication and access control

Features

• Email and password login
• Google and Microsoft SSO
• Multi-factor authentication
• Forgot password and password reset
• Session management
• Role-based access control
• Optional biometric unlock on mobile

Functional requirements

• The system shall allow users to log in using email and password.
• The system shall support SSO with Google and Microsoft accounts.
• The system shall allow admins to enforce MFA for selected roles.
• The system shall terminate expired sessions automatically.
• The system shall restrict screens, actions, and data based on role and permission.
• The mobile app shall support biometric unlock after first successful login.

7.2 Organization setup

Features

• Company profile setup
• Multi-branch setup
• Department management
• Designation management
• Holiday calendar setup
• Shift policy setup

Functional requirements

• The system shall allow admins to create and edit company profile information.
• The system shall allow admins to create multiple branches and assign employees to branches.
• The system shall allow admins to manage departments and designations.
• The system shall allow admins to define holiday calendars per branch or organization.
• The system shall allow admins to configure shifts, working hours, grace periods, and overtime rules.

7.3 Employee management

Features

• Employee directory
• Employee profile creation and editing
• Employee ID generation
• Reporting hierarchy
• Employment status tracking
• Emergency contacts
• Document upload

Functional requirements

• The system shall allow HR admins to create employee records manually.
• The system shall support employee import through spreadsheet upload in future versions.
• The system shall generate a unique employee ID for each employee.
• The system shall store personal, job, branch, department, salary band, and emergency contact information.
• The system shall support employee lifecycle statuses including active, probation, notice, resigned, and terminated.
• The system shall allow managers to view only employees they are permitted to access.
• The system shall maintain an audit trail for employee profile changes.

7.4 Attendance and time tracking

Features

• Clock in and clock out
• Shift assignment
• GPS attendance for mobile
• Attendance corrections
• Overtime tracking
• Timesheets for flexible work schedules
• Device/biometric integration readiness

Functional requirements

• The system shall allow employees to clock in and clock out from mobile and web where permitted.
• The system shall store attendance timestamps with timezone data.
• The system shall support location capture for mobile attendance where enabled.
• The system shall calculate late arrivals, early exits, and overtime based on shift rules.
• The system shall allow employees to submit attendance correction requests.
• The system shall route correction requests to the correct approver.
• The system shall allow managers and HR admins to review daily attendance summaries.

7.5 Leave management

Features

• Leave type setup
• Leave accrual rules
• Leave balances
• Leave application
• Multi-level approval workflow
• Holiday integration
• Carry-forward rules
• Half-day and optional leave support

Functional requirements

• The system shall allow admins to define leave types such as casual, sick, earned, unpaid, and maternity leave.
• The system shall calculate leave balances according to policy rules.
• The system shall allow employees to apply for full-day or half-day leave.
• The system shall validate leave requests against balance, holidays, and policy rules.
• The system shall route leave requests to one or more approvers.
• The system shall notify employees of leave approval, rejection, or pending status.
• The system shall show team leave calendars to managers.

7.6 Employee self-service

Features

• Profile viewing and editing
• Payslip access
• Leave application
• Attendance history
• Request submissions
• Policy and document access
• Announcements

Functional requirements

• The system shall allow employees to update selected personal profile fields.
• The system shall allow employees to view attendance records and leave balances.
• The system shall allow employees to submit HR service requests.
• The system shall allow employees to download authorized documents such as payslips and tax forms.
• The system shall display company announcements and policies in both web and mobile apps.

7.7 Notifications and announcements

Features

• In-app notifications
• Push notifications for mobile
• Email notifications
• Announcement publishing
• Reminder rules

Functional requirements

• The system shall notify users when approvals are pending.
• The system shall notify employees about leave decisions and attendance exceptions.
• The system shall allow HR admins to publish announcements by audience group.
• The system shall maintain read and unread notification states.

7.8 Reports and dashboards

Features

• HR admin dashboard
• Manager dashboard
• Employee personal dashboard
• Attendance reports
• Leave reports
• Headcount summary
• Export to spreadsheet and PDF in future iterations

Functional requirements

• The system shall display total headcount, active employees, and department-level metrics.
• The system shall display attendance summaries including absent, late, and present counts.
• The system shall display leave balance and leave usage reports.
• The system shall allow authorized users to filter reports by date range, branch, department, and manager.
• The system shall allow authorized users to export reports.

7.9 Recruitment module

Features

• Job opening creation
• Career page integration
• Candidate application tracking
• Interview scheduling
• Candidate status pipeline
• Offer management
• Candidate conversion to employee

Functional requirements

• The system shall allow recruiters to create and publish job openings.
• The system shall accept candidate applications through a branded application form.
• The system shall track candidate movement across recruitment stages.
• The system shall support interview scheduling with panel and feedback notes.
• The system shall allow selected candidate records to convert into employee records.

7.10 Onboarding module

Features

• Preboarding task lists
• Document collection
• Equipment assignment
• Policy acknowledgment
• Training checklist

Functional requirements

• The system shall create onboarding checklists for new hires.
• The system shall assign onboarding tasks to HR, managers, IT, and employees.
• The system shall track completion status for onboarding tasks.
• The system shall allow uploading and verification of onboarding documents.

7.11 Payroll module

Features

• Salary structures
• Earning and deduction components
• Payroll run preparation
• Reimbursement support
• Payslip generation
• Bank export file generation
• Payroll history

Functional requirements

• The system shall allow authorized users to define salary components.
• The system shall compute payroll entries based on attendance, leave, and manual adjustments.
• The system shall allow payroll users to review and finalize payroll runs.
• The system shall generate downloadable payslips.
• The system shall maintain payroll history and audit logs.

7.12 Performance management

Features

• Goals and KPIs
• Review cycle setup
• Self-review
• Manager review
• 360 feedback
• Review outcome history

Functional requirements

• The system shall allow HR admins to configure review cycles.
• The system shall allow employees to complete self-assessments.
• The system shall allow managers to rate direct reports.
• The system shall support optional peer feedback collection.
• The system shall store review outcomes and comments historically.

7.13 Documents and policy management

Features

• Employee document repository
• Offer letters and contracts
• Policy library
• Versioned documents
• Access control by role

Functional requirements

• The system shall store employee-related documents in organized categories.
• The system shall allow HR admins to upload and manage policy documents.
• The system shall apply document visibility rules based on role and ownership.
• The system shall track document upload, update, and access events.

7.14 Audit and settings

Features

• Audit logs
• Permission management
• Notification settings
• Attendance policy settings
• Leave policy settings
• Payroll settings

Functional requirements

• The system shall record sensitive administrative changes in an audit log.
• The system shall allow super admins to assign module and action permissions.
• The system shall allow authorized admins to update system policies and configurations.

8. Web application requirements

The web app is the main operational workspace for admins, HR teams, recruiters, managers, and payroll users.

Required web sections

• Login and authentication
• Admin dashboard
• Employee directory
• Employee profile detail
• Departments and designations
• Attendance monitor
• Leave management and approvals
• Reports and analytics
• Announcements and documents
• Recruitment board
• Onboarding workspace
• Payroll workspace
• Performance review center
• System settings
• Audit logs

Web-specific requirements

• The web app shall support advanced filtering, search, and export actions.
• The web app shall support bulk administrative actions where allowed.
• The web app shall display dashboards optimized for desktop usage.
• The web app shall support responsive design for tablet usage.

9. Mobile application requirements

The mobile app is focused on daily employee and manager actions.

Required mobile sections

• Login and biometric unlock
• Home dashboard
• Clock in and clock out
• My attendance
• Apply for leave
• My leave balance
• My profile
• Payslips and documents
• Notifications
• Announcements
• Team approvals for managers
• Onboarding tasks

Mobile-specific requirements

• The mobile app shall prioritize low-friction daily actions.
• The mobile app shall support push notifications.
• The mobile app shall support GPS-based attendance where enabled.
• The mobile app shall use a simplified navigation structure.
• The mobile app shall support offline view caching for selected static content such as profile and policies in future versions.

10. UI/UX screen flow

10.1 Web app screen map

mermaid
flowchart TD
    A[Login] --> B[Dashboard]
    B --> C[Employee Directory]
    B --> D[Attendance Monitor]
    B --> E[Leave Approvals]
    B --> F[Reports]
    B --> G[Announcements]
    B --> H[Settings]
    B --> I[Recruitment]
    B --> J[Onboarding]
    B --> K[Payroll]
    B --> L[Performance]

    C --> C1[Employee Profile]
    C1 --> C2[Documents]
    C1 --> C3[Attendance History]
    C1 --> C4[Leave History]
    C1 --> C5[Employment Details]

    D --> D1[Daily Attendance View]
    D --> D2[Shifts]
    D --> D3[Correction Requests]

    E --> E1[Pending Requests]
    E --> E2[Leave Calendar]

    I --> I1[Job Openings]
    I --> I2[Candidate Pipeline]
    I2 --> I3[Candidate Detail]

    J --> J1[Onboarding Tasks]
    K --> K1[Payroll Runs]
    K --> K2[Payslips]
    L --> L1[Review Cycles]
    L --> L2[Employee Reviews]

Web experience principles

• Navigation should be left-side persistent for desktop users.
• Dashboards should surface high-priority exceptions first.
• Employee profile pages should act as a central source of truth.
• Approvals should require minimal clicks and show clear status.

10.2 Mobile app screen flow

mermaid
flowchart TD
    M1[Login] --> M2[Biometric Unlock]
    M2 --> M3[Home]
    M3 --> M4[Clock In or Out]
    M3 --> M5[My Attendance]
    M3 --> M6[Apply Leave]
    M3 --> M7[My Leave Balance]
    M3 --> M8[My Profile]
    M3 --> M9[Payslips]
    M3 --> M10[Notifications]
    M3 --> M11[Announcements]
    M3 --> M12[Onboarding Tasks]
    M3 --> M13[Manager Approvals]

    M6 --> M6A[Select Leave Type]
    M6A --> M6B[Select Dates]
    M6B --> M6C[Submit Request]

    M13 --> M13A[Review Request]
    M13A --> M13B[Approve or Reject]

Mobile experience principles

• Common actions should be reachable within 3 taps.
• Attendance actions should be prominent on the home screen.
• Manager approvals should be optimized for quick decision-making.
• Notifications should deep-link users into the correct screen.

10.3 Priority screen list

Web MVP screens

1. Login
2. Dashboard
3. Employee directory
4. Employee profile
5. Attendance monitor
6. Attendance correction requests
7. Leave request list
8. Leave approvals
9. Department management
10. Holiday calendar
11. Announcements
12. Settings and permissions
13. Reports

Mobile MVP screens

1. Login
2. Biometric unlock
3. Home dashboard
4. Clock in/out
5. Attendance history
6. Apply leave
7. Leave balance
8. Notifications
9. Profile
10. Announcements

11. Database schema and ER diagram

11.1 Core entities

• Company
• Branch
• Department
• Designation
• Role
• User
• Employee
• EmployeeDocument
• Shift
• AttendanceRecord
• AttendanceCorrectionRequest
• LeaveType
• LeaveBalance
• LeaveRequest
• Holiday
• Announcement
• Notification
• JobOpening
• Candidate
• Interview
• OnboardingTask
• PayrollRun
• Payslip
• SalaryComponent
• PerformanceCycle
• PerformanceReview
• AuditLog

11.2 Logical relationship model

mermaid
erDiagram
    COMPANY ||--o{ BRANCH : has
    COMPANY ||--o{ DEPARTMENT : has
    COMPANY ||--o{ HOLIDAY : defines
    COMPANY ||--o{ ANNOUNCEMENT : publishes
    COMPANY ||--o{ JOB_OPENING : creates
    COMPANY ||--o{ PAYROLL_RUN : processes

    BRANCH ||--o{ EMPLOYEE : assigns
    DEPARTMENT ||--o{ EMPLOYEE : groups
    DESIGNATION ||--o{ EMPLOYEE : classifies
    ROLE ||--o{ USER : grants
    USER ||--|| EMPLOYEE : maps_to
    EMPLOYEE ||--o{ EMPLOYEE_DOCUMENT : owns
    EMPLOYEE ||--o{ ATTENDANCE_RECORD : logs
    EMPLOYEE ||--o{ ATTENDANCE_CORRECTION_REQUEST : submits
    EMPLOYEE ||--o{ LEAVE_BALANCE : holds
    EMPLOYEE ||--o{ LEAVE_REQUEST : creates
    EMPLOYEE ||--o{ NOTIFICATION : receives
    EMPLOYEE ||--o{ ONBOARDING_TASK : assigned
    EMPLOYEE ||--o{ PAYSLIP : receives
    EMPLOYEE ||--o{ PERFORMANCE_REVIEW : reviewed_in
    EMPLOYEE }o--|| EMPLOYEE : reports_to

    SHIFT ||--o{ ATTENDANCE_RECORD : applies_to
    LEAVE_TYPE ||--o{ LEAVE_BALANCE : defines
    LEAVE_TYPE ||--o{ LEAVE_REQUEST : used_by
    PAYROLL_RUN ||--o{ PAYSLIP : contains
    SALARY_COMPONENT ||--o{ PAYSLIP : contributes_to
    JOB_OPENING ||--o{ CANDIDATE : attracts
    CANDIDATE ||--o{ INTERVIEW : attends
    PERFORMANCE_CYCLE ||--o{ PERFORMANCE_REVIEW : contains

    COMPANY {
        uuid id PK
        string name
        string timezone
        string country
        string status
    }
    BRANCH {
        uuid id PK
        uuid company_id FK
        string name
        string location
    }
    DEPARTMENT {
        uuid id PK
        uuid company_id FK
        string name
    }
    DESIGNATION {
        uuid id PK
        string title
        string grade
    }
    ROLE {
        uuid id PK
        string name
        string permission_set
    }
    USER {
        uuid id PK
        uuid role_id FK
        string email
        string password_hash
        boolean is_active
    }
    EMPLOYEE {
        uuid id PK
        uuid user_id FK
        uuid branch_id FK
        uuid department_id FK
        uuid designation_id FK
        uuid manager_employee_id FK
        string employee_code
        string full_name
        string status
        date joining_date
    }
    ATTENDANCE_RECORD {
        uuid id PK
        uuid employee_id FK
        uuid shift_id FK
        datetime clock_in_at
        datetime clock_out_at
        string status
    }
    LEAVE_REQUEST {
        uuid id PK
        uuid employee_id FK
        uuid leave_type_id FK
        date start_date
        date end_date
        string approval_status
    }
    PAYROLL_RUN {
        uuid id PK
        uuid company_id FK
        string period_label
        string status
        date processed_on
    }
    PAYSLIP {
        uuid id PK
        uuid payroll_run_id FK
        uuid employee_id FK
        decimal gross_pay
        decimal net_pay
    }
    JOB_OPENING {
        uuid id PK
        uuid company_id FK
        string title
        string status
    }
    CANDIDATE {
        uuid id PK
        uuid job_opening_id FK
        string full_name
        string email
        string stage
    }
    PERFORMANCE_REVIEW {
        uuid id PK
        uuid performance_cycle_id FK
        uuid employee_id FK
        decimal final_score
        string status
    }

Data model notes

• User stores application authentication identity.
• Employee stores HR profile information and references the user account where applicable.
• The employee-to-employee relationship supports reporting hierarchy.
• Payroll, performance, and recruitment modules are modular but share employee and company references.
• Audit and notification tables should be designed as cross-module shared services.

12. Key API groups

• /auth
• /users
• /roles
• /employees
• /branches
• /departments
• /designations
• /attendance
• /attendance-corrections
• /leave-types
• /leave-balances
• /leave-requests
• /holidays
• /announcements
• /notifications
• /job-openings
• /candidates
• /interviews
• /onboarding
• /payroll-runs
• /payslips
• /performance-cycles
• /performance-reviews
• /reports
• /settings
• /audit-logs

13. Business rules

• An employee may only have one active primary manager at a time.
• An attendance record must belong to one employee and one work date.
• A leave request cannot be approved if policy balance validation fails, unless override permission exists.
• Payroll cannot be finalized twice for the same employee and payroll period.
• Employees can edit only approved self-service profile fields.
• Managers can approve requests only for employees within their reporting scope.
• Terminated employees must be restricted from active login based on policy.

14. Non-functional requirements

Performance

• Common dashboard pages should load quickly under normal usage.
• Attendance actions should complete with minimal delay.
• Search and filter actions should remain responsive for large employee directories.

Scalability

• The architecture should support modular horizontal scaling of attendance, payroll, and notification services.
• The platform should support growth from a single branch to multi-branch organizations.

Security

• All traffic shall use encrypted transport.
• Sensitive employee and payroll data shall be protected at rest.
• Role-based access control shall be enforced server-side.
• Audit logs shall capture critical administrative and payroll actions.

Availability

• The system should be designed with backup and recovery procedures.
• Critical data changes should be protected from accidental loss.

Usability

• The interface should use clear status indicators for approvals and exceptions.
• The system should support accessible forms and readable navigation.
• Mobile primary tasks should be streamlined for one-hand use.

Localization

• The platform should support configurable timezone and regional date formatting.
• The platform should be designed to support future multilingual interfaces.

15. Recommended technology stack

Frontend

• Web: React or Next.js
• Mobile: React Native or Flutter
• UI: Tailwind, Material UI, or a custom design system

Backend

• Node.js with NestJS or Express, or Python with Django/FastAPI
• JWT-based authentication with refresh tokens
• Optional SSO provider support

Data and infrastructure

• PostgreSQL
• Redis
• Object storage for files and documents
• Notification queue/event service
• Docker-based deployments
• CI/CD pipeline
• Monitoring and logging stack

16. Release plan

Phase 1: Discovery and design

• Requirements validation
• Workflow mapping
• Wireframes
• Architecture and schema design

Phase 2: MVP build

• Authentication
• Employee management
• Attendance
• Leave management
• Employee self-service
• Notifications
• Reports

Phase 3: Stabilization

• QA
• UAT
• Security testing
• Pilot deployment

Phase 4: Extended modules

• Recruitment
• Onboarding
• Payroll
• Performance management
• Integrations

17. Acceptance criteria for MVP

• Admins can create and manage employee records.
• Employees can log in and manage core self-service actions.
• Employees can clock in and out from mobile.
• Employees can request leave and managers can approve or reject it.
• HR users can view attendance and leave summaries.
• Notifications are delivered for key workflow events.
• Core reports are available by date range and team dimensions.

18. Risks and considerations

• Payroll rules may become highly country-specific.
• Attendance policies may vary by branch or employee type.
• Mobile location-based attendance may require privacy disclosures.
• Recruitment and performance modules can significantly expand complexity if included too early.
• Role design should be carefully planned before implementation to avoid permission sprawl.

19. Recommended next deliverables

After this SRS, the best next documents would be:

1. detailed wireframes for web and mobile screens
2. a developer-ready API specification
3. a prioritized product backlog with user stories and estimates
4. a cost breakdown by MVP and full v1 scope

20. Summary

This HRMS SRS defines a modular web and mobile platform that starts with employee management, attendance, leave, self-service, and reporting, while leaving room to scale into payroll, recruitment, onboarding, and performance management. The included screen flows and ER model provide a practical starting point for product design and engineering execution.

21. Developer-ready API specification

This section provides a practical API contract structure for the MVP and future-ready modules.

21.1 API design principles

• Use RESTful JSON APIs.
• Use bearer token authentication.
• Enforce role-based authorization on every protected endpoint.
• Use pagination for list endpoints.
• Use soft deletes where audit traceability matters.
• Return standardized error objects.

21.2 Standard response format

Success response

json
{
  "success": true,
  "message": "Request completed successfully",
  "data": {},
  "meta": {
    "page": 1,
    "limit": 20,
    "total": 100
  }
}

Error response

json
{
  "success": false,
  "message": "Validation failed",
  "errors": [
    {
      "field": "email",
      "message": "Email is required"
    }
  ]
}

21.3 Authentication APIs

POST /auth/login

Purpose: authenticate a user.

Request body:

json
{
  "email": "[email protected]",
  "password": "string"
}

Response fields:

• accessToken
• refreshToken
• user
• permissions

POST /auth/refresh

Purpose: issue a new access token.

POST /auth/logout

Purpose: revoke the current session.

POST /auth/forgot-password

Purpose: send password reset instructions.

POST /auth/reset-password

Purpose: set a new password.

21.4 User and role APIs

GET /users/me

Purpose: fetch the current authenticated user profile.

GET /roles

Purpose: list available roles.

POST /roles

Purpose: create a role.

PATCH /roles/{id}

Purpose: update role permissions.

21.5 Employee APIs

GET /employees

Purpose: list employees with filters.

Supported query params:

• search
• branchId
• departmentId
• designationId
• managerId
• status
• page
• limit

POST /employees

Purpose: create an employee.

Example request:

json
{
  "firstName": "Ava",
  "lastName": "Rahman",
  "email": "[email protected]",
  "phone": "+8801XXXXXXXXX",
  "branchId": "uuid",
  "departmentId": "uuid",
  "designationId": "uuid",
  "managerEmployeeId": "uuid",
  "joiningDate": "2026-08-01",
  "employmentType": "full_time"
}

GET /employees/{id}

Purpose: fetch employee details.

PATCH /employees/{id}

Purpose: update employee details.

GET /employees/{id}/documents

Purpose: list employee documents.

POST /employees/{id}/documents

Purpose: upload an employee document.

21.6 Attendance APIs

POST /attendance/check-in

Purpose: create a clock-in record.

Example request:

json
{
  "employeeId": "uuid",
  "timestamp": "2026-07-31T09:00:00+06:00",
  "location": {
    "lat": 23.8103,
    "lng": 90.4125
  },
  "deviceType": "mobile"
}

POST /attendance/check-out

Purpose: create a clock-out record.

GET /attendance/me

Purpose: fetch current user's attendance history.

GET /attendance

Purpose: fetch attendance records for admins and managers.

Supported filters:

• employeeId
• dateFrom
• dateTo
• branchId
• departmentId
• status

POST /attendance-corrections

Purpose: submit an attendance correction request.

PATCH /attendance-corrections/{id}/approve

Purpose: approve a correction request.

PATCH /attendance-corrections/{id}/reject

Purpose: reject a correction request.

21.7 Leave APIs

GET /leave-types

Purpose: list leave policy types.

GET /leave-balances/me

Purpose: fetch current employee leave balances.

POST /leave-requests

Purpose: create a leave request.

Example request:

json
{
  "leaveTypeId": "uuid",
  "startDate": "2026-08-10",
  "endDate": "2026-08-12",
  "durationType": "full_day",
  "reason": "Family event"
}

GET /leave-requests/me

Purpose: fetch employee leave history.

GET /leave-requests/pending

Purpose: fetch pending approvals for managers.

PATCH /leave-requests/{id}/approve

Purpose: approve leave.

PATCH /leave-requests/{id}/reject

Purpose: reject leave.

21.8 Announcement and notification APIs

GET /announcements

Purpose: list visible announcements.

POST /announcements

Purpose: create an announcement.

GET /notifications

Purpose: fetch user notifications.

PATCH /notifications/{id}/read

Purpose: mark a notification as read.

21.9 Reporting APIs

GET /reports/headcount

Purpose: fetch headcount summary.

GET /reports/attendance-summary

Purpose: fetch attendance metrics.

GET /reports/leave-summary

Purpose: fetch leave metrics.

21.10 Future module APIs

• /job-openings
• /candidates
• /interviews
• /onboarding
• /payroll-runs
• /payslips
• /performance-cycles
• /performance-reviews

21.11 Suggested status codes

• 200 success
• 201 created
• 400 validation error
• 401 unauthenticated
• 403 forbidden
• 404 not found
• 409 conflict
• 422 business rule violation
• 500 server error

22. Wireframes and screen-by-screen UI layout

This section translates the screen flow into practical interface blocks for design and development.

22.1 Web wireframe outline

A. Login screen

Sections:

• Company logo and product name
• Email field
• Password field
• SSO buttons
• Forgot password link
• Sign in button

B. Admin dashboard

Sections:

• Top navigation with user menu
• Left sidebar navigation
• KPI cards: total employees, present today, on leave, pending approvals
• Attendance trend widget
• Leave summary widget
• Recent notifications panel
• Quick actions panel

C. Employee directory

Sections:

• Search bar
• Filter row
• Employee table or cards
• Bulk action toolbar
• Pagination

D. Employee profile

Tabs:

• Overview
• Job details
• Attendance
• Leave
• Documents
• Payroll
• Performance
• Audit history

E. Attendance monitor

Sections:

• Date selector
• Shift filter
• Attendance summary cards
• Attendance table
• Exceptions panel

F. Leave approvals

Sections:

• Pending approval list
• Calendar view
• Request details drawer
• Approve and reject actions

G. Reports screen

Sections:

• Filter bar
• Chart area
• Summary cards
• Export actions

H. Settings screen

Sections:

• Company settings
• Branches
• Departments
• Designations
• Holidays
• Leave policies
• Shift policies
• Roles and permissions

22.2 Mobile wireframe outline

A. Mobile home screen

Sections:

• Greeting header
• Today status card
• Clock in or out button
• Attendance shortcut
• Leave shortcut
• Notifications preview
• Announcements preview

B. Apply leave screen

Sections:

• Leave type selector
• Date range selector
• Duration selector
• Reason field
• Balance preview
• Submit button

C. My attendance screen

Sections:

• Monthly summary strip
• Calendar or list toggle
• Daily entries list
• Correction request action

D. Manager approvals screen

Sections:

• Pending requests list
• Request detail bottom sheet
• Approve and reject buttons

E. Profile screen

Sections:

• Profile card
• Personal details
• Job details
• Editable info form
• Documents shortcuts

22.3 Navigation model

Web navigation

• Persistent left sidebar
• Global top bar
• Breadcrumbs on detail screens
• Role-based menu visibility

Mobile navigation

• Bottom tab navigation for Home, Attendance, Leave, Notifications, Profile
• Additional manager approval shortcut on Home
• Contextual back navigation on forms and detail screens

23. Feature backlog with user stories

This backlog is prioritized for delivery planning.

23.1 Epic: Authentication and access

User stories

• As a user, I want to log in securely so I can access my HR workspace.
• As an admin, I want role-based permissions so users only see what they are allowed to use.
• As a mobile user, I want biometric unlock so I can reopen the app quickly.

Acceptance notes

• Login works for valid credentials.
• Unauthorized users cannot access protected routes.
• Mobile biometric login only works after first password login.

23.2 Epic: Employee management

User stories

• As an HR admin, I want to create employee profiles so records are centrally maintained.
• As an HR admin, I want to assign departments, branches, and managers so reporting lines are clear.
• As a manager, I want to view my team members so I can review their status and requests.

23.3 Epic: Attendance management

User stories

• As an employee, I want to clock in and out so my attendance is recorded.
• As an employee, I want to request correction for missed or incorrect attendance so my record stays accurate.
• As a manager, I want to review attendance exceptions so I can take action quickly.

23.4 Epic: Leave management

User stories

• As an employee, I want to apply for leave from mobile so I can request time off quickly.
• As a manager, I want to approve or reject leave requests so leave is controlled efficiently.
• As an HR admin, I want to configure leave rules so balances are calculated correctly.

23.5 Epic: Employee self-service

User stories

• As an employee, I want to view my profile so I can confirm my records.
• As an employee, I want to view my leave balance and attendance history so I can manage my time.
• As an employee, I want to access my announcements and documents so I stay informed.

23.6 Epic: Notifications

User stories

• As a user, I want to receive notifications for important actions so I do not miss approvals or updates.
• As an HR admin, I want to publish announcements so I can communicate policy or company updates.

23.7 Epic: Reporting

User stories

• As an HR admin, I want attendance and leave summaries so I can monitor workforce operations.
• As a manager, I want team status dashboards so I can act on absences and pending approvals.

23.8 Backlog priority list

Must have for MVP

1. Authentication and roles
2. Employee profile management
3. Department, branch, designation setup
4. Clock in and clock out
5. Attendance history
6. Attendance correction requests
7. Leave types and balances
8. Leave request and approval flow
9. Employee mobile home dashboard
10. Admin dashboard
11. Notifications
12. Announcements
13. Reports

Should have

1. Holiday calendars
2. Shift rules
3. Search and filters
4. Document management
5. Bulk employee actions
6. Export reports

Could have

1. Biometric attendance device sync
2. Multi-language UI
3. E-signature support
4. Advanced analytics

Later phase

1. Recruitment
2. Onboarding
3. Payroll
4. Performance management
5. Asset management

23.9 Suggested sprint plan

Sprint 1

• Authentication
• Roles and permissions foundation
• Company, branch, department, designation setup
• Base UI shell

Sprint 2

• Employee directory
• Employee create and edit flows
• Profile details
• Manager hierarchy

Sprint 3

• Attendance check-in and check-out
• Attendance history
• Attendance correction flow
• Notifications foundation

Sprint 4

• Leave setup
• Leave balance engine
• Leave request flow
• Manager approval flow

Sprint 5

• Dashboards
• Reports
• Announcements
• QA hardening for MVP

24. Cost breakdown for MVP and full v1

These are practical planning ranges and will vary by geography, team composition, design depth, and compliance complexity.

24.1 Estimated team model

• 1 Product Manager
• 1 UI/UX Designer
• 2 Frontend Engineers
• 2 Backend Engineers
• 1 Mobile Engineer
• 1 QA Engineer
• 1 DevOps Engineer (part-time or shared)

24.2 MVP timeline and cost range

Scope

• Authentication
• Employee management
• Attendance
• Leave management
• Employee self-service
• Notifications
• Basic dashboards and reports
• Web and mobile apps

Timeline

• 3 to 4 months for a focused MVP

Estimated cost range

• Lean offshore team: $25,000 to$45,000
• Balanced mid-market team: $45,000 to$90,000
• Senior agency or enterprise-grade team: $90,000 to$180,000

24.3 Full v1 timeline and cost range

Scope

• MVP features
• Recruitment
• Onboarding
• Payroll
• Performance management
• Documents and advanced reporting
• Integration layer

Timeline

• 6 to 10 months depending on payroll complexity and compliance requirements

Estimated cost range

• Lean offshore team: $70,000 to$140,000
• Balanced mid-market team: $140,000 to$300,000
• Senior agency or enterprise-grade team: $300,000 to$600,000+

24.4 Cost drivers

• Payroll country complexity
• Number of custom roles and permissions
• Need for biometric integrations
• Required mobile polish and offline capability
• Number of reports and exports
• Security and compliance requirements
• Multi-branch or multi-country support

24.5 Recommended cost-saving approach

• Launch MVP first with attendance, leave, employee records, and self-service.
• Delay payroll until the operational model is validated.
• Use a shared design system for web and mobile.
• Build modular APIs so later modules do not require rework.

25. Final recommendation

The strongest execution path is:

1. finalize the MVP scope
2. convert the wireframe outline into low-fidelity designs
3. lock the API contracts for MVP modules
4. estimate the backlog by sprint
5. begin phased delivery with attendance and leave as the first operational modules

26. Delivery package summary

This document now includes:

• the full SRS
• UI/UX screen flows
• ER diagram and data model
• developer-ready API structure
• wireframe outlines
• feature backlog and sprint plan
• MVP and full v1 cost ranges

This gives you a strong starting package for product planning, UI design, and engineering kickoff.