Software Requirements Specification

for
Locker Prototype - Group 42 (webschool.au)

Version 1.0 approved

Prepared by William Bentley, Daniel Shekhtman, Peter Quan

Macquarie University.

02/04/2025

Table of Contents
Table of Contents...........................................................................................................................
ii

Revision History.............................................................................................................................
ii

1. Introduction............................................................................................................................. 1

1.1 Purpose.................................................................................................................................
1

1.2 Document Conventions..........................................................................................................

1

1.3 Intended Audience and Reading

Suggestions........................................................................... 1

1.4 Project Scope.........................................................................................................................

1

1.5 References.............................................................................................................................
1

2. Overall Description................................................................................................................. 2

2.1 Product Perspective................................................................................................................

2

2.2 Product Features....................................................................................................................

2

2.3 User Classes and

Characteristics............................................................................................. 2

2.4 Operating Environment..........................................................................................................

2

2.5 Design and Implementation

Constraints................................................................................... 2

2.6 User Documentation...............................................................................................................

2

2.7 Assumptions and

Dependencies.............................................................................................. 3

3. System Features.......................................................................................................................
3

3.1 System Feature 1....................................................................................................................

3
3.2 System Feature 2 (and so
on).................................................................................................. 4

4. External Interface Requirements........................................................................................... 4

4.1 User Interfaces.......................................................................................................................

4

4.2 Hardware Interfaces...............................................................................................................

4

4.3 Software Interfaces.................................................................................................................

4

4.4 Communications Interfaces.....................................................................................................

4

5. Other Nonfunctional Requirements...................................................................................... 5

5.1 Performance Requirements.....................................................................................................

5

5.2 Safety Requirements..............................................................................................................

5

5.3 Security Requirements............................................................................................................

5

5.4 Software Quality Attributes....................................................................................................

5

6. Other Requirements................................................................................................................
5

Appendix A: Glossary................................................................................................................... 5

Appendix B: Analysis Models...................................................................................................... 6

Appendix C: Issues List................................................................................................................ 6

Revision History

Name Date Reason For Changes Version

1. Introduction
1.1 Purpose
This Software Requirements Specification (SRS) document defines the functional and non-
functional requirements for the Smart Locker System to be developed for Webschool.au.
Currently, Webschool.au does not have a product that provides smart locker services. The goal
of this system is to introduce a secure, remotely accessible locker solution that can be
seamlessly integrated into Webschool.au’s existing web infrastructure.

The Smart Locker System will enable existing users of Webschool.au to remotely book,
access, and manage lockers through a web-based interface. The system will support user
authentication, booking management, access control, and real-time status updates to
ensure a smooth and reliable experience.

This SRS specifically covers the software requirements for the Smart Locker System, detailing
its expected functionalities, constraints, and integration needs. The document does not address
hardware specifications beyond their required software interfaces, nor does it define broader
Webschool.au platform changes unrelated to locker management.

1.2 Document Conventions

This project was assigned to us by Webschool.au. From here on out, Webschool.au will be
referred to as “the Sponsor”.

Bold to be used for key details.

1.3 Intended Audience and Reading Suggestions - DS

<Describe the different types of reader that the document is intended for, such as developers,
project managers, marketing staff, users, testers, and documentation writers. Describe what the
rest of this SRS contains and how it is organized. Suggest a sequence for reading the
document, beginning with the overview sections and proceeding through the sections that are
most pertinent to each reader type.>

The intention of this document is to provide a useful reference point for technical personnel and
project managers, working on the WebSchool web platform and the locker hardware project. It
is intended to provide an overview of the technical requirements for the entire locker project.
Section 1: “Introduction” should be relevant to all readers. Section 2: “Overall Description” and
Section 3: “System Features” provide a higher level overview most relevant to the project
management team. The remaining sections of the document provide a greater level of technical
depth that is aimed at the development and engineering team. The suggested reading order of
the document is sequential, omitting any sections that are not relevant to the nature of your role
in the project.

1.4 Project Scope

