Software Requirements Specification

for

Library Management System

Version 1.0

Prepared by
Group Name: SCAR
Ashish Patel 23293916122 apashish889@gmail.com
Deepak Kumar 23293916112 deepaktomar1488@ce.du.ac.in

Instructor: Dr. Juhi Jain

Course: B.TECH CSE - B

Lab Section: B2

Date: 29 January 2025

Contents
CONTENTS ................................................................................................................................................................. I

REVISIONS ................................................................................................ ERROR! BOOKMARK NOT DEFINED.

1 INTRODUCTION ...............................................................................................................................................1
1.1 DOCUMENT PURPOSE ................................................................................................................................1

1.2 PRODUCT SCOPE .......................................................................................................................................1

1.3 INTENDED AUDIENCE AND DOCUMENT OVERVIEW....................................................................................1

1.4 DEFINITIONS, ACRONYMS AND ABBREVIATIONS ........................................................................................2

1.5 DOCUMENT CONVENTIONS ........................................................................................................................2

1.6 REFERENCES AND ACKNOWLEDGMENTS...................................................................................................2

2 OVERALL DESCRIPTION ..............................................................................................................................3

2.1 PRODUCT OVERVIEW .................................................................................................................................3
Software Requirements Specification for Library Management System Page ii

2.2 PRODUCT FUNCTIONALITY .........................................................................................................................3

2.3 DESIGN AND IMPLEMENTATION CONSTRAINTS ..........................................................................................3

2.4 ASSUMPTIONS AND DEPENDENCIES ..........................................................................................................4

3 SPECIFIC REQUIREMENTS ..........................................................................................................................6

3.1 EXTERNAL INTERFACE REQUIREMENTS ....................................................................................................6

3.2 FUNCTIONAL REQUIREMENTS ....................................................................................................................8

3.3 USE CASE MODEL .............................................................................. ERROR! BOOKMARK NOT DEFINED.

4 OTHER NON-FUNCTIONAL REQUIREMENTS ....................................................................................... 13

4.1 PERFORMANCE REQUIREMENTS .............................................................................................................. 13

4.2 SAFETY AND SECURITY REQUIREMENTS ................................................................................................. 13

4.3 SOFTWARE QUALITY ATTRIBUTES ........................................................................................................... 13

5 OTHER REQUIREMENTS ............................................................................................................................ 14

APPENDIX A – DATA DICTIONARY ................................................................................................................... 15

APPENDIX B - GROUP LOG .................................................................. ERROR! BOOKMARK NOT DEFINED.

Software Requirements Specification for <Project> Page 1

Introduction
This document provides a detailed software requirements specification (SRS) for the
Library Management System. It outlines the essential requirements for the development,
implementation, and operation of the system. The section will guide the reader through the
system's functionality, design considerations, and intended user interactions.
Document Purpose
This document serves as a detailed Software Requirements Specification (SRS) for the
development and implementation of the Library Management System. The primary objective of this
document is to define the functional and non-functional requirements for the system. These
requirements ensure that the LMS delivers the necessary features to manage library operations
efficiently, supports various user roles, and guarantees seamless interaction with other systems or
services. The SRS serves as the foundation for software developers, testers, and stakeholders,
guiding them throughout the development lifecycle and ensuring that the product meets the
expectations of all involved parties.

The LMS is expected to be scalable and adaptable, supporting multiple libraries with varying sizes
and workflows. This document will cover all aspects of the system, from user interface design and
database management to performance and security requirements. Additionally, the SRS will also
detail the use cases, data flow, and integration points with other systems, making it a
comprehensive reference for all stakeholders involved in the system's creation, deployment, and
future updates.

Product Scope
The Library Management System will cover a wide range of library management tasks, such as:

• Book Management: The system will allow for the easy cataloging, categorization, and
tracking of books. It will support the input of book details like title, author, ISBN, publisher,
and genre.

• Member Management: The system will handle member registration, profile maintenance,
and track the borrowing history of each user. This includes supporting different member
types (e.g., student, faculty, external users).

• Borrowing and Returning Books: The system will automate the process of book
checkouts and returns, with built-in features for tracking due dates, sending reminders, and
imposing fines for overdue books.

