library circulation system

8/19/2019 Library Circulation System

1/44


2/44

Page | 4

1.0 Introduction

1.1 Purpose:

The main objective of this document is to illustrate the requirements of the

project Library Circulation system. The document gives the detailed

description of the both functional and non-functional requirements.

The document is developed after a number of consultations with the client

and considering the complete requirement specifications of the given Project.

The final product of the team will be meeting the requirements of this document.

The SRS typically contains the brief description of the project. The purpose of the

requirement document is to specify all the information required to design, develop

and test the software.

The purpose of this project is to provide a friendly environment to maintain the details

of books and library members.

The main purpose of this project is to maintain easy circulation system using

computers and to provide different reports

1.2 Scope:

The project scope is the definition of what the project is supposed to accomplishand the budget of both time and money that has been created to achieve these

objectives. We can’t provide PC in the library

We can’t provide internet

Can’t provide network connection

Can’t provide manpower

We can’t provide warranty service more than one year

1.3 Features:Our project will provide the following features-

Authentication system

Searching system without login

Borrower can check his eligibility and availability of books

Anyone can borrow book by logging in

Admin can verify the valid user to permit for borrowing book

When book is unavailable, user can request for advanced booking

If anyone over his issuing date, he will be inform by a warning message

Also have the re-new facility

Finally has a fine generating system


3/44

Page | 5

2.0 Inception

In software industry requirement engineering is one of the most important parts

of software engineering process. Which one gives us the proper scenarios whatthe customer wants, analyzing needs and feasibility, negotiating a reasonable

solution etc. Inception is the initial step of requirement engineering which make

us understand “how does a software project get started?”. In software industries,

a software project begins when a business need is identified. So the first step is

we need to understand the customer needs. Figure out a rough feasibility

analysis, not only the customer’s need but also with the people who are

apparently involved with the introducing system. This stage is called inception.

Inception involves the following phases:

Identifying Stakeholders

Recognizing multiple viewpoints

Working towards collaboration

Asking the First Questions

The phase ends with identifying credibility and go/no – go decision. Though we

did not have any interaction with the stakeholders, especially with the client

“Total Solutions Enterprise”, this paper is more on assumption. This paper will

be more easeful after communicating with our client. In this paper we will focuson Accounting and Inventory management module. Again, this paper is a partial

submission; more details will be included as per communicating with all of the

stakeholders.

2.1 Stakeholders:

The stakeholders of a software project are those people or positions, who are

directly or indirectly affected or effected by the project. The stakeholders and

users who are most immediately involved in a “Book Circulation System”

implementation can be divided into four groups.

Library Authority: Library authority is one of the major stakeholders of our

software because they operate and maintain book circulation system of a

library.

Database Admin: Database Admin has the adminstrative power to handle the

software.So he is also our stakeholder.

Borrowers: Borrowers will directly interact with this software. So they are also

a major stakeholder of our system.


4/44

Page | 6

IT Department : We selected developers as stakeholder because they develop

this system and work for further development. If occurs any system interruption,

they will find the problem and try to solve it.

University: University will finance the project and it has some has rules and

regulations to maintain our system. We have to follow them strictly. Souniversity is also our stakeholder.

2.2 Stakeholders View Point: What They Want

Different stakeholders achieve different benefits. Consequently, each of them has

a different view of the system. So we have to recognize the requirements from

multiple points of view. Our assumption is given below:

Library Authority view points: Library Authority beholds the people who areconcerned with library management. These people are librarian, operator and

other employees. Though these people are more of passive actors, we treated

them as important stakeholders because they will judge the credibility of the

product and will make go/no-go decision. Their view point’s may be the

following-

User friendly and efficient system

Minimum maintenance cost

Easy to operate

Guidelines for operators

Automated alarm system and letter generation

Database Admin view points:

Maintain a database of all items in the library’s circulation Secured System

Easy to operate

The application only needs to be installed and maintained on one computer. Strong Authentication system

Borrowers view points: Borrowers behold the people who are concerned with