The Smart Locker System is a web-based solution designed to integrate with Webschool.au’s
existing platform, enabling users to remotely book, access, and manage smart lockers.
This system will provide a secure, convenient, and efficient way for users to store and
retrieve items, enhancing the overall service offerings of Webschool.au.

The primary objectives of the Smart Locker System include:

● Seamless Integration: The system will integrate with Webschool.au’s existing user
authentication and management framework, ensuring a unified experience for current
users.

● Remote Booking & Access: Users will be able to reserve lockers in advance through a
web interface, reducing wait times and optimizing locker availability.

● Security & Access Control: The software will implement robust authentication and
access mechanisms to ensure that only authorized users can access booked lockers.

● Real-time Status Updates: The system will provide live availability updates, ensuring
users can make informed decisions when booking lockers.

From a business perspective, this project aligns with Webschool.au’s strategy to expand its
service offerings and generate additional revenue streams. By introducing smart lockers,
Webschool.au can provide a value-added service to its customers, increasing user
engagement and satisfaction.

This document defines the software requirements for the initial release of the Smart Locker
System. Future iterations may include mobile app integration, advanced analytics, and
expanded locker functionalities based on user feedback and evolving business needs.

1.5 References
● Feasibility Study – Locker Prototype
Webschool.au Pty Ltd, Group 42
Version 02, 02/04/2025
Internal document detailing the problem statement, proposed solutions, and business
context for the Smart Locker System.
● Webschool.au Web Platform Documentation
Internal documentation for integration with the existing Webschool.au infrastructure,
including user authentication and room management systems.
 Location: Internal documentation repository – https://webschool.au/docs (access
restricted)
● Actix Web Framework Documentation
Version 4.10.2
Rust framework for building HTTP servers
URL: https://actix.rs/
● Diesel ORM Documentation
Version 1.4.8
Rust ORM and query builder for PostgreSQL
URL: https://diesel.rs/
● ACS Code of Professional Ethics
Australian Computer Society, March 2023
URL: https://www.acs.org.au/content/dam/acs/ACSimages/ethicsdiscipline/
CodeOfProfessionalEthics_Mar_2023.pdf

2. Overall Description
2.1 Product Perspective - DS/PQ
<Describe the context and origin of the product being specified in this SRS. For example, state
whether this product is a follow-on member of a product family, a replacement for certain
existing systems, or a new, self-contained product. If the SRS defines a component of a larger
system, relate the requirements of the larger system to the functionality of this software and
identify interfaces between the two. A simple diagram that shows the major components of the
overall system, subsystem interconnections, and external interfaces can be helpful.>

The WebSchool locker system represents an entirely new product branch for the company. It is
the first system to include dedicated hardware devices to be integrated into WebSchool. The
locker system will require an extension of the existing WebSchool backend API, as well as an
additional frontend component. Communication between these software elements and the
hardware attached to lockers in the field is facilitated via the Locker Management Controller,
hereafter referred to as the “LMC”. Each LMC will control several Locker Controllers (LC). Each
LC is attached to an individual locker door. See the following diagram:

2.2 Product Features

<Summarize the major features the product contains or the significant functions that it performs
or lets the user perform. Details will be provided in Section 3, so only a high level summary is
needed here. Organize the functions to make them understandable to any reader of the SRS. A
picture of the major groups of related requirements and how they relate, such as a top level data
flow diagram or a class diagram, is often effective.>

2.3 User Classes and Characteristics

<Identify the various user classes that you anticipate will use this product. User classes may be
differentiated based on frequency of use, subset of product functions used, technical expertise,
security or privilege levels, educational level, or experience. Describe the pertinent
characteristics of each user class. Certain requirements may pertain only to certain user
classes. Distinguish the favored user classes from those who are less important to satisfy.>

2.4 Operating Environment

Hardware

Recycled TV boxes (X96 Max+ Ultra) - acting as the Locker Management Controller.

ESP32s - Will be used for smaller and more versatile locker controllers. Wirelessly connected to
the Locker Management Controller.