• Fine Calculation: The system will automatically calculate fines for late returns, providing
transparency and ensuring the timely return of borrowed books.
Software Requirements Specification for <Project> Page 2

• Search & Reservation: Members will be able to search for books by title, author, or genre
and reserve them for future checkout if unavailable.

• User Management: The system will allow different access levels, including librarian, staff,
and member roles, each with specific permissions and functionality.

Intended Audience and Document Overview

This document is intended for various stakeholders involved in the development and deployment of
the Library Management System, including but not limited to:
• Librarians: The primary users who will be responsible for managing and overseeing library
operations.
• Software Developers: The team responsible for the technical implementation and
development of the LMS based on the requirements outlined.
• Quality Assurance Testers: The individuals who will verify the functionality of the system,
ensuring it meets all the defined requirements.
• Stakeholders: This includes anyone with an interest in the successful implementation of
the system, such as educational institutions, library managers, and other relevant parties.
The document is structured to provide a clear understanding of the system's requirements,
breaking down the content into logical sections that cover the scope, functional specifications,
external interfaces, and other essential attributes of the system. It is expected to be used
throughout the development lifecycle and may be updated as needed to reflect any changes or
additions to the system.

Definitions, Acronyms and Abbreviations

• LMS – Library Management System

• RBAC – Role-Based Access Control

• ISBN – International Standard Book Number

• UI – User Interface

• API – Application Programming Interface

• RFID – Radio Frequency Identification

Document Conventions
In this document, we adhere to the following conventions:
Software Requirements Specification for <Project> Page 3

• Use Case diagrams are represented using UML notation for visual clarity.

• Functional requirements are labeled as FR-XX for easy reference.

• Non-functional requirements are labeled as NFR-XX to distinguish them from functional

requirements.

• System diagrams, such as flow charts and architecture diagrams, will be presented in
simplified, easy-to-understand formats.

References and Acknowledgments

This document has been developed with reference to several standards and best practices:

• IEEE 830-1998 Software Requirements Specification Standard

• Library Management Best Practices: Guidelines followed by libraries worldwide for

automation and management.

Overall Description
Product Overview
The LMS will be a **web-based application** accessible via desktop and mobile devices. It will
integrate with library databases, digital catalogs, and notification services.

Product Functionality
• Book Cataloging & Management

• Member Registration & Management

• Book Borrowing & Return Tracking

• Fine Management

• Search & Reservation

User Classes and Characteristics

The Library Management System will be used by several distinct user classes, each with specific
characteristics and access rights. These include:
• Librarians: The primary users who will have the highest level of access and control.
Librarians can manage book cataloging, member registration, borrowing transactions, fines,
and system settings. They can generate reports and perform administrative tasks.
o Characteristics: Detailed knowledge of library operations, tech-savvy, often working
with high transaction volumes.
• Members: These are the library users who can search for books, borrow and return items,
and check their borrowing history. Members are also responsible for paying fines.
Software Requirements Specification for <Project> Page 4

o Characteristics: May vary from students and faculty to general public users; basic
knowledge of how to interact with the system.
• Staff: Support personnel who assist with daily operations but don’t have full administrative
rights. They may help manage books, assist members, and process returns.
o Characteristics: Typically trained on the operational aspects but not as involved in
system configuration or higher-level management.
• External Systems: These could include external APIs or services like cataloging services,
barcode/RFID scanners, or external notification services. These systems interface with the
LMS but do not directly interact with users.

Operating Environment
The Library Management System will be a web-based application, ensuring accessibility across
multiple platforms. The operating environment will include:
• Hardware: The system will run on standard desktop and mobile devices with internet
access. Servers hosting the application will require high availability and robust database
management systems.
o Minimum system requirements for users:
▪ Desktop/laptop: 2 GHz processor, 4 GB RAM, 10 GB available disk space,
internet connection.
▪ Mobile devices: Android or iOS devices with up-to-date operating systems.
• Software:
o Operating Systems: Windows, macOS, and Linux for the server-side environment.
o Web Browsers: Modern browsers such as Google Chrome, Mozilla Firefox, Safari,
and Edge.
o Database: The system will use MySQL or PostgreSQL for managing the library
database.
o Web Frameworks: The front-end will utilize HTML5, CSS3, and JavaScript, with
React.js or Angular for a dynamic, user-friendly interface. The back-end will be
built with Node.js or Python (Django/Flask).

