SOFTWARE REQUIREMENTS

SPECIFICATION

VERSION 1.0

JANUARY 31, 2025

FACE RECOGNITION SYSTEM

1. Introduction
1.1 Purpose
This document specifies the software requirements for the Face Recognition
Attendance System, Version 1.0. The system automates attendance-taking through
facial recognition technology, intended for use in organization and professional
settings. This system aims to provide a seamless and accurate solution for
monitoring and recording attendance in various organizational settings by
leveraging real-time database integration.
This document serves as the baseline for the system's development, testing, and
deployment. Any future extensions or integrations with external systems will be
covered in separate releases.

1.2 Scope
This project focuses on:
 Creating and managing user accounts.
 Synchronizing data between client and server.
 Tracking and processing attendance data.
 Development of user-friendly interfaces for different user roles for marking
attendance using facial recognition.
 User authentication and authorization mechanisms to control access and
permissions.
 Secure access for administrators to manage attendance data

1.3 Objectives
 Ensure reliable user data management.
 Automate attendance tracking.
 Establish seamless integration between client, server, and external systems.
2. Project Overview
The project involves designing a system that enables users to create accounts,
synchronize their data, and manage attendance records. The system also calculates
attendance-related metrics and integrates with external services to expand
functionality. It includes automated retries and notifications to handle errors
effectively.

3. System Architecture
3.1 Components
Client Application: Interface for user interactions.
Server: Centralized system for processing and storing data.
External Systems: Third-party integrations for data sharing and additional
processing.
Database: Stores user information, attendance records, and logs.

3.2 Architecture Diagram

 The system architecture includes:
 Input from users.
 Data synchronization between client and server.
 Processing layers for validation and calculations.
 External systems for extended functionalities.

4. Functional Requirements
4.1 User Account Management
4.1.1 Create Account
This app gives access to two kinds of users.
1. Administrator: Administrator will open an account using our app where they
will open an account with their email address, and the user will be verified by
sending a code to their email, while opening an account, they will have to fill
up the form as normal by entering their email, number, name, username
password etc.

2. User: Administrator will open user accounts one by one, for which there will
be an "Add User" option. Where all personal data like user id, picture, name,
department, join time, phone number, default password etc. will be input.

4.1.2 Update Account

 Administrator can update his account information from his profile page
also
 User only can update his personal information he can’t modify attendance
related information
4.1.3 Delete Account
 Admin can delete user account and also can delete his account

4.2 Connect device

Here have 2 ways to connect machine with app manual connect devise with
searching and “QR scan” to connect Bluetooth need to keep both ways to connect
device.
4.2.1 Set Password
When a device is requested to connect from the MCU/machine, first set the default
password as "0000" or "1111" or any other, then a pop up will appear asking if this
default password is being used. If you click "ok" and the default password will be
set, if you click cancel, it will start the process of setting a new password.

4.2.2 Save device password in server

If you select set password, then by API save password in server. Use this password
he can log in next time. If you select input password, then first time it needs to set
your password by entering it two times. Next time when user login then uses this
new set password. If user forget his set password or used password, then he can
retrieve it with his registered email by getting security code also long press the
power button can reset the default password.
4.2.2 Search device for connect
When you try to connect devices that time need a search system in this app for
determined which devices in nearby this app. With Bluetooth (BLE) we can achieve
this purpose.
Discovery Mechanism by Web-Sockets:
To achieve device discovery with Web-Sockets, there needs to be a mechanism
in place for the devices to announce themselves. For example:
 Devices could register their Web-Socket endpoints (IP address and port) on a
central server.
 The app could query this server to find available devices and then connect to
them via Web-Socket.
 This would be similar to how a web application might discover services on a
network via a directory or registry system, but it wouldn't be "searching" for
devices like Bluetooth does.
4.3 Apps main interface
4.3.1 Connect device
Follow the description of 4.2.2

4.3.2 Create user account

First when the account is created through all the verifications, now this user
information has to be sent to the device and server for which we can use two
methods Bluetooth and cloud. The information has to be stored in the device
because when someone's face is detected then his data has to be matched to see if it
is in the database or not, if it is then needs to give his attendance for that day.
Send information to the device's mcu via Bluetooth and store it in the device's
internal memory. It also needs to be updated in the device's mcu when adding new
employees or updating/deleting employee information which requires the option to
sync data between the server and the device via the app.
1. User Creation & Initial Data Collection

1. A new user profile is created with the following details:

 Name, ID, Department

 Face recognition image
 Join time
 Contact details (phone number, etc.)

2. This user data is stored in the system for identification purposes.