USB relay boards - will be used to additionally control the locks (to unlock / lock the lockers).
Plugged into the Locker management controller via USB.

GPIO relay boards - same as the usb ports. Connected to the ESP32s via GPIO header.

NFC reader - managed by both ESP32s and TV boxes.

Software / OS

Debian 12 - Used for the Locker controller.

Front end (web) - Existing website: webschool.au

Actix: HTTP server, network communication

Diesel: Query manager - for database

PostgreSQL: Database

Rust: Programming language for all tasks.

2.5 Design and Implementation Constraints

The following constraints have been identified for the design and implementation of the Smart
Locker System:
 ● Mandated Technologies:

○ Backend and firmware development must be done in Rust, as specified by the

Sponsor.
○ The system must use Actix Web for the HTTP server, Diesel for ORM/database
interaction, and PostgreSQL as the database.
○ Deployment must utilize Docker containers for portability and consistency across
environments.

● Hardware Constraints:
○ Limited to existing hardware supplied by the Sponsor: ESP32 microcontrollers,
Linux-based TV boxes (X96 Max+ Ultra), USB and GPIO relay boards, and
NFC readers.
○ Each ESP32 must operate within memory and processing limitations typical of
embedded microcontrollers.
● Integration Requirements:
○ The system must integrate with Webschool.au’s current web platform,
including the existing login system and room/building data models.
○ User accounts and locker assignments are tied to existing UUIDs already used
in the Webschool.au ecosystem.
● Security & Compliance:
○ All communications must use HTTPS with secure encryption (TLS 1.2+).
○ JWT tokens with RS256 signatures are required for all authentication and data
exchanges.
● Prototype Scope:

○ The current phase is a prototype/MVP, meaning performance tuning and large-

scale scalability are not priorities at this stage.

○ Final hardware form factor and optimized performance will be addressed in future
iterations.

2.6 User Documentation

All user documentation will use a combination of the site’s - webschool.au - help documentation,
as well as new help documentation. To be placed in the same location.

There are also a collection of videos / tutorials available on the website.

2.7 Assumptions and Dependencies - DS

<List any assumed factors (as opposed to known facts) that could affect the requirements
stated in the SRS. These could include third-party or commercial components that you plan to
use, issues around the development or operating environment, or constraints. The project could
be affected if these assumptions are incorrect, are not shared, or change. Also identify any
dependencies the project has on external factors, such as software components that you intend
to reuse from another project, unless they are already documented elsewhere (for example, in
the vision and scope document or the project plan).>
The use of the Rust programming language for embedded firmware development on the ESP32
platform, as requested by the client, is still fairly new to the industry. The existing HAL libraries
(Hardware Abstraction Layer) are provided by a mix of the hardware manufacturer (Espressif)
as well as open-source community support. These libraries, which are critical to the success of
the project, remain in Beta testing as of February 2025 and certain features within them may be
incomplete, untested or missing. Currently, to reduce development time and to ensure better
support for a local HTTP stack on the ESP32, we are planning to use the community HAL which
supports the Rust standard library. Despite these advantages, the development of this HAL is
currently primarily driven by the community, with more limited support provided by Espressif.

Although the hardware and software development are scheduled to proceed concurrently, any
significant delays or changes to one may ultimately result in delays to the other. Hardware is
slower to iterate or change, when problems may become apparent. It is possible that there are
unforeseen interdependencies or relationships between hardware and software elements of the
project, particularly around the development of lower level code, such as drivers for the various
external accessories/peripherals. At this time, the team has not yet had an opportunity to review
all documentation for the various hardware components mandated by the client. Additionally,
currently no NFC reader has been identified or selected for the ESP32.

3. System Features
3.1 NFC Locker Unlock - DS
3.1.1 Description and Priority

<Provide a short description of the feature and indicate whether it is of High, Medium, or Low
priority. You could also include specific priority component ratings, such as benefit, penalty,
cost, and risk (each rated on a relative scale from a low of 1 to a high of 9).>

