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 accomplish
and the budget of both time and money that has been created to achieve these
objectives.
We cant provide PC in the library
We cant provide internet
Cant provide network connection
Cant provide manpower
We cant 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
Page | 4

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 what
the 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 customers 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 focus
on 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.

Page | 5

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. So
university 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 are
concerned 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 points 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 librarys 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 departments viewpoints:
Easy to develop
No ambiguous requirement
Page | 6

 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 priorotizing

the 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

Page | 7

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?

Page | 8

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

Page | 9

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-

Page | 10

Normal
Requirements

Expected
Requirements

Wow factors

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.
Page | 11

3.3 Usage Scenarios:

At first a user authenticate in our system by creating an account .If a user already
has an account then he/she will log in the system with his/her own password
and username .Then our system will search the book that is requested by a user.
If the book is not found, the system will exit. Otherwise system will check the
availability of the book.

In case of Issue the available book:

If the book is available the system will check the user database to confirm
about the validation of the user. For an invalid user the system will exit and for
valid user librarian will generate a call slip number manually for the user.
Then our system will change the status of the book and user in our database.
The system also generates a return date for the book.

In case of Issue the reserved book:

If the user wants to issue a book which is already issued by a second user,
the user is supposed to reserves the book and gets a reservation number
on the basis of waiting list which is already in the reservation queue for
that book.
User is supposed to check his reservation number on the notice board
database in our system and list is put up on the library notice board also
by the librarian. Whenever they got the book free from the second user
they give the book to the user who have priority in the reservation queue
and second user is supposed to pay fine if he/she is returning the book
after due date.
User is supposed to issue the reserved book within three days from the
day when his/her turns on the reservation list otherwise his reservation
will be cancelled and he will not get the book (if there is waiting queue for
that book).
Now the user issues the book and the system automatically generates the
return date (+7 days) and the user is required to return the book within
the due date otherwise fine is imposed on him by the librarians.

3.4 Elicitation work product:

The output of the elicitation task can vary depending on size of the system or
product to be built. Our elicitation work product includes:
A statement of our requirements for automated book circulation system.
A bounded statement of scope for our system.
A list of customer, user and other stakeholder w h o p a r t i c i p a t e d i n
Page | 12

requirements elicitation.
View on the set of usage scenarios.
Total description of the systems 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 doesnt 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

Page | 13

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 ip
range 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 web
programming language.

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

Database SupportSQL 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.

Page | 14

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 isnt 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 doesnt 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
Fine Generation
Borrowing
Re-Issue
Booking
Page | 15

Use case Name:

Use case No:
Primary Actor:
Secondary Actor:
Description:
Precondition:
Trigger:
Events:
Use case Name:
Use case No:
Primary Actor:
Secondary Actor:
Description:
Precondition:
Trigger:
Events:

Use case Name:

Use case No:
Primary Actor:
Secondary Actor:
Description:
Precondition:
Trigger:
Events:

Authentication
1
User(students/ teachers / other
people)
Library staffs
User has to login to authenticate
himself/herself
Must take the digital Id
To borrow or renew or doing
anything.
Checking the validity of users.
Borrowing
2
User(students/teacher /
Undergraduate Student/PHD
students/researchers )
Library people.
The process of lending books.
Must take the digital Id and must be
logged in and eligible for lending.
To get the books.
Give the user the books that he is
searching for.
Booking
3
User(students/teacher /
Undergraduate Student/PHD
students/researchers )
Library people.
The process of booking the books if
not available at that time .
Must take the digital Id and must be
logged in and eligible for booking.
To Get the book when it arrives in
the library.
Generate booking request.

Page | 16

Use case Name:

Use case No:
Primary Actor:
Secondary Actor:
Description:
Precondition:
Trigger:
Events:

Use case Name:

Use case No:
Primary Actor:
Secondary Actor:
Description:
Precondition:
Trigger:
Events:

Fine Generation
4
Library people
Null
The process of generating fines for
whom didnt return the book in
time.
Must be authorized as authority.
To generate fines request.
Generate the fine, give warning mail
automatically, increase the fine
everyday and update the DB.

Re-Issue
5
User(students/teacher /
Undergraduate Student/PHD
students/researchers )
Library people.
The process of renew the books and
extending the time.
Must take the digital Id and must be
logged in and eligible for renewal.
To get the same books for some
more days.
Give the user the other copy of same
book if available.

Page | 17

