Software Requirement Specification

Library Management Project

Author
MR. Sanket A. Mevada

Affiliations

Address

Date
8 August, 2025

Versions
V0
 TABLE OF CONTENT

1. INTRODUCTION 3
1.1 PURPOSE 3
1.2 DOCUMENT CONVENTIONS 3
1.3 INTENDED AUDIENCE AND READING SUGGESTIONS 4
1.4 PROJECT SCOPE 4
1.5 REFERENCES 4
2. OVERALL DESCRIPTION 4
2.1 PRODUCT PERSPECTIVE 4
2.2 PRODUCT FEATURES 5
2.3 USER CLASS AND CHARACTERISTICS 7
2.4 OPERATING ENVIRONMENT 8
2.5 DESIGN AND IMPLEMENTATION CONSTRAINTS 8
2.6 ASSUMPTION DEPENDENCIES 8
3. SYSTEM FEATURES 9
3.1 DESCRIPTION AND PRIORITY 9
3.2 STIMULUS/RESPONSE SEQUENCES 9
3.3 FUNCTIONAL REQUIREMENTS 9
3.4 DISTRIBUTED DATABASE: 9
3.5 CLIENT/SERVER SYSTEM 10
4. EXTERNAL INTERFACE REQUIREMENTS 11
4.1 USER INTERFACES 11
4.2 HARDWARE INTERFACES 11
4.3 SOFTWARE INTERFACES 11
4.4 COMMUNICATION INTERFACES 11
5. NONFUNCTIONAL REQUIREMENTS 11
5.1 PERFORMANCE REQUIREMENTS 12
5.2 SAFETY REQUIREMENTS 13
5.3 SECURITY REQUIREMENTS 13
5.4 SOFTWARE QUALITY ATTRIBUTES 13
5.5 PRELIMINARY SCHEDULE 14
5.6 BUDGET 14

1. INTRODUCTION
1.1 PURPOSE

The purpose of this document is to build an online system to manage books, users, and transactions
in a library environment. This Library Management System aims to streamline the process of book
lending, returns, inventory tracking, and user registration.

1.2 DOCUMENT CONVENTIONS

This document uses the following conventions.

DB Database

DDB Distributed Database

ER Entity Relationship

LMS Library Mangement System

1.3 INTENDED AUDIENCE AND READING SUGGESTIONS

This project is a prototype for a Library Management System, developed for academic purposes
and initially deployed within college premises. However, the system is designed to be adaptable
for use in schools, public libraries, and other educational institutions. It has been implemented
under the guidance of college faculty. The intended audience includes library staff, students,
administrators, and developers interested in managing or accessing library resources.

1.4 PROJECT SCOPE

The purpose of the Library Management System is to simplify library operations and provide a
user-friendly platform for managing books, users, and transactions. The system supports core
functions like book lending, returns, inventory tracking, and user registration. While initially
designed for academic institutions, it can be adapted for use in schools, colleges, and public
libraries. The backend is built on a relational database to ensure reliable data storage and retrieval.
1.5 REFERENCES

● IEEE Software Engineering Standards – For structuring SRS documents and

following best practices in software documentation.

• MongoDB Documentation – Used for designing and implementing the backend

database for book and user management.

2. OVERALL DESCRIPTION

2.1 PRODUCT PERSPECTIVE

A distributed airline database system stores the following information.

● Book Details:
Includes book title, author, publication, ISBN, category, and availability status.
Tracks issued and returned books.
● User Description:
Stores user ID, name, role (student, teacher, librarian), contact details, and
borrowing history. Helps maintain accountability and communication.
● Transaction Records:
Logs book issue and return dates, due dates, fines (if any), and user interactions with the
system.

2.2 PRODUCT FEATURES

The major features of the Library Management System as shown in below entity–relationship
model (ER model)
The diagram shows the layout of Library Management System – entity–relationship model

2.3 USER CLASS AND CHARACTERISTICS

The Library Management System supports two primary user roles: Library Staff and
Students/Faculty Members. Each role has distinct privileges and access levels:

These users interact with the system to manage their personal library activities. They can:

• Search for books by title, author, or category

• Reserve or borrow available books
• View issued books and due dates
• Renew borrowed books (if eligible)
• Pay fines for overdue returns
• Submit feedback or book requests

Library Staff have access to both user-level and administrative functionalities They can:

• Register new users and issue library cards

• Add, update, or delete book records
 • Track inventory and availability
• Manage reservations and returns
• View user borrowing history
• Generate reports on book circulation, fines, and user activity

The system ensures that each book can be reserved by only one user at a time, and staff can monitor
due dates and overdue penalties. Authentication is handled via login credentials for staff, ensuring
secure access to administrative features.

2.4 OPERATING ENVIRONMENT

The Library Management System is designed to run in a typical academic IT setup. The operating
environment includes:

● Frontend: React.js for building dynamic and responsive user interfaces

