Software Requirements Specification

for

Document Access Control System

Version 1.0 approved
Prepared by: 1. Man Mohan Jha(123A1060)
2. Nancy Maruthuvar(123A1063)
3. Swarika Maurya(123A1064)
4. Divya Mudaliar(123A1070)
Batch: C3

Date: 18/07/2025
Software Requirements Specification for Document Access Control System

Table of Contents
1. Introduction
1.1 Purpose
1.2 Document Conventions
1.3 Intended Audience and Reading Suggestions
1.4 Product Scope
1.5 References
2. Overall Description
2.1 Product Perspective
2.2 Product Functions
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. External Interface Requirements
3.1 User Interfaces
3.2 Hardware Interfaces
3.3 Software Interfaces
3.4 Communications Interfaces
4. System Features
4.1 User Registration and Document Upload
4.2 Admin Verification and Smartcard Assignment
4.3 RFID Scan and Authentication
4.4 Email verification and Document Display
4.5 Smartcard Write and Overwrite Handling
5. Other Nonfunctional Requirements
5.1 Performance Requirements
5.2 Safety Requirements
5.3 Security Requirements
5.4 Software Quality Attributes
5.5 Business Rules
6. Other Requirements
Appendix A: Glossary
Appendix B: Analysis Models
Appendix C: To Be Determined List

2
Software Requirements Specification for Document Access Control System

1. Introduction

1.1 Purpose
A Software Requirements Specification (SRS) document defines the complete set of
requirements for a software system, serving as a guide for developers, testers, and
stakeholders. This SRS specifies Version 1.0 of the Document Access Control System using
Smartcards, which securely manages access to encrypted personal documents like Aadhaar and
PAN cards by authenticating users through smartcards and PINs. The system combines
hardware and software components to provide a reliable, end-to-end identity verification
solution for academic and enterprise environments. Functionally, it includes user
authentication, document encryption and decryption, access control, audit logging, user
management, Wi-Fi connection, and notifications. Non-functional requirements, the system
requires secure, access-controlled locations for hardware to prevent tampering, and an
uninterrupted power supply to ensure continuous operation. A reliable, secure network is
needed for communication between devices and servers. The system must comply with data
protection standards like ISO 27001. Regular hardware maintenance and software updates are
necessary to keep the system running smoothly, and secure physical backups should be
maintained for disaster recovery.

1.2 Document Conventions

[No document conventions to mention]

1.3 Intended Audience and Reading Suggestions

This document is intended for:

 Software developers and testers should pay most attention to Sections 2–5, which
explain what the system needs to do, how it should behave, and how to test it.
 Hardware integrators should focus on Section 2, which covers how hardware and
software must work together, and Section 3, which details hardware-specific needs.
 Project managers will find Sections 1 and 6 helpful since they lay out the project’s
purpose, boundaries, assumptions, and planning details.
 Security auditors should review Sections 4.3 and 5.3, where the document covers
security controls, compliance requirements, and auditing measures.
 Faculty evaluators or academic reviewers should read the entire document to assess its
completeness, clarity, and adherence to standards.

3
Software Requirements Specification for Document Access Control System

 New or occasional readers can get started with Section 1 for an introduction, then move
on to Section 2 to understand the system at a high level before diving into the details.

1.4 Product Scope

In-Scope Features

 User Authentication: Implement secure login mechanisms, including support for multi-
factor authentication (MFA).
 Role-Based Access Control (RBAC): Define and assign roles to users, granting access to
documents based on their roles.
 Document Permissions Management: Allow administrators to set and modify
permissions for documents, specifying who can view, edit, or share them.