6.1.2 Use Case Diagram:

Authentication

Borrowing

Booking
Librarian/Admin
User

Fine generation

Re-Issue

DB

Fig : Level 0

Page | 18

Sign up

Verify

Sign in
Librarian/Admin
User

Retry

Sign out

Block

Fig: Authentication

Page | 19

Renew Request

Changing book
with same book
Showing fines
Librarian/Admin
User

Changing DB

Booking

Borrowing

Fig: Re Issue

Page | 20

Searching for People

who have fines
Giving warning

Librarian/Admin

Increasing the fine

Fig: Fine Generation

Page | 21

6.1.3 Activity Diagram:

User

Reset Password

Have
Account?

Yes

Try>3 ?

Sign Up

Yes
No

Give Input

No

Try=Try+1

No

Check
Confirmation Mail

Correct
Username/
Password

Yes

Logged in
System

Fig: Authentication

Page | 22

Borrowing
Book

No

Eligible
borrower?

Exit

Yes

Is the book
Available ?

No

Booking

Yes

Generate Call Slip

Change Borrower
Data

Change Book Data

Fig: Borrowing Book

Page | 23

Booking
Book

Check Booking
requests

No

Exit

Available
Book >0
Yes

Send mail
Wait 24 hours

No

Book
Taken ?

Delete Request

Yes

Change the DB

Fig: Booking book

Page | 24

Re- Issue

Return the book

Yes

Has any
Fine ?

Clear Fines

No

Give A fresh Copy

If Available

No

Booking

Yes

Borrowing

Fig: Re-Issue
Page | 25

Fine Generation

Check the DB who has fines

Give Warning (via mail)

Yes

Cleared after
warning ?

EXIT

No

Already have
request ?

Yes

Increase the fine daily

No

Generate request

DONE

Fig: Fine Generation

Page | 26

6.1.4 Swim lane Diagram:

User

UI

System

Borrow

Eligible ?
No
Yes

Books
availability?

Exit

Yes

No

Borrow

Call slip
generator

Change
borrower DB

Change book DB

Fig: Borrowing Book

Page | 27

User

System

UI

Booking

Booking

Check Booking
request

EXIT

No
Yes

Send
Mail
Wait 24 hour

Delete
Request

No
Book Taken?

Yes
Update
Database

Fig: Booking Book

Page | 28

User

UI

System

Return
The book

Re-issue

Has any fine?

Clear
Fines

Yes

No

Re-issue

If available

Yes

Re-Issue

Booking

No

Fig: Re-Issue

Page | 29

6.2 Data Modeling:

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

Subject
Author
Title
Publish
er

ID

Book

Name

Borrowed
by

Status
ISBN

Call Num

Username
Email

Fines

User

Address

Password

Return Date

Call Num

Type

Type

Is A

Issue Date

Holder
Borrower
ISBN
Notify Date

ISBN

Return Date
Page | 30

6.3 Class Based Model:

6.3.1 Identifying Analysis Class :
Now we will analyze the main scenario or the story to get those classesA 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 isnt 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. 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 doesnt 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 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.
Here we can see that probable classes are

User
Book
Borrow
Authentication
Booking
Re-Issue
Fine
Librarian
Clearance
Database
Identifying analysis classes:

Page | 31

Analysis classes manifest themselves in one of the following ways.

External entities
Things
Occurrences Or Events
Roles
Organizational Units
Places
Structures

Potential Classes
User
Book
Authentication
Borrower
Booking
Re-Issue
Fine Generation
Librarian
Clearance
Database

Characteristics Number that Applies

Accepted 1,2,3,4,5,6
Accepted 1,2,3,7
Accepted all
Accepted 1,2,3,4,5,7
Accepted 1,2,3,4,5,7
Accepted 1,2,3,4,5,7
Accepted 1,2,3,4,7
Accepted 2,4 other all are rejected
Accepted 1,2,3 other all are rejected
Accepted 1,2,3,5,6,7

6.3.2 Specifying Attributes and Defining operations:

Class Cards

Class Name: User

Methods:

Attributes:

ChangePassword( ); String

ID : Bigint

BookCollection( ); void

Username: String
Password: String
Name: String
Type: String
Department: String

Page | 32

Class Name: Book

Methods:

Attributes:

SearchBook( ); String

Subject: String

DB(Object)

Title: String
Name: String
Author: String
ISBN: String
Category: String

Class Name: Authentication