Successful reading of user ID token from NFC card, when card is applied to NFC reader.
Comparison of read ID token from NFC card with corresponding JWT token fetched from
backend API. Authentication check to ensure card token matches token of assigned locker
user. Corresponding activation or deactivation of door lock solenoid, if token is matching.
Priority: HIGH

3.1.2 Stimulus/Response Sequences

<List the sequences of user actions and system responses that stimulate the behavior defined
for this feature. These will correspond to the dialog elements associated with use cases.>

When the user taps their corresponding NFC card on the reader, the door lock solenoid shall be
actuated to change state, i.e. from unlocked to locked, or from locked to unlocked.

3.1.3 Functional Requirements

<Itemize the detailed functional requirements associated with this feature. These are the
software capabilities that must be present in order for the user to carry out the services provided
by the feature, or to execute the use case. Include how the product should respond to
anticipated error conditions or invalid inputs. Requirements should be concise, complete,
unambiguous, verifiable, and necessary. Use “TBD” as a placeholder to indicate when
necessary information is not yet available.>

<Each requirement should be uniquely identified with a sequence number or a meaningful tag of
some kind.>

REQ-1: Driver for serial communication with NFC reader

REQ-2: Solenoid control circuit

REQ-3: Solenoid GPIO driver

REQ-4: JWT token authentication module

Possible Invalid Inputs:

● User taps incorrect alternate card onto reader, instead of their own assigned locker card:

Do not actuate solenoid, display appropriate error message on local display.

● User taps blank, unprogrammed card onto reader:

Do not actuate solenoid, display appropriate error message on local display.

3.2 Database Synchronisation - DS

3.2.1 Description and Priority

<Provide a short description of the feature and indicate whether it is of High, Medium, or Low
priority. You could also include specific priority component ratings, such as benefit, penalty,
cost, and risk (each rated on a relative scale from a low of 1 to a high of 9).>

In the event of a loss of internet connectivity at the customer site, it is important that lockers
remain accessible to staff/students. However, authentication of user cards against lockers must
still be maintained for security, even without access to the WebSchool remote database. The
LMC should keep a reduced local database copy of user IDs and their corresponding tokens,
for all LC’s under its direct management. To remain current, this local database must be
synchronised on a 10min interval with the remote WebSchool database, when it is available.
Priority: MED

3.2.2 Stimulus/Response Sequences

<List the sequences of user actions and system responses that stimulate the behavior defined
for this feature. These will correspond to the dialog elements associated with use cases.>

As this feature amounts to a background backup process, there are no additional user actions
that stimulate the behavior defined for this feature. This feature is tested by ensuring that users
can still lock and unlock their locker as normal, when the internet connection of the LMC is
deliberately disabled.

3.2.3 Functional Requirements

<Itemize the detailed functional requirements associated with this feature. These are the
software capabilities that must be present in order for the user to carry out the services provided
by the feature, or to execute the use case. Include how the product should respond to
anticipated error conditions or invalid inputs. Requirements should be concise, complete,
unambiguous, verifiable, and necessary. Use “TBD” as a placeholder to indicate when
necessary information is not yet available.>

<Each requirement should be uniquely identified with a sequence number or a meaningful tag of
some kind.>

REQ-5: LMC local database synchronisation module

Possible Invalid Inputs:

Not Applicable

3.3 Locker Displays - DS

3.3.1 Description and Priority

<Provide a short description of the feature and indicate whether it is of High, Medium, or Low
priority. You could also include specific priority component ratings, such as benefit, penalty,
cost, and risk (each rated on a relative scale from a low of 1 to a high of 9).>

A local user interface should be implemented for both LC and LMC units, to identify the owner
of each locker, to display lock/unlock status messages as well as any error codes. On the LC,
the display is a small LCD screen mounted to the front of the locker door, which can be
updated/controlled via an I2C interface. On the LMC, the display is a larger LCD panel
controlled via HDMI, that may be mounted to the wall. The larger display shows the locker
status and owner information for all lockers under the LMC’s control. Priority: LOW

3.3.2 Stimulus/Response Sequences