library user. These people are student, teacher, and other employees who are

interacted directly or indirectly with the library.

Easy to use.

User friendly and efficient systems

Automated alarm system

Easy authentication system

IT department’s viewpoints:

Easy to develop

No ambiguous requirement


5/44

Page | 7

University viewpoints:

Buy the system within their budget

No disruption of rules and regulation

2.3 Working towards Collaboration:

Every stakeholder has their own requirement. In this step, we merged these

requirements. We followed following steps to complete the task:

Identify the common and conflicting requirements

Categorize the requirements

Take priority points for each requirements from stakeholders and on the basis of

this voting prioritize the requirements

Make final decision about the requirements.

2.4 Common Requirements:

User friendly and efficient system

Easy to operate

The application can be accessed from any computer that has Internet access

2.5 Conflicting Requirements

Minimum maintenance cost

Availavility of all requriments within the budget Easy access

Restrict access to functionality of the system based upon user roles

No ambiguous requirement

We finalized following requirements for the system by categorizing and priorotizingthe requirements.

2.6 Final Requirements

User friendly and efficient system Easy to operate

The application can be accessed from any computer that has Internet access

Secured System

Restrict access to functionality of the system based upon user roles

The application only needs to be installed and maintained on one computer

No disruption of rules and regulation

Allows valid users to renew items online by logging into the system

Automatic generate reports on the items in the system Availavility of all requriments within the budget


6/44

Page | 8

2.7 Questioners:

We set our first set of context-free questions focuses on the customer and other

stakeholders, overall project goals and benefits. The questions are mentioned

above. These questions helped us to identify all stakeholders, measurable benefit

of the successful implementation and possible alternatives to custom software

development. Next set of question helped us to gain a better understanding of

problem and allows the customer to voice his or her perception about the

solution. The final set of question focused on the effectiveness of the

communication activity itself. We can follow the following steps to prepare a

questioner.

Step 1: Confirm actors and goals.Have all actors and their goals been identified?

Which actors can be generalized (combined)?

Which goals are potential use cases?

Step 2: Develop an outline of the use case(s).For the goals identified as potential use cases, what are the key pieces?

For each outline level, what are key data?

Outline all use cases.

Prioritize the use-case flows.

Decide on a final use-case list (for initial pass).

Step 3: Write a brief description of the use case(s).

What two or three sentences describe all actors and the basic flow?Generate content first, and worry about words meeting later.

Step 4: Detail the basic flow.What event starts the use case?

How does the use case end?

How does the use case repeat some behavior?

What is the "happy" (best case) path?

There is one and only one basic flow.

Step 5: Detail the alternate flows.Are there optional situations for the use case?

What might go wrong?

What might not happen?

Which resources might be blocked?

Which alternate flows are special -- perhaps nonfunctional -- requirements

(i.e., they apply to this use case only)?

Step 6: Review the use case(s).Are there more use cases?

Should some use cases be redefined?Which ones can be combined?


7/44

Page | 9

Step 7: Record pre- and post-conditions.What was the previous state before this use case comes into play?

What happens once the use case is complete?

Step 8: Develop generalizations for all use cases.Determine shared content and process for the use cases.What items have been noted for the glossary or as global business rules?

Who has the most recent and accurate source document?

Where is it located?

2.8 Group Meeting:

Date: 09.09.2012

Place: IIT

Subject: Discussion on inception

Members:

Md. Samsuddoha BIT-0309

Md. Zahidul kabir BIT-0320

Sujit Ghosh BIT-0329

Date: 13.09.2012

Place: Central Library, University of Dhaka

Subject: Discussion on inception

Members:

Md. Samsuddoha BIT-0309

Md. Zahidul kabir BIT-0320

Sujit Ghosh BIT-0329


8/44

Page | 10

3.0 Elicitation

Elicitation refers on what process we should keep focus. To do a great a

elicitation for a SRS we need to conduct a error free focusing use case from

different viewpoints. In this process we need to think on what is basic unit of this