Methods:

Attributes:

SignUp( ); Void

AuthenticationNumber : Bigint

SignIn( ); void

User(Object)

SignOut( );void

DB(Object)

Class Name: Borrower

Methods:

Attributes:

SearchBorrower( ); User

BorrowerNumber : Bigint

UpdateBorrower( ); void

CallNumber: Bigint

DeleteBorrower( ); Void

BorrowerStatus: boolean
User(Object)
Page | 33

Class Name: Booking

Methods:

Attributes:

SearchBorrower( ); User

RequestId : Bigint

UpdateBorrower( ); void

BorrowerStatus: boolean

User(Object)

DeleteBorrower( ); Void

Class Name: Fine Generation

Methods:

Attributes:

GenerateFines( ); User

User(Object)

CheckFines( ); void

DB(Object)

Class Name: Database

Methods:

Attributes:

checkFine( );Bigint

QueryString: String

Search( ); String

Result: Resultset

InsertBorrower( ); void

Page | 34

Class Name: Engine

Methods:

Attributes:

Renew( );void

User(Object)

User.GenerateFines( ); User

DB(Object)

Fine Generartion.CheckFines( ); void

Borrower(Object)

Booking.update( ); void

Fine Generation(Object)
Booking(Object)

6.3.3 CRC Model:

Authentication

Fine Generation

Book

Database

User

Booking

Borrower

Engine

Page | 35

6.4 Flow Oriented Model:

Data Flow Diagrams

Booking

Borrowing

Circulation
System

Fine
Generation

Re- Issue

Fig: Level 0

Page | 36

Get username,
password

No

Correct
Password?

Counter++

Yes

Logged in
Successfully

Sign Up Page

Counter>3
?
Yes

If Critical inputs are

filled
If reset password
is given

Give Confirmation
Mail

If Mail link is clicked

filled

Update the DB

Blocked

Send the reset

Password to
mail

No, Let
him try
again

Fig: Authentication Sub System

Page | 37

Borrowing
If searched

Show Book List

If specified

Show Book Details

If want to borrow

If not eligible

Check
Users

Exit

If eligible

Check if Book
Available

If not available

Booking

If available

Generate Call Slip

Update Database
Fig: Level 1 (Borrowing)
Page | 38

Booking

Book user into Holder List

If a copy is available

Send Mail
Wait 24 hours

Taken?

No

Delete Request

Yes

Update DB

Fig Level 2(Booking)

Page | 39

Check User

Authentication

Check Fines

No

Show Message to clear

Fines

No Fines

Check Limit of
Books

No

Show Message to return

Books

Limit not Exceed

Give Permission

Fig : Level 2 (Check User)

Page | 40

6.5 Behavioural Model:

6.5.1 State Transition Model:

If searched book in category

Show specified category of

Books
If selected specified book

Show Details of the Book

If the borrow button is clicked

Check Eligibility of user

If user fine is zero and maximum number of

books not exceeded

Check if the book is available

If available book number >0

If available book number ==0

Generate Call Slip

Enter in Booking List

Fig: Borrowing Process

Page | 41

Get username,
password

No

Correct
Password?

Counter++

Yes

Logged in
Successfully

Sign Up Page

Counter>3
?
Yes

If Critical inputs are

filled

Blocked
If reset password
is given

Give Confirmation
Mail

If Mail link is clicked

filled

Update the DB

Send the reset

Password to
mail

No, Let
him try
again

Fig : Authentication
Page | 42

Booking
Process

Push User into the Holding

List
If Available book number >0

Send mail to users mail

address
If waiting time==24hours

Pop and Delete the first user

Update Database

Fig: Booking Process

Page | 43

Insert a
borrower
Generate
Call slip

Insert a user
in booking
list

Search Book

Update Database

Insert a
query into
the String

Prepare A Query
Execute
query in sql
server

Execute Query
Execute
query in sql
server

Get Resultset
If resultset is
empty

If resultset is
not empty

Show Empty Result

Show Result in UI

Fig: Database
Page | 44

6.5.2 Sequence Model:

UI

Control
Panel

System

DB

Reading

System
Ready

Borrow

User
Checking

Book
Checking

Fig: Borrowing Process

UI

System
Ready

Control
Panel

Generate
Request

System

DB

Check if Book
Available

Notify
If not
Taken

Delete Request

Fig: Booking Process

Page | 45

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 preliminary
communication 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.

Page | 46