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 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
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 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 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 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
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 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
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 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
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 didn’t 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 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. 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 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 user’s 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