● Backend: Node.js with Express.js for handling server-side logic and API routing
● Database: MongoDB for storing book, user, and transaction data in a flexible document
format
● Operating System: Compatible with Windows, Linux, and macOS environments
● Architecture: Client/Server model with RESTful API communication
● Hosting:

o Frontend deployed on platforms like Vercel or Netlify

o Backend hosted on services like Render, Railway, or Heroku

2.5 DESIGN AND IMPLEMENTATION CONSTRAINTS

1. The global schema, fragmentation schema, and allocation schema.

• Global Schema: Unified view with entities like Book, Reader, Staff, Report, etc.

• Fragmentation: Horizontal—e.g., Book by Category, Reader by Region.

• Allocation: Centralized—all fragments stored on one server (e.g., MongoDB Atlas).

2. SQL commands for the above queries/applications

 Ans : -- Reserved books by a reader
SELECT Book.title, Reserve.reserve_date
FROM Book JOIN Reserve ON Book.ISBN = Reserve.Book_no
WHERE Reserve.UserId = 'U123';

-- Overdue report
SELECT Report.UserId, Book.title
FROM Report JOIN Book ON Report.Book_no = Book.ISBN
WHERE Report.return_date > Report.due_date;

3. How will the response for applications 1 and 2 be generated? Assuming these are global
queries. Explain how various fragments will be combined to do so.
Ans: Global Query Response
• App 1: Join Reserve and Book by ISBN; filter by UserId.
• App 2: Join Report and Book; filter by overdue condition.
• All fragments combined locally in centralized DB.

4. Implement the database at least using a centralized database management system.

Ans : Centralized DBMS Implementation

• Use MongoDB or MySQL on a single server.
• Simplifies query handling, backups, and maintenance.

2.6 ASSUMPTION DEPENDENCIES

Let us assume that this is a distributed Library Management System and it is used in the following
feature:

• The system uses a centralized database for all operations.

• Book reservation/return is available to all registered users.
• If a book is unavailable, the system may suggest alternatives or waitlist options.
• Frequent readers are tracked based on borrow history.
• Reward points (optional) can be assigned for active borrowing and timely returns.
 • All operations are treated as single atomic transactions to ensure consistency.

3. SYSTEM FEATURES

3.1 DESCRIPTION AND PRIORITY

The Library Management System maintains records of books, readers, staff, publishers, reports,
and reservations. It supports book issue/return, user registration, and report generation. This
project has high priority as it streamlines library operations, reduces manual errors, and improves
user experience.

3.2 STIMULUS/RESPONSE SEQUENCES

• Search for Books :-

o Stimulus: User enters book details (title, author, or category) into the search bar.
o Response: The system displays a list of matching books along with their
availability status.

• Reserve or Issue Book :-

o Stimulus: User selects an available book and clicks the "Reserve" or "Issue"
button.
o Response: The system changes the book's status to "Reserved" or "On Loan,"
records the transaction, and shows a confirmation message.

• Cancel Reservation :-

o Stimulus: User selects a reserved book from their list and clicks the "Cancel"
button.
o Response: The system deletes the reservation record and changes the book's status
back to "Available," then displays a confirmation message.

3.3 FUNCTIONAL REQUIREMENTS

Other system features include:

• Search, reserve, issue, and return books

• Register readers and manage staff authentication

• Generate reports for issued/returned books

• Track due dates and calculate fines

• Categorize books by title, author, edition, and publisher

• Secure login system for staff

• Identify frequent readers and manage reward points (optional)

3.4 DISTRIBUTED DATABASE:

Distributed database implies that a single application should be able to operate transparently on
data that is spread across a variety of library branches and connected by a communication network
as shown in the below figure.

Distributed database located in four different cities

3.5 CLIENT/SERVER SYSTEM

Definition: Client/server refers to a logical architecture where the client is the front-end
application and the server is the backend DBMS. (also known as the back-end).
A client/server system is a distributed system in a Library Management System,

● Clients (e.g., staff or readers using browsers) send requests.

● Server (centralized database) processes and responds to those requests.
● All data resides on the server; all application logic runs on the client.

4. EXTERNAL INTERFACE REQUIREMENTS

4.1 USER INTERFACES

● Front-end Software: React.js (modern, responsive UI)

● Back-end Software: Node.js with Express.js (API and server logic)
● Database: MongoDB (document-based storage)
● Access: Web browser interface for staff and readers

4.2 HARDWARE INTERFACES

● Operating System: Compatible with Windows, Linux, and macOS.

● Browser Support: Any modern browser that supports HTML, CSS, JavaScript, and
RESTful API calls

4.3 SOFTWARE INTERFACES

Following are the software used for the Library Management online application.

Software used Description

Operating Cross-platform support: Windows, Linux, and macOS for

system development and deployment.

Database MongoDB Atlas or SQL(can also used) is used to store books,