Design and Implementation Constraints

The development of the Library Management System must adhere to several constraints that may
affect design decisions:

• COMET Method: The system must follow the COMET (Component-Oriented Modeling,
Engineering, and Testing) method for software design, ensuring modular, maintainable,
and reusable components.

o Reference: COMET software design methodology for object-oriented design

[COMET Methodology Documentation].

• UML Modeling Language: The system's design will be represented using UML (Unified
Modeling Language) for visual modeling of its structure, behavior, and interactions.
Software Requirements Specification for <Project> Page 5

o Reference: UML modeling guidelines and standards.

• Database Constraints: The system must use MySQL/PostgreSQL as the database,

limiting the choice of features and scalability options depending on the database’s capacity
and configuration.

• Security: The system will follow best practices for secure data transmission and storage,
ensuring all sensitive data (e.g., user information, borrowing records) is encrypted.
Security protocols such as SSL/TLS will be implemented for communication.

• Integration with External Systems: The system must support integration with external
services, such as barcode/RFID scanners and notification services (email/SMS). The
library management system should be designed to easily integrate with future services or
other library databases.

• Technology Stack: The use of Node.js, React, and MySQL/PostgreSQL limits the
available frameworks and libraries, ensuring the development team follows industry-
standard practices for web applications.

Assumptions and Dependencies

Several assumptions have been made that could impact the design and functionality of the Library
Management System. These assumptions include:
• Assumed Access to Reliable Internet: It is assumed that users will have stable internet
access, as the system is web-based. If users experience connectivity issues, their access
to the system will be compromised.
• Availability of External APIs: The system assumes the availability and stability of any
external APIs (e.g., digital book catalog APIs) that may be integrated into the LMS for
enriched book data or additional services.
• User Technical Knowledge: It is assumed that users will have basic knowledge of how to
interact with a web-based system. While the system will be designed to be intuitive, minimal
user training will be required.
• Barcode/RFID Integration: The system assumes that the library will already have or be
willing to invest in barcode/RFID scanners for automated check-in and check-out
processes. If this hardware is not available, manual input may be required for book
transactions.
• Third-party Components: The project will use third-party libraries for specific
functionalities (such as email notifications or PDF generation). Any changes or
discontinuation of these components could affect the system’s functionality.
• Database Size and Growth: The design assumes the database will grow linearly with the
library’s size. If the library significantly increases in size or membership, additional database
optimizations or scaling strategies may be necessary.
Software Requirements Specification for <Project> Page 6

Specific Requirements
External Interface Requirements
User Interfaces
The User Interface (UI) of the Library Management System will be designed to ensure ease of use
and a seamless interaction experience for different user classes (Librarians, Members, and Staff).
The main UI will be a web-based interface that can be accessed via desktops, laptops, or mobile
devices, and will have the following logical characteristics:

• Book Management (Librarians): A clean, organized dashboard for managing book

records. Librarians will have options to add, edit, delete, and search books by various
filters like title, author, genre, and ISBN.

o Interaction: Using form fields to input book information, drop-down menus for
categories, and search bars for quick retrieval.

• Member Management (Librarians and Staff): Librarians will also be able to manage
member registrations, and view member profiles, borrowing histories, and fine details.

o Interaction: Members can fill out registration forms, while staff can view and
update member details with options to issue fines.

• Book Search & Reservation (Members): Members will have access to a search bar and
filter options to find books in the catalog and reserve them if unavailable.

o Interaction: Search options based on title, author, genre, or ISBN. Buttons to

initiate reservations or checkout.

• Borrowing & Returning Books: A clear interface for checking out and returning books.
For each borrowed item, the system will show due dates, and overdue status, and allow the
user to return the item.

o Interaction: Click to borrow or click to return with visual feedback indicating