1.5 References
[1] R. Want, "An introduction to RFID technology," in IEEE Pervasive Computing, vol. 5, no.
1, pp. 25-33, Jan.-March 2006, doi: 10.1109/MPRV.2006.2.
[2] A. Larchikov, S. Panasenko, A. V. Pimenov and P. Timofeev, "Combining RFID-based
physical access control systems with digital signature systems to increase their
security," 2014 22nd International Conference on Software, Telecommunications and
Computer Networks (SoftCOM), Split, Croatia, 2014, pp. 100-103, doi:
10.1109/SOFTCOM.2014.7039085.
[3] B. Fabian, T. Ermakova and C. Muller, "SHARDIS: A Privacy-Enhanced Discovery Service
for RFID-Based Product Information," in IEEE Transactions on Industrial Informatics, vol.
8, no. 3, pp. 707-718, Aug. 2012, doi: 10.1109/TII.2011.2166783.
[4] V. R, H. N and N. M R, "Multi-Factor Authentication System With ID Card Credentials For
Secure Transactions," 2023 14th International Conference on Computing
Communication and Networking Technologies (ICCCNT), Delhi, India, 2023, pp. 1-8, doi:
10.1109/ICCCNT56998.2023.10308252.

4
Software Requirements Specification for Document Access Control System

2. Overall Description

2.1 Product Perspective

The Document Access Control System using Smartcards is a new and independent product
developed to enhance the security and automation of identity document verification. It is not a
replacement or upgrade of any existing system but is designed to introduce a hardware-backed
multi-factor authentication approach that is currently lacking in traditional verification
methods.

Existing verification processes mostly involve manual checks or online systems that rely on
passwords alone, which are prone to fraud and unauthorized access. This product addresses
these shortcomings by combining smartcard-based RFID authentication with encrypted
document storage and email verification, thereby providing stronger identity protection.

The system is intended to function as a standalone solution but can be integrated with
institutional IT infrastructures if required. It operates independently without dependence on
prior systems and provides secure interfaces for communication between hardware
components, backend services, and user-facing applications.

2.2 Product Functions

The Document Access Control System using Smartcards provides the following major functions:

 User Registration and Document Upload

Allows users to create accounts, upload scanned Aadhaar and PAN card images, and
track their application status.
 Administrator Verification and Smartcard Issuance
Enables administrators to review uploaded documents, approve or reject them, and
assign encrypted smartcards to verified users.
 Smartcard-Based Authentication
Supports RFID scanning of smartcards to authenticate users in real-time through
communication between the hardware and backend.
 Two-Factor Email Verification
Sends verification emails to users after successful smartcard scans, requiring users to
confirm their identity before accessing documents.

5
Software Requirements Specification for Document Access Control System

 Secure Document Access and Display

Decrypts and displays verified documents only upon successful authentication and
email confirmation.
 Audit Logging and Feedback
Logs all access attempts and provides real-time visual and auditory feedback through
LEDs and buzzers to indicate success or failure.

2.3 User Classes and Characteristics

1. Use Case Diagram

The following Use Case diagram illustrates the interaction between the End User, RFID
reader, and the backend system during the registration and authentication process. It identifies
primary use cases such as document upload, RFID scan, email verification, and document
retrieval.

Figure 2.3.1 Use Case Diagram for User Registration and Authentication

6
Software Requirements Specification for Document Access Control System

2. Sequence Diagram

This sequence diagram models the step-by-step interaction between

system components when a user taps their RFID smartcard to access their
Aadhaar and PAN documents. It captures the request flow from the RFID
scan to backend verification and document display via email authentication.

Figure 2.3.2 Sequence Diagram for Document Access Via

SmartCard

2.4 Operating Environment

 ESP32 Microcontroller: A dual-core microprocessor with integrated Wi-Fi and Bluetooth

capabilities, serving as the central processing unit for the system.
 RFID Reader: An RFID module operating at 13.56 MHz, compliant with ISO/IEC 14443
standards, used to read data from RFID smartcards.
 Smartcards (ISO/IEC 14443 compliant): Contactless smartcards that store unique
identification information, enabling secure access control.

7
Software Requirements Specification for Document Access Control System

 16x2 LCD Display: An alphanumeric display used to provide real-time feedback to users,