users, staff, and transaction records

Frontend React.js for building dynamic and responsive user interfaces

 Backend Node.js with Express.js for handling server-side logic and RESTful
APIs

Deployment Vercel/Netlify (frontend), Render/Railway (backend), with

Tools optional CI/CD setup

4.4 COMMUNICATION INTERFACES

• The system supports all modern web browsers (Chrome, Firefox, Edge, etc.).
• Users interact through electronic forms for book reservation, issue, return, and feedback.
• Communication between frontend and backend is handled via RESTful APIs , secured
over HTTP or HTTPS protocols.

5. NONFUNCTIONAL REQUIREMENTS

5.1 PERFORMANCE REQUIREMENTS

The steps involved to perform the implementation of the Library Management are listed below.

A) E-R DIAGRAM

The Entity-Relationship (E-R) Diagram visually represents the logical structure of the Library
Management System database. It helps in organizing data into normalized relations and ultimately
designing a relational database.

● ENTITIES: These specify distinct real-world items in an application.

● PROPERTIES/ATTRIBUTES: These specify properties of an entity and relationships.
● RELATIONSHIPS: These connect entities and represent meaningful dependencies
between them.

the diagram shows the ER diagram of the Library Mangement the more detail one is in starting.

B) NORMALIZATION:
The basic objective of normalization is to reduce redundancy which means that information is to
be stored only once. Storing information several times leads to a wastage of storage space and an
increase in the total size of the data stored.

If a database is not properly designed it can give rise to modification anomalies. Modification
anomalies arise when data is added to, changed, or deleted from a database table. Similarly, in
traditional databases as well as improperly designed relational databases, data redundancy can be
a problem. These can be eliminated by normalizing a database.

Normalization is the process of breaking down a table into smaller tables. So that each table deals
with a single theme. There are three different kinds of modifications of anomalies and formulated
the first, second, and third normal forms (3NF) is considered sufficient for most practical purposes.
It should be considered only after a thorough analysis and complete understanding of its
implications.

5.2 SAFETY REQUIREMENTS

If there is extensive damage to a wide portion of the database due to catastrophic failure, such as
a disk crash, the recovery method restores a past copy of the database that was backed up to
archival storage (typically tape) and reconstructs a more current state by reapplying or redoing the
operations of committed transactions from the backed up log, up to the time of failure.

Backups will be scheduled daily, and transaction logs will be maintained in real-time to minimize
data loss. The system must ensure that no partial or uncommitted transactions are reapplied
during recovery to maintain data integrity.

5.3 SECURITY REQUIREMENTS

Given the importance of maintaining trust and integrity in academic environments , Like other data-
driven applications, the Library Management System relies heavily on secure database storage to
protect sensitive information such as user credentials, book records, and transaction logs.

5.4 SOFTWARE QUALITY ATTRIBUTES

● AVAILABILITY: The system must be accessible during institutional working hours and
support 24/7 access for students and faculty performing online book searches or
 reservations. Scheduled maintenance windows should be minimal and clearly
communicated.
● CORRECTNESS: The system must ensure accurate book records, user data, and
transaction logs. Issued books should reflect correct due dates, and search results must
match the query parameters precisely.
● MAINTAINABILITY: The application should be modular and well-documented to
support regular updates, bug fixes, and compatibility with evolving web technologies.
Codebase should follow industry-standard practices to ease future enhancements.
● USABILITY: The interface should be intuitive and responsive across devices (desktop,
tablet, mobile). Users should be able to search, reserve, and manage books with minimal
training. Accessibility standards (e.g., keyboard navigation, screen reader support) should
be considered.

5.5 PRELIMINARY SCHEDULE

Draw Gantt for tentative Schedule

5.6 COST ESTIMATION

Developer Hourly Rate

 ● Junior Developer: ₹300 – ₹800/hour
● Mid-Level Developer: ₹800 – ₹1,500/hour
● Senior Developer: ₹1,500 – ₹2,500/hour

Estimated Hours

● Analysis and Planning: 80-120 hours

● Database Design and Setup: 120-160 hours
● Backend Development: 240-400 hours
● Frontend Development: 160-320 hours
● Integration and APIs: 80-160 hours
● Testing and QA: 80-120 hours
● Deployment and Go-Live: 40-80 hours

Total Hours Estimate

● Total: 800-1360 hours

Total Cost Estimate

● Junior Developer: ₹24,000 – ₹96,000

● Mid-Level Developer: ₹96,000 – ₹240,000
● Senior Developer: ₹360,000 – ₹5,00,000

Additional Costs

● Project Management: 10-15% of development costs

● Design and UX/UI: Additional 10-15% if outsourced
● Infrastructure Costs: Hosting, database servers, and third-party services
● Maintenance: Ongoing costs for updates, bug fixes, and enhancements

Contingency

● Budget for Unexpected Costs: Typically 10-20% of the total project cost.