success or error messages.

The interface layout will be designed to accommodate various screen sizes, making it responsive
on desktops, tablets, and smartphones. The user interaction will be primarily through buttons,
menus, and forms, with intuitive prompts to guide the user through each action.

Graphic description: For illustration, a sample dashboard screen will display:

• Navigation bar (Home, Books, Members, Transactions)

• Section for current book loans and overdue items

• Option to search or reserve books

Software Requirements Specification for <Project> Page 7

Hardware Interfaces
The Library Management System will interface with several hardware components for
automation, inventory tracking, and enhanced user experience. The main hardware components
involved include:

• Barcode Scanners: Used to scan book barcodes for easy check-in and check-out.

o Logical Characteristics: The software communicates with the scanner through a

basic read interface, where the barcode data is passed to the system for searching
the database and performing the transaction.

• RFID (Radio Frequency Identification) Scanners: For automated tracking and quicker
check-in/check-out processes.

o Logical Characteristics: Similar to barcode scanners, RFID scanners transmit data

when a tagged book is scanned. The system retrieves book data and updates the
status.

• Printers: Used for printing receipt slips for book transactions or fine details.

o Logical Characteristics: The software sends the transaction details or fine

information to a connected printer, which prints receipts for members or librarians.

• Workstations: Desktops or laptops used by librarians, staff, and members.

o Logical Characteristics: Communication occurs between the software running on

the workstations and the web application server.

• Mobile Devices: Used by members to browse the catalog and perform basic tasks.

o Logical Characteristics: The system will be mobile-responsive, and interactions

will be similar to desktop-based interactions, with simplified navigation for smaller
screens.

Software Interfaces
The Library Management System will interact with other software components for various
functionalities:
• Mobile App: The mobile app will allow members to search for books, view their borrowing
history, check due dates, and place book reservations.
o Communication: The app will send HTTP requests to the LMS server, which will
process the data and return responses (e.g., search results, transaction status).
• Email/SMS Notification Services: Used to send reminders about due dates, overdue
books, or fines.
Software Requirements Specification for <Project> Page 8

o Communication: The LMS will integrate with external APIs to trigger notifications
via email or SMS, based on the user's transaction or account status.
• External APIs for Book Data: These might include connections to digital book catalogs or
other library systems to pull book details automatically.
o Communication: The system will call APIs to fetch book details (e.g., book
descriptions, author information, cover images) and update the internal catalog.

Communications Interface
The Library Management System will support communication across various interfaces, ensuring
that all components work together seamlessly:
• Internal Communication: The system will use HTTP/HTTPS protocols for communication
between the client (web app) and the server.
• External Communication: External integrations, such as APIs for book cataloging and
notification services, will use standard RESTful API communication over HTTPS.
• Database Communication: The system will use SQL queries to communicate with the
MySQL/PostgreSQL database to store and retrieve information related to books,
members, transactions, and fines.
• Hardware Communication: Devices like barcode scanners, RFID scanners, and
printers will communicate with the system through local USB or Bluetooth connections,
depending on the specific hardware setup.

Functional Requirements
F1: Book Management
• The system shall allow librarians to add, update, and delete books in the catalog.

o The librarian can input details such as title, author, genre, ISBN, and publication
year.

o The system shall validate that all required fields are filled before a book record is
saved.

o The system shall ensure that ISBNs are unique and properly formatted.
F2: Member Management
• The system shall allow staff and librarians to register and update member profiles.

o Members must provide their name, contact information, membership type, and any
other required fields.
Software Requirements Specification for <Project> Page 9

o The system shall allow members to view and update their own profile information,
such as phone number or email address.

o The system shall assign unique member IDs to each new member upon
registration.
F3: Book Borrowing and Returning
• The system shall allow members to borrow books by scanning the book barcode or RFID
tag.

o The system shall display the book details (e.g., title, due date) after borrowing.

o The system shall allow members to return books and automatically update the
borrowing history.

o If a member has overdue books, the system shall display overdue warnings and
impose a fine based on the overdue duration.
F4: Book Search and Reservation
• The system shall allow members to search for books based on various filters such as
title, author, genre, or ISBN.