project, what is domain that we work for, for whom we make the software, who

is going to be benefitted by this system and a lot of correlated functions.

After ice breaking, in elicitation we need to understand the users need. We

should have to a make choice on that concern by which the Software can be

much more sophisticated. We should rapidly decrease the complexity in case of

using the product but have to convey our attention on how we develop this.

To elicit the total process anyone must need to gather information. To gather

this info we hold some meetings, did some team work, understood what

requirements we need.

Here is the info we got from some meetings-

3.1 Collaborative Requirements Gathering:

We have been proposed in many different approaches to gather collaborative

requirements. They make use of various slightly different scenarios .We completed

following steps to do it.

Meeting with Librarian to understand the recent process

Meeting with the Library people to understand what is the task they perform to

provide book.

Meeting with user. Understand their problems of getting books.

3.2 Quality Function Deployment:

If we want to provide much attention on product requirements analysis we need

conduct the QFD(Quality function deployment) in this respect.QFD provides

three basic form of requirements .The are-


9/44

Page | 11

Normal Requirements:

Normal requirements consist of objectives and goals that are stated during the

meeting with the customers. Normal requirements of our project are

User friendly system

Decrease the complexity of exiting system

Error free activity

Proper use of recourses

Expected Requirements:

These requirements are implicit to the system and may be so fundamental

that the customer does not explicitly state them .Their absence will be a

cause for dissatisfaction.

Well security

Make it error less

Decrease the human work

Make it automated

Exciting requirements:

These requirements are for features that go beyond the customer's

expectations and prove to be very satisfying when present

Automated warning mail generation

Enrich the web site with eBooks and journal

If anyone forget password ,can get them back form SMS

Can use electronic board for reading newspaper or other regular journal.

NormalRequirements

ExpectedRequirements

Wow factors


10/44


11/44

Page | 13

requirements elicitation.

View on the set of usage scenarios.

Total description of the system’s technical environment.

4.0 Product Perspective

The existing circulation system of Dhaka University Library is ok but not good

enough. Still there are some problems that and a lot of manual activity is

required to solve those dependencies. So, in our proposed system we tried to

eradicate the problem with a lot of digitalized features.

After acquisition process, the books are sorted into 1000 categories. But still the

system doesn’t have department wise searching and sorting capacity. It

becomes a mess when anyone tries to see subject wise books. Again providing

pdf and e-books are still not handled well. Even the library people do not find the

existing system a user friendly one. So at the time of executing this project, it was

our main target to make it much more user friendly and error-less.

5.0 Elicitation

5.1 Product Functionality:

The main functionality of the circulation system are –

Borrowing/ Holding the books

Issue

Renew

Proper description of this function will be described later in this SRS document.

5.2

Users and Characteristics:

Registered Graduate

Teacher

Undergraduate Student

PHD student

Researcher


12/44

Page | 14

5.3 Operating Environment:

The proposed system will be a mixture of web based system along with

computer based system. Library website can be visited from anywhere. But

anyone can download the pdf & e-book if and only if he/she are stayed at the iprange of Dhaka University area. And computer based system will be provide in

the Library for hard copies of books.

5.4 Design and Implementation Constraints

Software Language used -

The application can be developed using Java/php/ .NET or any other webprogramming language.

Development Tools -

Some Development tools like CSS3 can be used to make it much more user

friendly.

Database Support-

SQL can be used for database support.

According to the schedule, our team will hand-over the complete SRS of Dhaka

University Library Management System. At the same time, the team will also

provide a user manual if it is required. The team is also responsible to conduct

training sessions for the Administrative task, where they will provide tutorials,notes along with the hands on training. They will give feedback to the coder and

future developer. The team will be ready for solving any type of mistakes if

occurred in this SRS.


13/44

Page | 15

6.0 Software Requirement Models

6.1 Scenario Based Model:

A normal user wants to borrow a book from a library. He first searches the book

he needs. When he finds the book he tries to borrow the book. Then we need to

