Experiment: 01

Aim: Prepare SRS document in line with the IEEE recommended standards.

Objective: To find Library Management System for Student Information System.

Description:

A Software Requirements Specification (SRS) is a comprehensive document that outlines

the functional and non-functional requirements of a software system. It serves as a blueprint
for software development by providing a detailed description of what the software should
do and how it should behave. The SRS document typically includes sections such as
introduction, scope, functional requirements, non-functional requirements, constraints,
assumptions, and glossary.

In the introduction section, the SRS provides an overview of the software system and its
purpose. The scope section defines the boundaries of the software system and describes the
features and functionalities it will include. The functional requirements section outlines
specific actions and behaviours that the software must support, such as user interactions and
system processes. The non-functional requirements section describes quality attributes such
as performance, security, reliability, usability, and scalability.

The goals of a Software Requirements Specification (SRS) document

1. Define System Scope: The SRS should clearly outline the scope of the software
project, evaluated for impact, and implemented in a controlled manner. including
what features will be included and what functionalities the system will offer. This
helps stakeholders understand the boundaries of the project.
2. Capture Requirements: One of the main goals of an SRS is to capture all functional
and non-functional requirements of the software system. This includes what the
system must do, how it should behave, and any constraints or limitations it must
adhere to.
3. Establish a Common Understanding: The SRS serves as a communication tool
between stakeholders, including clients, developers, testers, and project managers. It
helps ensure that all parties have a common understanding of the software's
objectives and functionalities.
4. Serve as a Basis for Development: The SRS provides developers with a detailed
blueprint for building the software system. It outlines the specific features,
functionalities, and behaviours that need to be implemented, guiding the
development process.
5. Facilitate Change Management: While the SRS aims to capture all requirements
upfront, it also provides a framework for managing changes throughout the software
development lifecycle. Changes can be documented

1
1. Introduction

The Library Management System (LMS) is a software application designed to streamline

the management of library resources, including books, journals, and multimedia materials.
It serves as a centralized platform for library staff to catalog, circulate, and manage library
items efficiently. This document outlines the functional and non-functional requirements of
the LMS to ensure its successful development and deployment.

2. Scope

The LMS will include modules for cataloging library items, managing borrower accounts,
circulation management, acquisitions, and administrative functions such as generating
reports and managing user accounts. It will be accessible to library staff with appropriate
role-based access controls.

3. Functional Requirements

3.1 Cataloging Module:

• Book Entry: Allow librarians to enter new books into the system, including
details such as title, author, ISBN, and category.
• Search and Retrieval: Enable users to search for library items based on
various criteria such as title, author, subject, or keyword.
• Classification and Tagging: Provide functionality to classify and tag library
items for easy organization and retrieval.
3.2 Circulation Module:

 Borrowing and Returning: Allow patrons to check out and return library
items.
 Renewals: Enable patrons to renew borrowed items if no holds exist and
renewal limits are not exceeded.
 Holds and Reservations: Allow patrons to place holds on items that are
currently checked out.
3.3. User Management Module:

 Patron Registration: Allow library staff to register new patrons and manage
their accounts.
o Account Management: Enable patrons to update their contact information,
view borrowing history, and manage holds.
3.4. Administrative Module:

 Reporting: Provide functionality to generate reports on library usage,

inventory status, overdue items, etc.

2
  User Permissions: Allow administrators to manage user roles and permissions
within the system.
4. Non-Functional Requirements

4.1. Performance:

 The system should support concurrent access by multiple users without significant
performance degradation.
 Response times for common operations such as searching and checkout should be
within acceptable limits.
4.2. Security:
 The system should enforce role-based access controls to ensure that users can only
access data and perform actions relevant to their roles.
 User authentication should be implemented using secure mechanisms such as
password hashing and session management.
4.3. Reliability:
 The system should have built-in mechanisms for data backup and recovery to
prevent data loss in case of system failures.
 It should be able to handle errors gracefully and provide meaningful error messages
to users.
4.4. Usability:
 The user interface should be intuitive and easy to navigate, with consistent layouts
and clear instructions.
 Help documentation and tooltips should be provided to assist users in performing
tasks and understanding system functionality.
4.5. Scalability:
The system architecture should be scalable to accommodate growth in the number
of library items, users, and transactions.
It should support horizontal scaling by adding more resources as needed.
1. Constraints:
 The system should be compatible with modern web browsers such as Chrome,
Firefox, and Safari.
 It should comply with relevant data protection regulations such as GDPR and
library confidentiality policies.
2. Assumptions:
 Users will have access to appropriate hardware and internet connectivity to use the