o Search results should display the book title, author, and availability status.

o The system shall allow members to reserve books that are currently unavailable,
and notify them when the book is available for pickup.
F5: Fine Calculation and Payment
• The system shall automatically calculate fines for overdue books based on the library’s fine
policy.

o The system shall display the total fine amount for overdue books in the member's
profile.

o The system shall allow members to pay fines via integrated payment systems (e.g.,
credit card, digital wallet).
F6: User Role Management
• The system shall allow for role-based access control (RBAC), meaning different users
(librarians, staff, members) will have access to different features.

o Librarians: Can add/edit/delete books, manage members, and generate reports.

o Staff: Can view and update member information but cannot delete books.

o Members: Can borrow/return books, reserve books, and view their borrowing
history.
F7: Report Generation
• The system shall allow librarians to generate reports on various aspects of library
operations, such as:

o Books borrowed per month

Software Requirements Specification for <Project> Page 10

o Most popular books

o Fine status

o The system shall allow export of reports in formats like PDF or CSV.
F8: Book Availability Notifications
• The system shall send email/SMS notifications to members when a reserved book is
available for pickup.

o The system shall automatically generate these notifications and send them to the
member's registered contact information.
F9: Library Database Backup
• The system shall automatically back up the library database at regular intervals to ensure
data integrity.

o Backups will include book records, member data, transaction history, and fine
information.

o The system shall allow administrators to restore data from a backup if needed.

Use Case #1 : Book Borrowing (U1)

• Author
XYZ
• Purpose
The purpose of this use case is to allow library members to borrow books from the library. It
ensures that the member can select a book, check its availability, and proceed with borrowing the
book. The use case also records the transaction in the system.
• Requirements Traceability
• FR-03: The system shall allow members to borrow and return books.
• FR-05: The system shall allow members to search and reserve books.
• Priority
High – This use case is critical for the core functionality of the system, as borrowing is one of the
main activities in a library.
• Preconditions
• The member must be logged into the system.
• The book must be available in the library (not checked out or reserved by another member).
• Postconditions
• The book's status is updated to "borrowed" in the catalog.
• The borrowing history of the member is updated.
• The due date for returning the book is recorded.
• Actors
• Primary Actor: Member
• Secondary Actor: Librarian (optional, for special cases like reserving restricted books)
• Extends
Software Requirements Specification for <Project> Page 11

• None
• Flow of Events
1. Basic Flow
1. The member searches for a book using the system’s search feature.
2. The system displays a list of books matching the search criteria.
3. The member selects the book they wish to borrow.
4. The system checks if the book is available for borrowing.
5. If the book is available, the system displays the book’s details and a "borrow" option.
6. The member clicks "borrow," and the system processes the transaction.
7. The system records the book as borrowed in the catalog and updates the member’s
borrowing history.
8. The system displays the due date for returning the book and confirms the
transaction to the member.
2. Alternative Flow
o If the book is unavailable:
1. The system notifies the member that the book is already checked out or
reserved.
2. The member is given the option to reserve the book for later borrowing.
3. Exceptions
o Member has overdue books:
1. If the member has overdue books, the system will not allow borrowing until
the fines are paid.
2. The member is notified of the overdue status, and they are prompted to clear
the fines.
o System fails to update book status:
1. If the system encounters an error while updating the book’s status, the
member is notified of the failure.
2. The librarian is alerted to resolve the issue manually.
• Includes
• U2: Search Book
• U5: Check Availability
• Notes/Issues
• Ensure that the system’s book availability check is real-time to avoid issues with concurrent
borrowing.
• The due date should consider library policies (e.g., different borrowing durations for
members based on membership type).

Use Case #2 : Member Registration (U2)

• Author
XYZ
• Purpose
The purpose of this use case is to allow new users to register and create a profile in the system. It
ensures that the system captures essential member information and assigns a unique member ID.
Software Requirements Specification for <Project> Page 12

