PROBLEM STATEMENT

The aim is to develop software for automating the college library. The system
should be standalone in nature. It should have a friendly User Interface and
should be designed with focus on security.

The required functionalities from the system are:

1. Issue of Books
(a) A member student of any course should be able to issue books. A
student can issue upto four books.
(b) A students book can be issued for a maximum of 2 weeks (14 days).
(c) The software takes the current date as the date of issue and
calculates the corresponding date of return.
(d) A barcode detector is used to save the student information as well as
book information.
(e) The due date for return of the book is stamped on the book.

2. Return of Books
(a) Any person can return the issued books.
(b) The student information is displayed using the bar code detector.
(c) The system displays the issuing students details, date of issue and
due date.
(d) The system compares the date of return with the due date. If the
book is being returned after due date, a fine of `5 is charged for each
day.
Printed slip for every fine levied should be generated.
(e) The information is saved and corresponding updations take place in
the database.
3. Query Processing
(a) The system should provide catalogue searching and provide
information like:
(i) Availability of a particular book.
(ii) Availability of books of any particular author.
(iii) Number of copies available of the desired book. If not available,
when is the expected date of availability of book.
(b) Substrings should be allowed.
(c) Real time searching to be present.

4. Security
(a) Entire System is password protected. Different people have different
levels of authenticity. The Librarian is at the highest level.

5. Login
(a) Each user should have a user id and a password.
(b) The account is to be verified and the user is to be redirected to his
account.
(c) The user then should be able to check the number and name of books
issued by him, their due dates and history of his account activities.
(d) The user should be able to logout whenever he/she wishes to.

Provision should be made for full backup of the system.

CONTEXT DIAGRAM

4lerk
Librarian
Student info
entry 2anage books

Issue/return

LI0RAR1
2ANA3E2ENT
S1STE2

5uery Login
resolution provided

Students
0ooks database is Reports
updated generated
LEVEL-1 DFD

Enter 2embers info

Seek membership
2embership info
details 2embership
management
0arcode
Seek membership 2embers info
reader
Read members details
Student Request for book

0ooks issue
Issue book 0ook issue
management

Return book
Implement fine

2anage
0ooks books
4lerk
management
Enter
user
id,pass6
word Enter user 7ine 4lerk
id,password Issue/
return
book
0ooks info

Request for report

Login Libarian
7ine Report
Send report
Enter user details management
id,password

0ooks info
Send details
LEVEL-2 DFDs

1. Login
2. Membership management
3. Books management
4. Books issue management
5. Report Management
USE CASE DIAGRAM
USE CASE DESCRIPTION
1. LOGIN

1.1 Introduction
This use case documents the procedure for logging into the Library
2anagement System based on user privileges.

Librarian(issue book, return book, query a book)

4lerk(maintain book catalogue, maintain members details)
Student(query a book, status of book issued by him)

1.2 Actors
Librarian, Student, 4lerk.

1.3 Pre-Condition
Every member should have a unique user_id and password.

1.4 Post-Condition
If the use case is successful, the user is logged into the system,
otherwise the system state is unchanged.

1.5 Flow of Events

1.5.1 Basic Flow
This use case starts when actor wishes to log into the system
The system requests the actor to enter his user_id and
password.
The actor enters user_id and password.
The system validates the user_id and password and checks
for his/her privileges.
If the user is Librarian, he/she will be logged into the
system and presented with Librarians menu, the 4lerk will
be presented with 4lerks menu, and a student with
students.
The use case ends.
 1.5.2 Alternate Flow
1.5.2.1 Invalid Name/Password
If the system receives an invalid user_id or password, an
error message is displayed and the use case ends

1.6 Special Requirements

None

1.7 Related Use Cases

None

2. MEMBERSHIP

2.1 Introduction
This use case documents the procedure for maintaining members
details.

2.2 Actors
4lerk, Student

2.3 Pre-condition
4lerk must be logged in to the system.

2.4 Post-condition
If the use case is successful, the member details should be updated,
otherwise the system state is unchanged.

2.5 Flow of Events

2.5.1 Basic Flow
The use case starts when the 4lerk wants to add, delete or
modify some details of the members; or when a Student wishes
to seek membership details.
The corresponding changes will be done.
 The student will be provided with membership details and
requirements, if he desires.
The use case ends.
2.5.2 Alternate Flow
None

2.6 Special Requirements

None

2.7 Related Use cases

None

3. MANAGE BOOKS

3.1Introduction
This use case documents the procedure for maintaining the catalog of
the library.
3.2Actors
4lerk

3.3 Pre-condition
4lerk should be logged into the system.

3.4 Post-condition
If use case is successful, the book should be updated, otherwise the
system state is unchanged.

3.5 Flow of Events

3.5.1 Basic Flow
This use case starts when the operator wishes to add, delete
or modify some details about books in library.
The corresponding changes are saved in the database.
The use case ends.
 3.5.2 Alternate Flow
None

3.6 Special Requirements

None

3.7 Related Use cases

None

4. ISSUE BOOK

4.1 Introduction
This use case documents the procedure of issuing a book.

4.2 Actors
Librarian, Student, 0arcode reader

4.3 Pre-Condition
Librarian must be logged in to the system.

4.4 Post-Condition
If use case is successful, the book is issued to the student otherwise
the system is unchanged.

4.5 Flow of Events

4.5.1 Basic flow
The use case starts when a student wants to get a book issued.

The system reads and validates the students information

using the 0arcode reader.
The system reads the books information using the 0arcode
reader.
The return date of the book is calculated.
 The book and students information is saved into the
database.
The use case ends.

4.5.2 Alternate flow

4.5.2.1 Unauthorized student
If the system doesnt validate the student, then an error message
is flagged and the use case ends.
4.5.2.2 Account is full
If the student has requested a book, and the account is already full
i.e. he has already 4 books issued on his name, then the request
for issue is denied and the use case ends.

4.6 Special Requirements

None

4.7 Related Use Cases

3enerate barcode

5. RETURN BOOK

5.1 Introduction
This use case documents the procedure of returning a book and
calculating the fine amount if the student has returned the book after
the specified return date.

5.2 Actors
Librarian, Student, 0arcode reader

5.3 Pre-Condition
Librarian must be logged in to the system.
 5.4 Post-Condition
If use case is successful, the book is returned back to the library and if
needed, the fine is calculated, otherwise the system state is
unchanged.

5.5 Flow of Events

5.5.1 Basic flow
This use case starts when a student wants to return a book.
The system reads the books information using the 0arcode
reader.
The book is returned to the library.
The database entries corresponding both to the student
account and the book are updated.
The use case ends.
5.5.2 Alternate flow
5.5.2.1 Late return of book
If the book is returned after the due date, fine is calculated and
database is updated accordingly. The use case end here.

5.6 Special Requirements

None

5.7 Related Use Cases

None

6. GENERATE REPORTS

6.1 Introduction
The use case documents the procedure for generating the reports as
desired by the Librarian.

6.2 Actors
Librarian
6.3 Pre-Condition
Librarian must be logged in to the system.

6.4 Post-Condition
If use case is successful, the various reports, regarding the fine and
details of the books are generated.

6.5 Flow of Events

6.5.1 Basic flow
This use case starts when a librarian wants to generate reports of the
books available in the library and fine reports.
The system displays the various report generating criteria to the
librarian, which can be the books available, fine details etc.
The librarian selects the criteria.
The system generates the report.
The book related report is sent to the printer.
The fine details are sent to the Institutes billing system.

6.5.2 Alternate flow

In case of book list, when printer is out of ink, use case ends.
In case of fine details, when the Institutes billing system is down,
the use case ends.

6.6 Special Requirements

None

6.7 Related Use Cases

None
ENTITY RELATIONSHIP DIAGRAM
SOFTWARE REQUIREMENTS SPECIFICATION

1. Introduction

This document aims at defining the overall software requirements for

Library 2anagement System. Efforts have been made to define the
requirements exhaustively and accurately. The final product will be
having only features/functionalities mentioned in this document and
assumptions for any additional functionality/feature should not be made
by any of the parties involved in developing/testing/implementing/using
this product. In case it is required to have some additional features, a
formal change request will need to be raised and subsequently a new
release of this document and/or product will be produced.

1.1 Purpose

This specification document describes the capabilities that will be

provided by the software application Library 2anagement System. It
also states the various required constraints by which the system will
abide. The intended audience for this document are the development
team, testing team and end users of the product.

1.2 Scope

The Software Requirements Specification captures all the requirements

in a single document. The Library 2anagement System that is to be
developed provides the members of the Library and employees of the
library with books information, online booking of books and many other
facilities. The Library System is supposed to have the following features:

The system provides users with Login facility.

 The system provides the members with the option to check their
account and/or change their options like password of the account
whenever needed all through the day during the library hours.
The system allows the members to issue the book during library
hours and all the through the semester.
The system lets the library staff to check which all members have
issued the books and whether they can borrow any more books or
not.
It keeps record of the due date of the issued books.
It helps to implement fine on the defaulter members and also
updates the related billing reports.
It helps the clerk and Librarian to add/remove books and arrange
them according to category
It automatically updates the database regarding the issued books
and hence provides info about the availability of individual books.

The application will greatly simplify and speed up the 0ook issuing
process and its management.

1.3 Definitions, Acronyms and Abbreviations

7ollowing abbreviations have been used in the document:

SRS: Software Requirement Specifications
AIT: Ansal Institute of Technology
D0A: Database Administrator

1.4 References

(i) IEEE recommended Practice for SRS6 IEEE Std 83061993

(ii) Software Engineering by KK Aggarwal.

 1.5 Overview

The rest of the SRS document describes the various system

requirements, interfaces, features and functionalities in detail.

2. Overall Description

The Library 2anagement System is a package to be used by Libraries to

improve the efficiency of Librarians, Library employees and Users. The
Library System to be developed benefits greatly the members and the
Librarian of AIT. The system provides books catalog and information to
members and helps them decide on the books to borrow from the
library. The Librarian can keep the books catalog updated all the time so
that the members get the updated information all the time.

The product to be developed has interactions with the users: Librarian,

2embers who are the students of AIT.
The product has to interact with other systems like: Internet, 0illing
System and the AIT Information Security System.

2.1 Product Perspective

The application will be a windows6based, self6contained and

independent software product.
2.1.1 System Interfaces

The product has to interact with other systems like: Internet, 0illing
System and the AIT Information Security System.

2.1.2 User Interfaces

1. Login form (for all).

2. Register form (for user interface).
3. 0orrowing form (for Librarian interface).
4. Returning form (for Librarian interface).
5. Searching form (for Librarian and User interfaces).
6. View the last transaction information (for Librarian interface).
7. Report form (for Librarian interface).
8. 0ook info form (for Librarian and 4lerk interfaces).
2.1.3 Hardware Interfaces

(i) Screen resolution of at least 800x600 required for proper and

complete viewing of the screen.
(ii)Supports for printer i.e. appropriate drivers are installed and
printer connected.

2.1.4 Software Interfaces

(i) Any Windows based operating system.

(ii)2S Access 2000 or the D02S6 for database

2.1.5 Communication Interfaces

The System is accessed by following:

Librarian, who works in the library and manages

transactions.
Student member, who borrows book from the library and
searches info about them
4lerk, who is responsible for database management.
Student member should have a member card for borrowing the
book.

2.1.6 Memory Constraints

At least 256 20 RA2 and 2 30 space on hard disk will be required

for running the application at Librarys end.

2.1.7 Operations

The product release will not cover any automated housekeeping

aspects of the database. The D0A at the client site (i.e. Library) will
 be responsible for manually deleting old/non6required data.
Database backup and recovery will also have to be handled by the
D0A.

2.1.8 Site Adaptation Requirements

The terminals at the clients site will have to support the hardware
and software interfaces specified in above sections.

2.2 Product Functions

The Library 2anagement System provides online real time

information about the books available in the Library and the user
information. The functions of the system include the system providing
different type of services based on the type of users
[2ember/Librarian].

2ajor functions that software performs:

(i) A Login facility for enabling only authorised access to the

system.
(ii) 2embers are provided with updated information about the
book catalog.
(iii) Provisions for the members to borrow the books they want, if
all the other required rules hold good.
(iv) The member is given a provision to check his account
information and change the account information any time in
the given valid period.
(v) The librarian can get the information about the members who
have borrowed or returned the books.
(vi) The availability of the books can be known by both Librarian
and members.
(vii) The 4lerk is provided with interfaces to add/delete the books
available in the book catalog.
 (viii) The members when complete the book borrowing or returning
process, the due to be paid by the member must be calculated
and the information about the member and the due amount is
sent to the billing reports system.

2.3 User Characteristics

The users of the system are members, librarian of the Institute, clerk
and the administrators who maintain the system. The members and
the librarian are assumed to have basic knowledge of the computers
and Internet browsing. The administrators of the system to have
more knowledge of the internals of the system and is able to rectify
the small problems that may arise due to disk crashes, power failures
and other catastrophes to maintain the system. The proper user
interface, user manual, online help and the guide to install and
maintain the system must be sufficient to educate the users on how
to use the system without any problems.

2.4 Constraints

(i) The information of all the users must be stored in a database

that is accessible by the Library System. Huge number of
records may slow down the system.
(ii) The Institute information security system must be compatible
with the Internet applications.
(iii) The Library System is connected to the Institute computer and
is running all 24 hours a day.
(iv) The billing system is connected to the Library System and the
database used by the billing system must be compatible with
the interface of the Library System.
(v) The users must have their correct usernames and passwords to
enter into the Library System.
 2.5 Assumptions and Dependencies

(i) The users have sufficient knowledge of computers.

(ii) The Institute computer should have Internet connection and
Internet server capabilities.
(iii) The users know the English language, as the user interface will
be provided in English.

2.6 Apportioning of Requirements

Not required.

3. Specific Requirements

This section contains the software requirements to a level of detail

sufficient to enable designers to design the system and testers to test
that system.

3.1 External Interface requirements

3.1.1 User Interfaces

The following screens will be provided:

Login screen:

This will be the first screen that will be displayed. It will allow user to
access different screens based upon the users role. Various fields
available on this screen will be

i) Library ID: alphanumeric of length up to 20 characters

ii) Password: alphanumeric of length up to 10 characters
iii) User Type: will have the following values out of which the user will
chose accordingly: student , librarian, clerk.
Registration form:

This screen will be displayed if a new user wants to register to the

library. This screen comes if user clicks on the register button on
login screen. This will contain the following fields

i) Library ID: user can give analphanumeric of length up to 20

characters as his user id which is later used for login.
ii) Name of Member: text of length up to 50 characters.
iii) Member Type:will have the following values out of which the user
will chose accordingly: administrator, student , librarian, clerk.
iv) Course/Department
v) Semester
vi) Mobile Number
vii) Address

Borrowing form:

This screen will be accessible to the user with role librarian only. It will
allow user to enter students details and the book he/she wants to
borrow and issue the book to the students. This will contain the
following fields:

i) Book ID
ii) Student ID
iii) Issue book button
iv) Return date

Returning form:

This screen will be accessible to the user with role librarian only. It
allows user to enter book details and remove the book from students
account and put it back in the library book bank.This will contain the
following fields:

i) Book ID
ii) Student ID
iii) Return book button
iv) Return date
v) Fine

Searching form:

This screen will be accessible to the user with role librarian and
student. It contains a text box in which name of the book can be
entered and based on availability the details of the book are
displayed.This will contain the following fields:
i) Text box for entering keyword
ii) List of books available

Last transaction information:

This screen will be accessible to the user with role librarian only.
Librarian can access the information about the last borrowing and
returning of the books.

Report form:

This screen will be accessible to the user with role librarian only. This
gives the report of all the books returned and issued till now. This
form contains the options for which report is to be generated.
Book information form:

This screen will be accessible to the user with role librarian and clerk.
The information about books can be edited. If new books come in the
library, their info can be added to the database.This will contain the
following fields:

i) Book ID
ii) Title
iii) Author
iv) Co-author
v) Publisher
vi) Edition
viii) Rack Number
iX) Price

3.1.2 Hardware Interfaces

(i) Screen resolution of at least 800x600 required for proper and

complete viewing of the screen.
(ii)Support for printer i.e. appropriate drivers is installed and printer
connected.

3.1.3 Software Interfaces

(i) Any Windows based operating system.

(ii)2S Access 2000 or the D02S6 for database

3.1.4 Communication Interfaces

The System is accessed by following:

Librarian, who works in the library and manages transactions.

 Student member, who borrows book from the library and searches
info about them
4lerk, who is responsible for database management.
Student member should have a member card for borrowing the book.

3.2 System features:

3.2.1 Books Issue Management

Description:
This system will maintain the information about the books that are
being issued & returned. The following information will be maintained
about each book:
Title of the book, author,book id, status of the book (issued or not),
return date of the book (if any), fine on the book, students name and
ID who has issued the book.
The system will allow creation/ modification/ deletion of new/
existing books.

Validity checks:
i) Only user with role administrator and librarian will be authorized
to access the books management module
ii) Each book must have book ID, title, author, publisher, edition, rack
no.
iii) 7ine of Rs5 per day after returning the book must be charged on a
book if not returned till due date.
iv) Student ID must be unique.
v) 0ook ID must be unique.
vi) Only 4 0ooks can be issued per student.
vii) Due date must be two weeks after the date of issue.

Sequencing Information:
0ooks information must be entered before issuing or returning of
books
Error handling/ response to abnormal situations:
If any of the above validations/ sequencing flow does not hold true ,
appropriate error messages will be prompted to the user for doing
the needful.

3.2.2 Report generation

Description:
This system will generate reports about the books that are present in
the library or the reports regarding the fine.

Validity checks:
(i) Only user with role librarian will be authorized to access the report
generation module.

Sequencing Information:
The reports for books to be returned today are created only at the
end of the process of returning and issuing books

Error handling/ response to abnormal situations:

If any of the above validations/ sequencing flow does not hold true ,
appropriate error messages will be prompted to the user for doing
the needful.

3.2.3 User accounts information management

Description:
The system will maintain information about various users who will be
able to access the system. The following information will be
maintained:
User ID, user name, user Type, password

Validity checks:
i) Only user with role administrator will be authorized to access the
user accounts information management module
 ii) User name cannot be blank.
iii) User ID cannot be blank .
iv) User ID should be unique for every user.
v) Password cannot be blank.
vi) User type cannot be blank.

Sequencing Information:
User account for a particular user has to be created in order for the
system to be accessible to that user.

Error handling/ response to abnormal situations:

If any of the above validations/ sequencing flow does not hold true,
appropriate error messages will be prompted to the user for doing
the needful.

3.3 Performance Requirements:

None

3.4 Design constraints:

None

3.5 Software System Attributes:

3.5.1 Security:
This application will be password protected. Users will have to enter
correct user name, user ID, password to access the application.

3.5.2 Maintainability:
The application will be designed in a maintainable manner. It will be
easy to incorporate new requirements in new modules.
 3.5.3 Portability:
The application will be easily portable on any windows based system
with 2S6Access 2003 or above installed.

3.6 Other requirements:

None
DATA DICTIONARY

Field Name Data Type Size Description

Name of member Text 50 Name of the
member

Library ID Alphanumeric 20 Unique

identification
of the members

Password Alphanumeric 10 Password chosen by

member at time of
registration

4ourse/Department Text 10 The course in which

the member is
enrolled.

Semester Numeric 5 The semester in

which the member
currently studies in

Address Text 100 Residence of

members

2obile Numeric 15 2obile no. of the

member

Date_reg Date/Time 66 Date of Registration

Date_expiry Date/Time 66 Registration Expiry

date.
0ook title Alphanumeric 100 Title of the book
0ook ID Text 50 0ook identification
[primary key] number

Author Text 70 Author of the book

Subject Text 70 The subject book

belongs to

No_of_copies Numeric 10 No of copies of that

book in the library

Price Numeric 10 Price of the book

Rack_Number Alphanumeric 10 Almirah no.

(location)

Date_issue Date/Time 66 Date on which book

is issued

Date_due Date/Time 66 Due date on which

book is
to be returned

Date_return Date/time 66 Date on which book

was returned

7ine charged Numeric 10 7ine implemented

on the student.
SCREENSHOTS
 INDEX

S.No Contents Date Signature

1. Problem Statement 11/1/12

2. 4ontext Diagram 18/1/12

3. Data 7low Diagram Level61 25/1/12

4. Data 7low Diagram Level62 1/2/12

5. Use 4ase Diagram 8/2/12

6. ER Diagram 15/2/12

7. Software Requirements 29/2/12

Specifications
8. Data Dictionary 14/3/12

9. Pseudo 4ode 21/3/12

10. Screen Shots 28/3/12

LIBRARY MANAGEMENT
SYSTEM

SO7TWARE EN3INEERIN3 LA0

ET4S 252

Ansal Institute of Technology, 3urgaon

Submitted by:
Nitesh Kumar Arora
01370102810
ECE-A Group 1