such as "Access Granted" or "Access Denied" messages.

 LEDs and Buzzer: Visual (LEDs) and auditory (buzzer) indicators that signal the status of
the access attempt.

Software Environment:

Backend: Python :
 Manages the server-side logic, handles HTTP requests, processes data, and
communicates with the database.
 Expose RESTful APIs for frontend communication.
 Authenticate and authorize users.
 Log access events and manage user permissions.
 Send email notifications via SMTP.

Microcontroller Firmware: Arduino C++:

 Operates the ESP32 microcontroller, interfacing with hardware components like the
RFID reader, LCD display, LEDs, and buzzer.
 Read RFID tags from smartcards.
 Display messages on the LCD.
 Signal access status using LEDs and buzzer.
 Communicate with the backend server to log access events.

Database: SQLite or MySQL:

 Stores persistent data such as user credentials, access logs, and system configurations.
 Store user information and access permissions.
 Log access attempts and system events.
 Provide data retrieval for reporting and analytics.

Frontend: HTML, CSS, JavaScript:

 Stores persistent data such as user credentials, access logs, and system configurations.
 Store user information and access permissions.
 Log access attempts and system events.
 Provide data retrieval for reporting and analytics.

8
Software Requirements Specification for Document Access Control System

SMTP server for email notifications:

(Insert deployment architecture image here — backend, SMTP, database, ESP32,
frontend)
 Facilitates the sending of email notifications for events such as access attempts, system
alerts, and user communications.
 Send confirmation emails upon successful access.

2.5 Design and Implementation Constraints

The development and deployment of the Document Access Control System using Smartcards
are subject to the following constraints:

 Hardware Limitations:
The system must operate on the ESP32 microcontroller platform and interface with the
RFID RC522 reader. The limited storage capacity and processing power of these devices
impose restrictions on encryption algorithms and data handling.
 Cost Constraints:
The choice of hardware components and software tools is influenced by budget
limitations. High-cost proprietary software or hardware solutions are avoided to
maintain project feasibility and accessibility.
 Regulatory and Legal Compliance:
The system must comply with Indian data protection laws, including the Information
Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data
or Information) Rules, 2011, and the Digital Personal Data Protection Act, 2023. These
regulations influence data storage, encryption, and access policies.
 Communication Protocols:
The system relies on standard protocols such as SPI for RFID communication,
HTTP/HTTPS for backend API interactions, and SMTP for email services. Compatibility
and security over these protocols must be ensured.
 Security Requirements:
Encryption standards such as AES-256 are mandatory to protect sensitive data.
Additionally, all backend services must implement secure authentication and access
controls in line with organizational security policies.
 Software Tools and Languages:
Development will use Python for the backend, Arduino C++ for microcontroller

9
Software Requirements Specification for Document Access Control System

firmware, and standard web technologies (HTML, CSS, JavaScript) for the frontend.
These choices are based on team expertise and maintainability.
 Operating Environment Constraints:
The backend server must be deployed on Linux-based systems with minimum resource
requirements (at least 1 GB RAM), ensuring stable operation and scalability.
 User Documentation and Maintenance:
The software must be developed following coding standards and modular design to
facilitate future maintenance by the customer’s technical team.

2.6 User Documentation

The following documentation components will be delivered to support different types of users:

1. End User Manual

This manual provides step-by-step instructions for system registration, document
upload, smartcard usage, and email-based verification. It includes screenshots and
troubleshooting tips.
Format: PDF and printed booklet.
2. Administrator Guide
This document details the backend functionalities, including user approval, smartcard
assignment, and managing system logs. It will also cover encryption practices and secure
storage guidelines.
Format: PDF and web-based HTML version
3. Hardware Setup Guide
This guide explains wiring the ESP32 microcontroller with the RFID reader, connecting
peripheral components (LED, LCD, buzzer), and flashing the microcontroller firmware.
Format: PDF with diagrams and labeled pinouts
4. Developer Setup Instructions
A technical guide covering backend server setup, frontend code deployment,
environmental configuration (.env), database initialization, and API usage.
Format: Markdown ([Link]) for GitHub repository and PDF export