<List the sequences of user actions and system responses that stimulate the behavior defined
for this feature. These will correspond to the dialog elements associated with use cases.>

When the system is idle and there is no user interaction, if the display is on, it will display the
locker owner name by default.

Tapping a blank, unprogrammed card or the incorrect card for a particular locker will trigger a
display of the corresponding error message.

Tapping the correct card for a given locker will result in an acknowledgement message and the
status of the locker being updated.

3.3.3 Functional Requirements

<Itemize the detailed functional requirements associated with this feature. These are the
software capabilities that must be present in order for the user to carry out the services provided
by the feature, or to execute the use case. Include how the product should respond to
anticipated error conditions or invalid inputs. Requirements should be concise, complete,
unambiguous, verifiable, and necessary. Use “TBD” as a placeholder to indicate when
necessary information is not yet available.>

<Each requirement should be uniquely identified with a sequence number or a meaningful tag of
some kind.>

REQ-1: Driver for serial communication with NFC reader

REQ-4: JWT token authentication module

REQ-6: I2C Display Driver

REQ-7: Large Display UI Module

Possible Invalid Inputs:

Not Applicable

4. External Interface Requirements

4.1 User Interfaces
The Smart Locker System will integrate seamlessly with Webschool.au’s existing website,
leveraging its current authentication and user management infrastructure.

Key UI Components

1. Login & Authentication

○ Utilises Webschool.au’s existing login system
○ Users authenticate with their existing credentials, mapped to their UUIDs
○ Session-based authentication to maintain security and user continuity
2. Locker Booking Dashboard
○ Extends the existing "Rooms" concept by adding a locker booking module
○ Displays available lockers in a grid or list view, showing real-time status
○ Filter and search functions based on locker size, location, and availability
○ "Book Now" button for instant reservations
3. Locker Access & Management
○ Access cards already exist.
○ Displays current and past bookings, with options to extend or cancel
reservations
○ Notifications for upcoming expirations or locker access issues
4. Administrator & Maintenance Panel
○ Allows admins to monitor locker usage, manage bookings, and perform
maintenance actions
 ○ Provides system alerts for faulty or unavailable lockers

○ Logs and analytics to track usage trends

5. Standard UI Elements
○ Consistent header and navigation menu aligned with Webschool.au’s design
standards
○ "Help & Support" section with FAQs and troubleshooting guidance
○ Error Handling: User-friendly messages for login failures, unavailable lockers,
and access errors

Since the UI is built on existing website infrastructure, it will maintain a cohesive look and feel.

4.2 Hardware Interfaces - DS

<Describe the logical and physical characteristics of each interface between the software
product and the hardware components of the system. This may include the supported device
types, the nature of the data and control interactions between the software and the hardware,
and communication protocols to be used.>

The principle hardware components of the system are:

1. The locker controller (LC), assigned to each locker door.

2. The locker management controller (LMC), assigned to a group of several lockers.

Each locker controller (LC) is implemented on a custom circuit board, powered by an ESP32 S3
microcontroller, which runs the firmware. The LC has several interfaces to other external
components of the system:

● Control over the door solenoid is established via 3.3V GPIO logic, which activates an
optocoupler, controlling a 12V relay.
● Communication between the LC and the LCD display on the door is facilitated via an I2C
bus.
● Communication to the LC is established via a Wi-Fi connection. The LC uses the HTTP
protocol, to make requests and receive data from the LMC.
● Communication to the NFC reader occurs via a standard 9600 baud, 8N1, serial data
connection at TTL logic levels, using a UART peripheral onboard the ESP32.

The locker management controller (LMC) hardware consists of a small form-factor embedded
Linux PC “X96 Max+ Ultra”. The LMC application code runs on this hardware. The LMC has
several interfaces to other external components of the system:

● Connection to the WebSchool backend API is facilitated via a Wi-Fi link, using HTTP
requests.
● Communication with LC units is similarly facilitated via Wi-Fi, using HTTP requests.
● The LMC also features a NFC reader, for school staff and administrators to use.
Communication with the NFC reader occurs via a standard 9600 baud, 8N1, USB-serial
connection. A COM port will be hosted on the PC automatically, for the LMC application
to communicate with the NFC reader.
 ● A larger external display may be connected to the LMC, via a HDMI bus. The LMC