• Requirements Traceability
• FR-02: The system shall allow members to register and maintain profiles.
• Priority
Medium – Registration is necessary for member interaction with the library system but can be done
before full system deployment.
• Preconditions
• The user must be on the registration page of the system.
• Postconditions
• A new member profile is created and stored in the database.
• The system assigns a unique member ID to the new user.
• Actors
• Primary Actor: New Member
• Secondary Actor: Librarian (optional, if manual registration is needed)
• Extends
• None
• Flow of Events
1. Basic Flow
1. The new member accesses the registration page.
2. The member fills in required fields: name, contact information, membership type,
etc.
3. The system validates the information (e.g., unique phone number, valid email).
4. The member submits the form.
5. The system creates the member profile and assigns a unique member ID.
6. The system confirms registration to the member and provides login credentials.
2. Alternative Flow
o Incomplete Information:
1. If the member fails to fill in required fields, the system displays an error
message and prompts for corrections.
3. Exceptions
o Duplicate Registration:
1. If the member tries to register with an existing email or phone number, the
system displays a warning and prevents registration.
o System Error During Registration:
1. If there is a technical issue, the system displays an error message and
suggests retrying.
• Includes
• U3: Member Profile Management
• Notes/Issues
• A confirmation email should be sent to the member after registration to verify their contact
information.
• Consider implementing CAPTCHA to avoid automated registrations.
Software Requirements Specification for <Project> Page 13

Other Non-functional Requirements

Performance Requirements
• P1: The system should be able to handle 500 concurrent users performing actions like
book searching, borrowing, and account management without noticeable degradation in
performance.

• P2: The system should return search results for books within 2 seconds for up to 100
books in the catalog. For more than 100 books, the search time should not exceed 5
seconds.

• P3: The member profile creation process should be completed within 5 seconds after form
submission for 95% of the registration requests.

• P4: The system must be able to calculate fines for overdue books in less than 1 second
after a member returns a book.

Rationale: These performance requirements aim to ensure the system's efficiency under load,
providing a smooth user experience even with a moderate number of concurrent users. They also
aim to reduce wait times for common actions such as search and registration.

Safety and Security Requirements

• S1: All sensitive user data (such as personal information and payment details) must be
encrypted using SSL/TLS protocols during transmission over the internet.

• S2: The system must implement two-factor authentication (2FA) for administrators and
librarians to enhance system security.

• S3: All passwords should be hashed and stored securely using industry-standard
algorithms (e.g., bcrypt).

• S4: The system should have an automatic session timeout after 15 minutes of inactivity
to protect user accounts from unauthorized access.

• S5: The system must comply with GDPR (General Data Protection Regulation) for data
privacy and protection, ensuring that personal data is not shared without consent.

• S6: The mobile app used for access must use encrypted connections to prevent
unauthorized access and ensure the integrity of the data transmitted.

Rationale: These requirements aim to protect user privacy and prevent unauthorized access to
sensitive information. Given the potential for sensitive user data (such as library usage and
personal information), a robust security model is necessary to ensure compliance with data
protection regulations and maintain trust.
Software Requirements Specification for <Project> Page 14

Software Quality Attributes

Reliability
• R1: The system should have a 99.9% uptime, with planned maintenance windows
communicated to users at least 48 hours in advance.
• R2: The system must automatically back up critical data (e.g., member information, book
catalog) daily to ensure data is not lost in case of system failures.
Rationale: A highly reliable system is essential for ensuring continuous access to library
resources. Regular backups will safeguard against data loss and minimize disruption to services in
case of failure.
Adaptability
•A1: The system should be designed in a modular way to allow for easy integration of new
functionalities (e.g., additional library services like digital media lending) without requiring
major redesigns.
• A2: The system should support easy adaptation to different library catalog formats (e.g.,
MARC, Dublin Core) and allow integration with future technologies (such as RFID or
advanced search algorithms).
Rationale: Libraries may need to adapt to new technologies, catalogs, or services. The system
must be flexible enough to accommodate future requirements without a complete overhaul.
Usability
•U1: The system should have an intuitive user interface that requires no more than 10
minutes of training for a new librarian to use the core features (e.g., adding books,
managing member profiles).
• U2: The mobile version of the system should be designed to be responsive, allowing users
to access library services from various devices (smartphones, tablets) with no significant
loss of functionality.
Rationale: A user-friendly design ensures that librarians and members can easily interact with the
system, minimizing learning time and errors.