2.7 Assumptions and Dependencies

Assumptions

10
Software Requirements Specification for Document Access Control System

 It is assumed that all users possess valid, scannable Aadhaar and PAN card documents at
the time of registration.
 The ESP32 microcontroller and RFID RC522 reader modules are correctly wired and
compatible with the power and signal specifications.
 A stable internet connection is available for real-time backend communication and email
transmission.
 The SMTP email service used for verification is properly configured and has no rate
limits that affect timely delivery.
 The encryption/decryption processes are assumed to perform reliably within the limited
memory of the ESP32.
 The hosting server environment supports Python 3.8+ and the necessary packages
(Django, MySQL, etc.).

Dependencies

 Functionality is dependent on the availability of a working SMTP service for sending

email verification links.
 The system assumes access to RFID-compatible smartcards and does not currently
support contact-based smartcards.
 The project reuses open-source or community-tested libraries for smartcard read/write
operations.
 Any changes to legal regulations around handling of Personally Identifiable Information
(PII) could require modification to the storage and encryption policies in the system.

11
Software Requirements Specification for Document Access Control System

3. External Interface Requirements

3.1 User Interfaces

The system provides two main graphical user interfaces (GUIs): one for end users and another
for administrators. Both interfaces are browser-based and developed using HTML, CSS, and
JavaScript. The layout has standard design principles for usability and accessibility.

General Design Standards:

 All screens follow a consistent color scheme, button style, and layout hierarchy.
 Fonts used are sans-serif (e.g., Roboto or Arial) for better readability.
 Responsive design ensures usability across desktops, tablets, and smartphones.
 All buttons have hover states and focus indicators for accessibility.
 Error messages are context-aware and color-coded (e.g., red for errors, green for
success).
 Help icons (?) appear next to major input fields to provide guidance via tooltips.

1. User Registration Page:

 Inputs: Name, Email, Aadhaar Image Upload, PAN Image Upload, Password.
 Buttons: Submit, Reset
 Field Validations: Aadhaar and PAN images must be in PNG or JPG format and under
2MB.
 Error Display: Inline under each field using red text.
 Confirmation Message: "Registration successful. Await admin approval." in green.
 (Insert screenshot placeholder of Registration Page UI)

2. User Login Page:

 Inputs: Email, Password

 Buttons: Login, Forgot Password
 Keyboard Support: Tab for navigation, Enter to submit
 Error Message: "Invalid credentials" with option to retry

12
Software Requirements Specification for Document Access Control System

3. Document Upload Status Page:

 Displays current status: Pending, Approved, or Rejected

 If rejected, a reason is shown
 Smartcard assignment status displayed

4. Admin Dashboard:

 Sidebar Navigation: View Users, Approve Documents, Smartcard Assignment, Logs

 Table View: Paginated list of users with filters (Approved / Pending / Rejected)
 Action Buttons: Approve, Reject, Assign Smartcard
 Document preview available via modal pop-up
 (Insert screenshot placeholder of Admin Dashboard UI)

5. RFID Scan Feedback Display (16x2 LCD):

 Messages like “Card Scanned”, “Access Granted”, “Authentication Failed”

 LEDs (green/red) blink accordingly
 Buzzer beeps on card scan success/failure

6. Email Verification UI:

 A minimal web page is shown when a user clicks the email link:
o If valid: "Verification successful. Your documents are displayed below."
o If expired/invalid: "Link expired or invalid. Please retry."

3.2 Hardware Interfaces

The system interfaces with several hardware components, each serving a specific function for
communication and feedback.

RFID RC522 Reader Module

 Connection: Communicates with the ESP32 using the SPI protocol.

 Function: Reads RFID tag or smartcard UID and sends it to the ESP32 for authentication.
 Control: The ESP32 initiates the reading process and handles errors by resetting the
module if needed.