check that if he is a valid user. He has to go through an authentication system by

logging in or signing up. And if he is eligible to borrow the book, then it is

checked if the book is available. If the book isn’t available then he has to go

through the booking process where he has to wait until any copy of that book is

returned. If the book is available then he will be given a call number with a slip

and then the book will be given to him for 15 days and he can issue 3 books at a

stretch.

When the book is unavailable then the user will be sent to the booking list. If any

copy of that is returned by anyone then the first booked person will be notified

by sending a mail. If he doesn’t borrow the book after 24 hour of sending the

mail his request will be deleted.

Whenever anyone wants to re-issue his book he has to come and give the book

back and the librarian will re-issue the book with a new time length if he has no

fines due. If a user or borrower cannot give the book in time then he has to pay

the fine and the fine increases day by day.

If he pays the fine then he is eligible again to borrow the books.

6.1.1 Use Case:

Authentication

Borrowing

Booking

Re-Issue

Fine Generation


14/44

Page | 16

Use case Name: Authentication

Use case No: 1

Primary Actor: User(students/ teachers / other

people)

Secondary Actor: Library staffsDescription: User has to login to authenticate

himself/herself

Precondition: Must take the digital Id

Trigger: To borrow or renew or doing

anything.

Events: Checking the validity of users.

Use case Name: BorrowingUse case No: 2

Primary Actor: User(students/teacher /

Undergraduate Student/PHD

students/researchers )

Secondary Actor: Library people.

Description: The process of lending books.

Precondition: Must take the digital Id and must be

logged in and eligible for lending.

Trigger: To get the books.Events: Give the user the books that he is

searching for.

Use case Name: Booking

Use case No: 3

Primary Actor: User(students/teacher /

Undergraduate Student/PHD

students/researchers )Secondary Actor: Library people.

Description: The process of booking the books if

not available at that time .

Precondition: Must take the digital Id and must be

logged in and eligible for booking.

Trigger: To Get the book when it arrives in

the library.

Events: Generate booking request.


15/44


16/44

Page | 18

6.1.2 Use Case Diagram:

Fig : Level 0

AuthenticationAuthentication

Borrowing

Booking

Fine generation

Re-Issue

Librarian/Admin

User

DB


17/44

Page | 19

Fig: Authentication

Sign up

Verify

Sign in

Retry

Sign out

Librarian/Admin

User

Block


18/44

Page | 20

Fig: Re –Issue

Renew Request

Changing book

with same book

Showing fines

Changing DB

Booking

Librarian/Admin

User

Borrowing


19/44

Page | 21

Fig: Fine Generation

Searching for People

who have fines

Giving warning

Increasing the fineLibrarian/Admin


20/44

Page | 22

6.1.3 Activity Diagram:

Fig: Authentication

User

Have

Account?

Correct

Username/

Password

Give Input

Logged in

Try>3 ?

Try=Try+1

Reset Password Sign Up

Check

Confirmation Mail

Yes

No

Yes

No

Yes

No


21/44

Page | 23

Fig: Borrowing Book

Borrowing

Book

Eligible

borrower?

Exit

Is the book

Available ?Booking

Generate Call Slip

Change Borrower

Data

Change Book Data

Yes

Yes

No

No


22/44

Page | 24

Fig: Booking book

Booking

Book

Check Booking

requests

Available

Book >0

Send mail

Book

Taken ?

Change the DB

Exit

Delete Request

No

No

Yes

Wait 24 hours

Yes


23/44

Page | 25

Fig: Re-Issue

Re- Issue

Return the book

Has any

Give A fresh Copy

Booking

Clear Fines

If Available

Borrowing

No

Yes

Yes

No


24/44


25/44

Page | 27

6.1.4 Swim lane Diagram:

Fig: Borrowing Book

BorrowEligible ?

Exit

Books

availability?

Call slip

generator

Change

borrower DB

Change book DB

Borrow

Yes

No

Yes

No

UserSystem

UI


26/44

Page | 28