application code uses this display to show the status and assignments of the group of
lockers under its control.

4.3 Software Interfaces

Front end (web)

Starting with the user interface, the front described earlier will connect to the locker controllers
via a web connection - HTTP.

HTTP Server - Actix

Actix will be a library that is used to create the HTTP server. The rust library will act as the main
communication point between the front end web server and the rest of the project.

The specific Actix version: “4.10.2”.

Actix will send all related database information from the web server to the rust project - eg. user
id, locker reserved.

Reference: https://actix.rs/

ORM and Query Builder (Database access)

Diesel will be used to access and manage the database. This rust library will act as the bridge
between the web server and the database.

The specific version of Diesel: “1.4.8”.

Reference: https://diesel.rs/

Database - PostgreSQL

The database, PostegreSQL will be the database accessed by Diesel.

Data stored: eg. user id, locker reserved.

Containerisation - Docker

The PostgresSQL database will sit inside of a Docker container.

Host OSE - Locker Controller

Debian 12 will be the OS that will sit directly on the controller hardware (tv box).
The main rust program will run here as well as the docker engine.

This OS will manage the USB relay boards.

As well as provide the wireless communications for the ESP32s.

Components will be tied together with Cron jobs and services, to ensure appropriate execution
of all parts.

Rust Backend

The main code of the backend. This will join all components above together.

Rust version: 1.85.0

Cargo

The tool used to build the Rust project. Also version: 1.85.0

4.4 Communications Interfaces - WB/DS

<Describe the requirements associated with any communications functions required by this
product, including e-mail, web browser, network server communications protocols, electronic
forms, and so on. Define any pertinent message formatting. Identify any communication
standards that will be used, such as FTP or HTTP. Specify any communication security or
encryption issues, data transfer rates, and synchronization mechanisms.>

The backend API is hosted on a remote web server. Communication from both the LC-LMC
units and from the LMC-API will rely on Wi-Fi links. HTTP will serve as the primary
communication protocol to be used across these links. Embedded software onboard each
device will use a sequence of GET and POST requests to exchange data with the remote
endpoint. User authentication from each endpoint with the server will rely on JWT tokens,
utilising RS256 signatures for security.

LC units will additionally rely on a I2C interface to control their local displays, mounted on each
locker door.

Both LC and LMC units will establish a serial data connection to their respective NFC readers,
at a 9600 baud rate, using a 8N1 data word. Flow control will be handled in software
(XON/XOFF scheme). The LMC accepts a serial connection on a virtual COM port, through a
USB interface. On the LC unit, the serial connection is managed by a UART peripheral.

5. Other Nonfunctional Requirements

5.1 Performance Requirements
As this is an MVP (Minimum Viable Product) solution, performance is not a primary
concern at this stage. The focus is on functionality and integration rather than optimisation.

However, the system should still meet basic performance expectations to ensure a smooth
user experience, particularly in the following areas:

● Response Time:

○ UI interactions (e.g., booking a locker, retrieving access credentials) should

complete within 2 seconds under normal network conditions.

○ Locker status updates should be refreshed in real time or within 5 seconds of

a state change.

● Concurrent Users:

○ The system should support at least 100 concurrent users without significant
degradation.

○ This number can be scaled based on demand and future hardware

considerations.

● System Availability:

○ Expected uptime of 99% or higher, excluding scheduled maintenance.

Future performance enhancements can be made once hardware specifications are finalised,
allowing for better scaling, faster response times, and improved concurrency handling as
needed.

5.2 Safety Requirements - DS

<Specify those requirements that are concerned with possible loss, damage, or harm that could
result from the use of the product. Define any safeguards or actions that must be taken, as well
as actions that must be prevented. Refer to any external policies or regulations that state safety
issues that affect the product’s design or use. Define any safety certifications that must be
satisfied.>