13
Software Requirements Specification for Document Access Control System

16x2 LCD Display

 Connection: Communicates with the ESP32 via I2C.

 Function: Displays status messages, e.g., "Access Granted" or "Authentication Failed".
 Control: ESP32 sends commands to update text on the display.

Buzzer and LEDs

 Connection: Controlled via GPIO pins on the ESP32.

 Function: Provides visual (LED) and auditory (buzzer) feedback during authentication.
 Control: The ESP32 triggers the buzzer and LEDs based on authentication results.

Smartcards

 Connection: Data is read from or written to the smartcard via the RFID module.
 Function: Stores encrypted user data, which the ESP32 retrieves for authentication.
 Control: ESP32 reads the UID and sends it to the backend server for verification.


3.3 Software interfaces

Backend Server (Django)

 Framework: Django (Python).

 Purpose: Exposes RESTful APIs for RFID scan verification, database interactions, and
email notifications.
 Endpoints:
o /verify_rfid: Verifies RFID scan data sent from the microcontroller.
o /store_data: Stores/retrieves user and card data from the database.
o /send_notification: Sends email notifications (e.g., access granted/denied).

Microcontroller (ESP32 with C++)

 Programming: C++ using Arduino IDE.

 Purpose: Scans RFID tags, sends UID to the backend server, and provides feedback (via
LCD, buzzer, and LEDs).
 Communication: Uses HTTP requests to send data (UID) to the backend and receives
responses (authentication results).

14
Software Requirements Specification for Document Access Control System

Database (MySQL )

 Type: MySQL .
 Purpose: Stores user and card data securely.
 Operations:
o Input: Stores new user and card data.
o Output: Retrieves user data based on RFID UID for verification.

SMTP Service (Email Notifications)

 Service: SMTP (e.g., SendGrid, Gmail).

 Purpose: Sends email notifications to users (e.g., authentication results).
 Integration: The Django backend triggers the email notifications based on
authentication events.

Encryption Libraries

 Purpose: Secure sensitive data such as user credentials and card information.
 Libraries: Django's built-in cryptography library for encryption, and C++ libraries for
secure communication between the microcontroller and backend.
 Data Flow: Encrypts sensitive data during transmission and storage in the database.

3.4 Communication interfaces

Communication Functions

 ESP32 to Backend: The ESP32 uses Wi-Fi to send HTTP requests over TCP/IP to the
backend. Data is sent in JSON format, and responses are secured with HTTPS.
 Backend to Database: The backend communicates with MySQL using SQL queries over
TCP/IP. Connections are encrypted with SSL/TLS.
 Backend to SMTP: SMTP is used to send email notifications (e.g., for two-factor
authentication). Emails are secured with TLS/SSL.

Security and Encryption

 HTTPS ensures encryption of communication between the ESP32 and the backend
server.

15
Software Requirements Specification for Document Access Control System

 SMTP emails use TLS/SSL for secure transmission. Email credentials are stored securely.
 SQL connections to the database are encrypted with SSL/TLS.

Data Transfer and Synchronization

 Data Transfer Rates: Wi-Fi connection allows sufficient transfer rates for small data
payloads (RFID UID).
 Synchronization: Communication is synchronous with defined timeouts for requests and
responses. Email notifications are sent after authentication.

16
Software Requirements Specification for Document Access Control System

4. System Features
4.1 User Registration and Document Upload

4.1.1 Description and Priority

This feature enables new users to register on the system and upload their identity documents
(Aadhaar and PAN). The system validates input data and stores uploads in the backend for
admin verification.
Priority: High
Priority Ratings:

 Benefit: 9 (onboarding users is critical)

 Penalty: 7 (blocks system use if missing)
 Cost: 3 (standard frontend/backend form handling)
 Risk: 3 (minimal risk with validation checks)

4.1.2 Stimulus/Response Sequences

 User Action: Opens registration page, fills personal details, and uploads Aadhaar and
PAN card images.
 System Response: Validates the inputs, stores the files in the server, and sets document