Fig: Booking Book

Booking Booking

Send

Mail

UpdateDatabase

Delete

Request

Check Booking

request

Book Taken?

EXIT NoYes

Wait 24 hour

Yes

No

User System UI


27/44

Page | 29

Fig: Re-Issue

User System UI

Re-issue Return

The book

Re-issue

Booking

Re-Issue

Has any fine?

If available

Clear

FinesYes No

Yes

No


28/44

Page | 30

6.2 Data Modeling:

There are few tables with attributes which are used in that SRS. They are given below

with ER Diagram.

Book

Sub ect

Author

ISBN

Title

Publish

Status

Call Num

User

ID

Name

Password

Username

Email

Address

Call Num

Fines

Borrowed

by

Is A

Holder

Borrower

T e

Notify Date

ISBN

Return Date

Issue Date

ISBN Return Date

T e


29/44

Page | 31

6.3 Class Based Model:

6.3.1 Identifying Analysis Class:

Now we will analyze the main scenario or the story to get those classes-

A normal user wants to borrow a book from a library. He first searches the book

he needs. When he finds the book he tries to borrow the book. Then we need to

check that if he is a valid user. He has to go through an authentication system by

logging in or signing up. And if he is eligible to borrow the book, then it is

checked if the book is available. If the book isn’t available then he has to go

through the booking process where he has to wait until any copy of that book is

returned. If the book is available then he will be given a call number with a slip

and then the book will be given to him for 15 days and he can issue 3 books at astretch. Then finally the Database will be updated.

When the book is unavailable then the user will be sent to the booking list. If any

copy of that is returned by anyone then the first booked person will be notified

by sending a mail. If he doesn’t borrow the book after 24 hour of sending the

mail his request will be deleted.

Whenever anyone wants to re-issue his book he has to come and give the book

back and the librarian will re-issue the book with a new time length if he has no

fines due and a clearance. If a user or borrower cannot give the book in time thenhe has to pay the fine and the fine increases day by day.

If he pays the fine then he is eligible again to borrow the books.

Here we can see that probable classes are…

User

Book

Borrow

Authentication

Booking

Re-Issue

Fine

Librarian

Clearance

Database

Identifying analysis classes:


30/44

Page | 32

Analysis classes manifest themselves in one of the following ways.

External entities

Things

Occurrences Or Events

Roles

Organizational Units

Places

Structures

Potential Classes Characteristics Number that Applies

User Accepted 1,2,3,4,5,6

Book Accepted 1,2,3,7

Authentication Accepted all

Borrower Accepted 1,2,3,4,5,7

Booking Accepted 1,2,3,4,5,7

Re-Issue Accepted 1,2,3,4,5,7

Fine Generation Accepted 1,2,3,4,7

Librarian Accepted 2,4 other all are rejected

Clearance Accepted 1,2,3 other all are rejected

Database Accepted 1,2,3,5,6,7

6.3.2 Specifying Attributes and Defining operations:

Class Cards

Class Name: User

Methods:

ChangePassword( ); String

BookCollection( ); void

Attributes:

ID : Bigint

Username: String

Password: String

Name: String

Type: String

Department: String


31/44

Page | 33

Class Name: Book

Methods:

SearchBook( ); String

Attributes:

Subject: String DB(Object)

Title: String

Name: String

Author: String

ISBN: String

Category: String

Class Name: Authentication

Methods:

SignUp( ); Void

SignIn( ); void

SignOut( );void

Attributes:

AuthenticationNumber : Bigint

User(Object)

DB(Object)

Class Name: Borrower

Methods:

SearchBorrower( ); User

UpdateBorrower( ); void

DeleteBorrower( ); Void

Attributes:

BorrowerNumber : Bigint

CallNumber: Bigint

BorrowerStatus: boolean

User(Object)


32/44

Page | 34

Class Name: Booking

Methods:

SearchBorrower( ); User

UpdateBorrower( ); void

DeleteBorrower( ); Void

Attributes:

RequestId : Bigint User(Object)

BorrowerStatus: boolean

Class Name: Fine Generation

Methods:

GenerateFines( ); User

CheckFines( ); void

Attributes:

User(Object)

DB(Object)

Class Name: Database

Methods:

checkFine( );Bigint

Search( ); String

InsertBorrower( ); void

Attributes:

QueryString: String

Result: Resultset


33/44

Page | 35

6.3.3 CRC Model:

Class Name: Engine

Methods:

Renew( );void

User.GenerateFines( ); User

Fine Generartion.CheckFines( ); void

Booking.update( ); void

Attributes:

User(Object)

DB(Object)

Borrower(Object)

Fine Generation(Object)

Booking(Object)

Authentication UserBook

BorrowerBookingDatabaseFine Generation

Engine


34/44


35/44

Page | 37

Fig: Authentication Sub System

Get username,

password

Correct

Password?

Logged in

Successfully

Counter++No

Yes

Counter>3?

Sign Up Page

Give Confirmation

Mail

Update the DB

If Critical inputs are

If Mail link is clicked

Blocked

Send the reset

Password to

mail

No, Let

him tryagain

Yes

If reset password

is given


36/44

Page | 38

Fig: Level 1 (Borrowing)

Borrowing

Show Book List

Show Book Details

Generate Call Slip

Update Database

Check

Users

Check if Book

Available

If searched

If specified

If want to borrow

If eligible

If available

Exit

Booking

If not eligible

If not available


37/44

Page | 39

Fig Level 2(Booking)

Booking

Book user into Holder List

Send Mail

If a copy is available

Wait 24 hours

Taken?

Yes

Update DB

Delete Request

No


38/44

Page | 40

Fig : Level 2 (Check User)

Check User

Authentication

Give Permission

Check Fines

Check Limit of

Books

No Fines

Limit not Exceed

Show Message to clear

Fines

Show Message to return

Books

No

No


39/44

Page | 41

6.5 Behavioural Model:

6.5.1 State Transition Model:

Fig: Borrowing Process

Show specified category of

Books

Show Details of the Book

Check Eligibility of user

Check if the book is available

Generate Call Slip Enter in Booking List

If searched book in category

If selected specified book

If the borrow button is clicked

If user fine is zero and maximum number of

books not exceeded

If available book number >0 If available book number ==0


40/44

Page | 42

Fig : Authentication

Get username,

password

Correct

Password?

Logged in

Successfully

Counter++

Yes

Counter>3

?Sign Up Page

Give Confirmation

Mail

Update the DB

If Critical inputs are

If Mail link is clicked

Blocked

Send the reset

Password to

mail

No, Let

him try

again

Yes

If reset password

is given

No


41/44

Page | 43

Fig: Booking Process

Booking

Process

Push User into the Holding

List

Send mail to user’s mail

address

Pop and Delete the first user

Update Database

If Available book number >0

If waiting time==24hours


42/44

Page | 44

Fig: Database

Update Database

Search Book

Insert a user

in booking

list

Insert a

borrower

Generate

Call slip

Prepare A Query

Insert aquery into

the String

Execute Query

Execute

query in sql

server

Get Resultset

Execute

query in sql

server

Show Empty Result Show Result in UI

If resultset is

empty

If resultset is

not empty


43/44

Page | 45

6.5.2 Sequence Model:

Fig: Borrowing Process

Fig: Booking Process

UI ControlPanel

System DB

ReadingSystem

Ready

Borrow User

Checking

Book

Checking

UI ControlPanel

System DB

System

Ready

Generate

Request Check if Book

Available

Notify

If not

TakenDelete Request


44/44

7.0 Conclusion:

In our project, we have established a basic understanding of the problem, the

nature of the solution that is desired and the effectiveness of preliminarycommunication and collaboration between the stake-holders and the software

team. More studies and communication will help both side (developer and client)

to understand the future prospect of the project. Our team believes that the full

functioning document will help us to define that future prospect.

library circulation system

Documents