The locker door solenoid is actuated from a 12VDC power line, using a standard low voltage
SPDT relay. The rest of the LC unit hardware is powered from a 3.3VDC and 5VDC power rail.
In the event of an unexpected electrical isolation failure across the relay, it is possible that the
higher 12V rail becomes electrically connected to the rest of the LC unit internal circuitry. This
would likely lead to complete, irrecoverable electrical failure of the LC unit. In order to minimise
damage to the LC unit from this failure mode, an opto-coupler will be used to electrically isolate
control of the 12V relay, from the rest of the internal circuitry. This will improve the safety and
reliability of the LC unit. A damaged relay can then be desoldered and replaced, allowing the LC
unit to be put back into service. This also reduces the possibility of electrical sparking occurring
inside of an enclosed locker, were such a fault to ever occur.
5.3 Security Requirements
The Smart Locker System will inherit and extend Webschool.au’s existing security practices to
ensure data protection, user privacy, and secure transactions.

Authentication & Access Control

● User Authentication:

○ The system will use Webschool.au’s existing login system with UUID-based
user identification.

○ Session management will include timeouts and token-based authentication to

prevent unauthorized access.

● Locker Access Security:

○ Secure NFC-based authentication will be used to grant access to booked

lockers.

○ Access credentials will be time-sensitive and expire after use or at the end of
the booking period.

○ Failed access attempts will be logged and trigger security notifications after a
predefined threshold.

Data Encryption & Communication Security

● All HTTP traffic will be encrypted over HTTPS using TLS 1.2 or higher.

● User credentials and locker access data will be stored using industry-standard
encryption methods.

● Sensitive data, such as access logs and booking history, will be stored securely and
access-restricted based on user roles.

5.4 Software Quality Attributes

Usability: The UI will be intuitive and familiar, built on Webschool.au’s existing design patterns,
requiring minimal training.
Reliability & Robustness: The system targets 99% uptime, with offline fallback support via
local cache to ensure continuous locker access.

Maintainability: Modular design and Git-based version control will make it easy to update,
debug, and extend the system.
Interoperability: Uses standard HTTP APIs and integrates directly with Webschool.au’s
infrastructure (user auth, database, frontend).

Portability & Flexibility: Backend containerized with Docker; supports both ESP32 and Linux-
based controllers for varied deployments.

Security: Secure against improper access, with encrypted communication and graceful
degradation during failures.

6. Other Requirements
<Define any other requirements not covered elsewhere in the SRS. This might include database
requirements, internationalization requirements, legal requirements, reuse objectives for the
project, and so on. Add any new sections that are pertinent to the project.>

Appendix A: Glossary

<Define all the terms necessary to properly interpret the SRS, including acronyms and
abbreviations. You may wish to build a separate glossary that spans multiple projects or the
entire organization, and just include terms specific to a single project in each SRS.>

LC - Locker Controller

A small single PCB to be placed inside of each locker, powered by an ESP32 microcontroller.
Contains all required circuitry to read from an NFC sensor and activate the door latch solenoid.
Interfaces with a small external display, located on the outside of each locker door.

LMC - Locker Management Controller

A small form factor PC running Linux, responsible for control/management over a group of LC’s
(Locker Controllers). Acts as an interface between multiple LC’s and the WebSchool backend
API for this project.

Appendix B: Analysis Models

<Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams,
state-transition diagrams, or entity-relationship diagrams.>

Appendix C: Issues List

< This is a dynamic list of the open requirements issues that remain to be resolved, including
TBDs, pending decisions, information that is needed, conflicts awaiting resolution, and the like.>

Hardware Kit Distribution

A kit of hardware devices has been arranged for the development and engineering team, to
assist them in deploying and testing their code in a relevant hardware environment, similar to
the final product. Currently, not all team members have had an opportunity to collect or receive
their hardware kit. The team is currently working on ensuring that each of its members has
received the relevant hardware resources that they need to complete their portion of the project.
Conflicting schedules between team members has delayed this process but it is expected that
all members of the team will have received their hardware kit by the 6th of April, 2025.