status to "Pending". Provides a confirmation on successful submission.

4.1.3 Functional Requirements

 REQ-1: The system shall allow users to register with a unique email ID and password.
 REQ-2: The system shall validate input fields such as name, mobile number, and email
format before accepting submissions.
 REQ-3: The system shall allow users to upload Aadhaar and PAN card files in .jpg, .jpeg,
or .png format.
 REQ-4: The system shall restrict file sizes to a maximum of 2MB.
 REQ-5: Upon successful submission, the system shall store the uploaded files securely
and mark their status as “Pending Review”.
 REQ-6: The system shall display a success message on the frontend and email a
confirmation to the user’s registered email address.

17
Software Requirements Specification for Document Access Control System

4.2 Admin Verification and Smartcard Assignment

4.2.1 Description and Priority

Admins verify uploaded documents and approve users. Approved users are assigned a
smartcard with encrypted data.
Priority: High

4.2.2 Stimulus/Response Sequences

 Admin logs into dashboard.

 Views pending uploads and reviews them.
 Approves or rejects the documents.
 If approved, user is assigned a smartcard with encrypted data.

4.2.3 Functional Requirements

 REQ-4: The system shall allow admins to approve or reject documents.

 REQ-5: Upon approval, documents shall be encrypted using AES-256.
 REQ-6: The encrypted documents shall be written to the assigned smartcard.

4.3 RFID Scan and Authentication

4.3.1 Description and Priority

Users scan their smartcard on the RFID reader. The system verifies card validity and initiates
two-factor authentication via email.
Priority: High

4.3.2 Stimulus/Response Sequences

 User places card on RFID reader.

 ESP32 reads UID and sends to backend.
 Backend verifies UID and sends verification email.

4.3.3 Functional Requirements

 REQ-7: The system shall read RFID UID using the RC522 reader.
 REQ-8: The system shall verify the UID against backend database records.

18
Software Requirements Specification for Document Access Control System

 REQ-9: Upon successful match, an email with a one-time verification link shall be sent.

4.4 Email Verification and Document Display

4.4.1 Description and Priority

Once email is verified, the user can view their decrypted documents temporarily.
Priority: Medium

4.4.2 Stimulus/Response Sequences

 User receives verification email.

 Clicks the link to confirm identity.
 System decrypts and displays Aadhaar and PAN cards.

4.4.3 Functional Requirements

 REQ-10: System shall send a secure, time-limited verification link.

 REQ-11: Upon verification, decrypted documents shall be shown on-screen.
 REQ-12: If the link is expired or invalid, user shall receive an error message.

4.5 Smartcard Write and Overwrite Handling

4.5.1 Description and Priority

This feature ensures smartcards cannot be overwritten once written unless explicitly reset by
the admin.
Priority: Medium

4.5.2 Stimulus/Response Sequences

 Admin attempts to assign a new user to an already issued smartcard.

 System detects previous data.
 System alerts admin to reset the card first.

4.5.3 Functional Requirements

 REQ-13: System shall detect if a smartcard already contains encrypted data.

 REQ-14: Admin shall be notified and prompted to reset card.

19
Software Requirements Specification for Document Access Control System

 REQ-15: Only admin users shall have permission to reset smartcards.

20
Software Requirements Specification for Document Access Control System

5. Other Nonfunctional Requirements

5.1 Performance Requirements

The system shall authenticate and respond to a scanned smartcard within 5 seconds under
typical network conditions. Verification email delivery shall occur within 10 seconds of backend
approval. These performance benchmarks are essential to ensure real-time responsiveness and
smooth operation under typical and peak usage scenarios, supporting both user satisfaction
and operational efficiency.

5.2 Safety Requirements

The system shall ensure that only encrypted documents are stored on smartcards, and no
decrypted document shall be stored permanently on any server or client device. In case of
unauthorized access attempts, the system shall trigger both visual and auditory alerts through
LED indicators and buzzers. These safety mechanisms aim to protect sensitive data and prevent
any misuse or exposure of confidential information, especially in environments with strict data
protection policies.