system.
 The system will be developed using a modern web application framework such as
Django or Laravel.
3. Glossary:
 LMS: Library Management System
 ISBN: International Standard Book Number
 GDPR: General Data Protection Regulation

3
This Software Requirements Specification provides a comprehensive overview of the
functionality, performance, security, and usability requirements for the Library
Management System. It serves as a guide for the development team to ensure that the
system meets the needs of its users and stakeholders.

Experiment: 02

Aim: Draw the use case diagram and specify the role of each of the actors. Also state the
precondition, post condition and function of each use case.

4
Objective: To draw the use case diagram for Student Information System.
Description:
A use case diagram is a graphical representation of the interactions between actors (users or
external systems) and a system under consideration. It illustrates the various ways in which
actors interact with the system to achieve specific goals or tasks. Here's a description of the
key components and concepts of a use case diagram:
1. Actors: Actors represent the different roles that interact with the system. They can be
users, external systems, or other entities that interact with the system. Actors are
typically depicted as stick figures or simple shapes
2. Use Cases: Use cases represent the specific functionalities or behaviours of the
system. Each use case describes a discrete task or function that the system performs
in response to an actor's request. Use cases are depicted as ovals or ellipses within
the diagram.
3. Relationships: Relationships between actors and use cases indicate the interactions
between them. The primary relationship in a use case diagram is the association
between actors and use cases, which represents the actor's involvement in the use
case. This association is typically depicted as a solid line connecting an actor to a
use case.
4. System Boundary: The system boundary defines the scope of the system being
modelled. It separates the system from its external environment and encapsulates all
the use cases and actors within the system. Actors: Actors represent the different
roles that interact with the system. They can be users, external systems, or other
entities that interact with the system. Actors are typically depicted as stick figures or
simple shapes.
5. Includes and Extends Relationships: In addition to basic associations, use case
diagrams can include more complex relationships such as includes and extends
relationships.
6. Includes: Indicates that one use case includes the functionality of another use case.
This relationship is depicted as a dashed arrow from the including use case to the
included use case.
7. Extends: Indicates that one use case extends another use case under certain
conditions or scenarios. This relationship is depicted as a dashed arrow from the
extending use case to the extended use case.
Use case diagrams provide a high-level overview of the system's functionality and the
interactions between actors and use cases. They are useful for stakeholders to understand
the system's requirements, scope, and behaviour, and they serve as a communication tool
between developers, designers, and clients throughout the software development process.

5
Library Management System (LMS) with the following actors:
1. Book Checkout:

 Actor: Patron
 Precondition: Patron is logged in and the desired book is available.
 Postcondition: Book is marked as checked out and becomes unavailable for
other patrons.
 Function: Allows patrons to borrow books from the library.
2. Book Return:
 Actor: Patron
 Precondition: Patron is logged in and has a book to return.
 Postcondition: Book is marked as returned and becomes available for other
patrons.
 Function: Enables patrons to return borrowed books to the library.
3. Book Search:
 Actor: Patron
 Precondition: Patron is logged in.
 Postcondition: Search results are displayed based on the search query.
 Function: Allows patrons to search for books by title, author, genre, or other
criteria.
4. Book Reservation:

6
  Actor: Patron
 Precondition: Patron is logged in and the desired book is currently checked
out.
 Postcondition: Patron is added to the waitlist for the reserved book.
 Function: Allows patrons to reserve books that are currently unavailable.
5. Book Inventory Management:
 Actor: Librarian
 Precondition: Librarian is logged in.
 Postcondition: Book inventory is updated based on actions performed.
 Function: Enables librarians to add new books, update book information,
and remove damaged or outdated books from the inventory.
6. User Account Management:
 Actor: Librarian
 Precondition: Librarian is logged in.
 Postcondition: User account information is updated or a new user is added.
 Function: Allows librarians to manage patron accounts, including
registration, updating contact information, and managing borrowing
privileges.
7. Book Reservation Management:
 Actor: Librarian
 Precondition: Librarian is logged in and there are reserved books.
 Postcondition: Reserved books are assigned to patrons based on the waitlist.
 Function: Enables librarians to manage book reservations, including
assigning reserved books to patrons and notifying patrons when reserved
books become available.

These use cases represent the core functionalities of a Library Management System,
detailing the actions performed by patrons and librarians, along with their respective
preconditions, postconditions, and functions within the system. Additional use cases may
include functionalities such as fine management, inter-library loan processing, and
reporting capabilities to comprehensively represent the system's capabilities and behaviors.