2. Data Transmission from MCU (Microcontroller Unit)

A. Bluetooth Mode (Local Communication)

 The MCU (Microcontroller Unit) sends command data via Bluetooth

(BLE).
 The attendance machine processes the scanned data.
 If successful, it returns OK and continues processing.
 If failed, it returns NG (Not Good), and the system rechecks the data and
resends it.

B. Cloud Mode (Remote Communication)

 If the attendance machine operates in Cloud Mode, it:

 Sends MAC ID + Email Account of the user for verification.

 If it's the first time, this data is stored in the server via API with a key.
 The server generates a client ID and stores it in the database.

3. Client ID & Database Storage

1. Client ID Creation

 Once a new MAC ID is verified, the server assigns a unique client

ID.
 This ID is used for further user identification.

2. Database Structure
  Data is stored in a grouped table based on client ID.
 For 100+ users, multiple tables may be created.

3. Stored Data Includes:

 User Information: (Name, ID, Department, Face Data, Contact, etc.)

 Attendance Data: (Check-in, Check-out times, Late, Missed Punch,
etc.)
 Rules: (Shift Timing, Overtime Rules, Holiday Policies, etc.)
 Calculation Data: (Processed work hours, overtime, etc.)

4. Data Retrieval & Processing

1. The server processes attendance data from the database.

2. If a client ID is recognized, it allows access.
3. If the client ID is not found, the system requests a retry.
4. Attendance rules are applied to calculate:

 Work hours
 Late/Early deductions
 Overtime
 Missed punches

5. Data Update & Real-Time Transmission

A. MCU Sending Data to the Server

 The MCU sends user attendance data using commands.

 If verified, data is stored in the server database.
 If an error occurs, data is rechecked and resent.

B. WebSocket for Real-Time Updates

 If attendance data is recorded, it is sent via WebSocket to notify other

applications.
 This ensures real-time attendance monitoring.

C. Applications Syncing Data

  Apps retrieve and update attendance data.
 Data is stored for further calculations.

4.3.3 User list

every user/employee account must show in this list administrator can delete and
update user accounts from this list. this data is also in the device's memory
4.3.4 Send Notice
1. Notice for all users which is show on his app interface when admin published
it.
2. Individual notification sends only for a specific user
4.3.5 Reports
1. Daily report
The following items may be included in the leave report:
 Employee Information:
 Employee ID or name
 Department/team
 Position or role
 Employee Information:
 Present: Whether the employee was at work on the specific day
 Absent: Whether the employee was absent, and if so, the reason (if
provided)
 Late: Whether the employee arrived late and the time of arrival
 Early Departure: Whether the employee left early and the time of
departure
 Half-day: If the employee worked only part of the day (e.g., a half-
day off)
 Leave Taken: If the employee took any kind of leave (e.g., sick
leave, vacation, personal leave)
 Overtime: If the employee worked overtime and how many hours
were worked
  Employee Information:
 Clock-in time: The time the employee clocked in for the day (if
applicable)
 Clock-out time: The time the employee clocked out for the day (if
applicable)
 Total worked hours: The total number of hours worked during the
day, including overtime
 Breaks taken: Duration or timing of any breaks taken (if
applicable)
2. Leave report
The following items may be included in the leave report:
 Employee Leave Summary:
 Total number of employees in the company
 Total number of leave requests (approved, pending, rejected)
 Total leave taken across all employees
 Leave usage by department/team
 Total leave balance available for all employees
 Employee Leave Details:
 Employee name or ID
 Department or team
 Type of leave (sick leave, vacation, personal leave, etc.)
 Leave start and end dates
 Duration of leave (days or hours)
 Reason for leave (if applicable, or categorized by type of leave)
 Leave Approval Status:
 Status of each leave request (approved, pending, or rejected)
 Manager's approval or comments for each request
 Any special conditions (e.g., unpaid leave, part-time leave)

3. Salary report
 Attendance Information:
  Presence Status: Whether the employee was present, absent, on
leave, or working remotely
 Late Arrival: If the employee was late, and the time of arrival (e.g.,
"Arrived at 9:30 AM instead of 9:00 AM")
 Early Departure: If the employee left early, and the time of
departure
 Leave Type: If the employee took any leave (e.g., sick leave,
personal leave, vacation, etc.)
 Overtime Hours Worked: If the employee worked overtime, with
details on the number of overtime hours
 Half-Day or Partial Attendance: If the employee worked a partial
day or had specific hours off
 Clock-in and Clock-out Times: The exact times the employee