Other Requirements
(Optional section)
• Database Requirements:
o The system should use a relational database (e.g., MySQL/PostgreSQL) for storing
structured data (e.g., book records, member profiles).
o The database must support ACID (Atomicity, Consistency, Isolation, Durability)
properties to ensure data integrity.
• Internationalization Requirements:
Software Requirements Specification for <Project> Page 15

o The system should support English as the primary language but be designed for easy
localization, allowing for future translations into other languages (e.g., Hindi, Spanish)
as required.
• Legal Requirements:
o The system must comply with local laws regarding data protection and user privacy
(e.g., GDPR for European users, CCPA for California-based users).
• Reuse Objectives:
o The system should be built using open-source technologies where possible to reduce
development costs and increase maintainability. Components like the authentication
system or book catalog could be reused in future projects or upgraded as needed.

Appendix A – Data Dictionary

A.1 Constants

Name Description Value Related Operations

The maximum number of books a Used when borrowing

MAX_BORROW_LIMIT 5
member can borrow at a time. books.

2 (in
Fine charged per day if a book is Applied when returning
LATE_FINE_PER_DAY currency
returned late. books late.
units)

The duration of inactivity before a Used to manage user

SESSION_TIMEOUT 15 minutes
user is logged out. session timeouts.

The maximum number of books that Used in search

MAX_BOOK_SEARCH 100
can be retrieved in a single search. functionality.
Software Requirements Specification for <Project> Page 16

A.2 State Variables

Name Description Possible States Related Operations

Available, Checked Updated during borrow,

Tracks the current status
bookStatus Out, Reserved, return, and reservation
of a book.
Overdue actions.

Tracks whether a user is Logged In, Logged Checked during user

userSessionStatus
logged in or logged out. Out authentication.

Tracks whether a Checked when returning

No Fine, Pending
fineStatus member has overdue books or updating member
Fine
fines. status.

A.3 Inputs

Name Description Data Type Related Operations

Member’s email address input Used in registration, login, and

userInputEmail String
during registration. email validation.

The unique identifier for a Used when borrowing, returning, or

bookID Integer/String
book in the library system. reserving books.

The unique identifier for a Used in member login, profile

memberID Integer/String
library member. management, and fines tracking.

The date when a member Used when calculating overdue

bookReturnDate Date
returns a book. fines and updating book status

A.4 Outputs

Data
Name Description Related Operations
Type

A message confirming a
Displayed after successful
confirmationMessage successful registration or String
registration or transaction.
operation.

A list of books returned from a List of Output of book search

bookSearchResults
search query. Books functionality.

The total fine a member must pay Calculated after returning

overdueFineAmount Decimal
for overdue books. books late.
Software Requirements Specification for <Project> Page 17

Data
Name Description Related Operations
Type

A message indicating whether

loginStatusMessage String Displayed after login attempt.
login was successful or not.

A.5 Related Operations

Operation Related Variables Description

Register Registers a new member by validating email,

userInputEmail, memberID
Member assigning a member ID.

Searches the library for books based on the user's

Search Book bookID, bookSearchResults
query.

Updates the status of a book to Checked Out and

Borrow Book bookID, bookStatus
assigns it to the user.

bookID, bookStatus, Marks the book as Available and calculates any

Return Book
bookReturnDate overdue fines.

fineStatus, Updates the user's fine status based on overdue

Apply Fine
overdueFineAmount books.

A.6 Functional Requirements Mapping to Data Dictionary

Functional Requirement Related Data Dictionary Items

FR-01: The system shall allow members to register and userInputEmail, memberID,
maintain profiles. confirmationMessage

FR-02: The system shall allow members to borrow and bookID, bookStatus, bookReturnDate,
return books. fineStatus

FR-03: The system shall calculate and apply fines for bookReturnDate, overdueFineAmount,
overdue books. fineStatus

FR-04: The system shall allow users to search for

bookID, bookSearchResults
books.
Software Requirements Specification for <Project> Page 18

THANK YOU.