5.3 Security Requirements

All user data shall be encrypted using AES-256, with encryption handled either on the ESP32 .
Each smartcard shall be linked to a unique user ID and cannot be reused. All key operations
such as authentication and document access shall be logged with timestamps. Admin access
shall be secured using strong passwords and CAPTCHA. Email communications shall use
encrypted SMTP protocols like SMTPS . These measures ensure data security and privacy within
the ESP32-based system.

5.4 Software Quality Attributes

The system shall provide a clean and intuitive user interface to enhance usability for all user
types. It must maintain 99% uptime to ensure high availability and consistent access. The
microcontroller software shall be compatible with ESP32 and be adaptable to other similar
platforms to support portability. Source code shall be modular, well-documented, and follow
clean coding practices to support maintainability. Furthermore, the system architecture shall
support scalability to accommodate thousands of users across institutions without requiring
major redesigns, ensuring future growth and sustainability

21
Software Requirements Specification for Document Access Control System

5.5 Business Rules

One smartcard shall be issued per verified user, and card duplication or sharing shall not be
permitted. Only documents that have been approved by an admin shall be allowed to be
written to a smartcard, ensuring validation and quality control. In cases where applications are
rejected, users must re-upload corrected documents for re-evaluation. These rules ensure a
secure, controlled, and traceable process for document storage and user verification.

22
Software Requirements Specification for Document Access Control System

6. Other Requirements
6.1 Database Requirements

The system shall use a secure relational database (SQLite or MySQL) to store user credentials,
encrypted document paths, smartcard IDs, and access logs.

6.2 Internationalization Requirements

The initial version of the application shall support English.

Future iterations may consider multilingual support including Hindi and Marathi for regional
deployment.

6.3 Legal and Regulatory Requirements

All personally identifiable information (PII) shall be handled in compliance with the Information
Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or
Information) Rules, 2011 (India).

Email verifications and document storage must follow applicable data protection laws such as
the Indian Digital Personal Data Protection Act, 2023.

6.4 Reuse Objectives

The RFID reading and encryption modules shall be developed as reusable libraries for
integration in other identity verification projects.

Modular REST APIs will be designed to allow future services such as biometric login or
document expiry timers to reuse the backend framework.

23
Software Requirements Specification for Document Access Control System

Appendix A: Glossary
 AES (Advanced Encryption Standard): Symmetric encryption used to protect sensitive
data.
 API (Application Programming Interface): Enables communication between software
systems.
 Authentication: Verifies the identity of a user or system.
 Authorization: Grants access permissions to users.
 HTTP (HyperText Transfer Protocol): Protocol for web data transfer.
 PII (Personally Identifiable Information): Data that can identify an individual (e.g.,
name, email).
 RFID (Radio Frequency Identification): Uses radio waves for tracking or user
identification.
 SMTP (Simple Mail Transfer Protocol): Sends system-generated email alerts.
 UID (Unique Identifier): Unique code assigned to users, documents, or components.
 ACL (Access Control List): Defines user permissions for a resource.
 Encryption: Converts data into secure, unreadable form.
 RBAC (Role-Based Access Control): Access control based on user roles (e.g., admin,
viewer).

Appendix B: Analysis Models

1. Figure 2.3.1 Use Case Diagram for User Registration and Authentication
2. Figure 2.3.2 Sequece Diagram of Document Access via SmartCard

24
Software Requirements Specification for Document Access Control System

Appendix C: To Be Determined List

TBD-1: Selection of the cloud deployment provider (options include AWS, GCP, or Azure).

TBD-2: Decision on whether to include biometric verification in this release.

TBD-3: Scope of integration with the institutional Enterprise Resource Planning (ERP) system.

TBD-4: Languages to be supported in the multilingual user interface.

TBD-5: Inclusion of SMS verification as a secondary option for email verification

25