clocked in and out for the day (if using a time-tracking system)
 Salary Impact:
 Base Salary: The employee's regular salary (may be included as a
reference for calculating daily wages)
 Daily Wage: Calculated daily wage (base salary divided by the
number of working days in the month)
 Overtime Pay: Details of overtime hours worked, and the
corresponding pay rate for overtime (typically higher than regular
pay)
 Leave Deductions: Any deductions made for unpaid leave or
absences not covered by leave balances
 Salary Adjustments: Any adjustments made to the salary (e.g.,
bonuses, commissions, performance incentives, etc.)
 Deductions: Any other salary deductions related to the day's
attendance (e.g., fines for unapproved absences, tardiness
penalties)
4.4 Punch Attendance
If someone punches for attendance or face recognition, the data will be sent to the
server which will be done through internet connection. If there is no internet, then it
will be stored in the device MCU. Later when internet is available then MCU will
send the data to the server.
4.5 Desktop/Web application for Scanned data calculation
1. Data Collection and Storage

 The attendance machine store user machine data (e.g. timestamps, MAC ID).
 The first-time scan saves the MAC ID locally.
 The data is sent to the server via an API with a key.
 The server stores user information, attendance data, and rules for
processing.

2. Rules and Processing

 The system has a rules module that includes:

 In-time and out-time rules

 Late arrival, missed punch, etc.
 Attendance policies

 The application needs user information before setting rules.

 Rules can be modified via an API.
 If modifications are successful, the system returns "OK", otherwise, it
returns "NG" (Not Good).

3. Desktop/Web Application for Calculation

 Users log in to the main desktop application (or web app) using their email.
 The application pulls data from the server, including:

 User details
 Attendance records
 Rules

 The app calculates attendance data (late arrivals, missed punches, etc.).
 The results are stored and matched with user email accounts.

4. Data Transmission

 Processed data is sent to the server, including:

 User ID
 Email account
  MAC ID
 Attendance-related issues (late arrivals, missed punches)

 The server returns confirmation of data receipt.

5. HR Management System Integration

 A PC-based HR management system can be used to manage and analyze

attendance data.
 This system requires payment to access certain features.

6. Real-time Updates

 Attendance issues are sent to other applications via WebSocket for real-time
updates.
 This functions similarly to a chat system, keeping relevant users informed of
attendance changes.
4.6 Connecting users/employees to the app
When Admin/Hr./owner add an employee in the system that time automatic
generates a QR code for that user to share with employee. Employee scan this QR
code and connect to the system database.
If the employee is already using our app, he/she will already have an account and a
unique QR code on our app. Then, the admin can scan that QR code and connect
him to the attendance machine server/database.

Admin Employee

In this QR code match

 Machine mac id
 User Id
 User email

5. Non-Functional Requirements
5.1 Performance
 Data synchronization must complete within 5 seconds.
 Attendance calculations should take no longer than 2 second per user.
5.2 Reliability
 99.9% uptime for the server.
 Automatic retries for 99% of transient errors.
5.3 Scalability
 Support up to 1,000 users concurrently.
 Expandable external system integrations.
5.4 Security
 Encrypt sensitive data in transit and at rest.
 Implement role-based access controls.

6. Process Workflow
Key Processes
1. User Account Creation: From user input to account verification.
2. Data Synchronization: Bidirectional data flow between employee and
admin and server.
3. Attendance Processing: Recording and calculating attendance
durations and generate a monthly report of employee.

7. Data Flow
 Input Data
 User account details (e.g., name, email).
 Attendance events (e.g., timestamps).
 Output Data
 Confirmation messages.
 Attendance reports.
 Error logs.
8. Use Cases
8.1 User Account Creation
 Actor: End User.
 Preconditions: User provides valid input.
 Steps:
1. Submit details.
2. Validate input.
3. Create account.
4. Verify via email/SMS.
5. Post conditions: User account is activated.

8.2 Attendance Tracking

 Actor: End User.
 Preconditions: User is registered.
 Steps:
1. Record check-in/check-out.
2. Process data.
3. Store in database.
4. Post conditions: Attendance records updated.

9. Error Handling
9.1 Retry Mechanisms
 Automatic retry for transient errors.
 Log failures for manual review.
 Inform users of errors with correct message.
 Log notifications for audit.
9.3 Assumptions and Constraints
 Reliable internet connection required.
 External systems must respond within 5 seconds.

10. Conclusion
This document serves as a blueprint for developing a reliable, efficient,
and user-friendly system based on the processes outlined in the provided
flowchart. The detailed workflows, functional requirements, and system
architecture ensure a robust implementation.