SRS of Library Circulation System

Institute of Information Technology , University of Dhaka
Library Circulation
System
Software Requirements Specification
7/8/2013

ii | P a g e
Library Circulation System
Software Requirements Specification
Software Requirements Specification and Analysis
SE 406
Submitted by:
Lamisha Rawshan (BIT0311)
Md. Shafiuzzaman (BIT0322)
Nadia Nahar (BIT0327)
Submitted to:
Dr. Kazi Muheymin-Us-Sakib
Associate Professor,
Institute of Information Technology,
University of Dhaka
Submission Date:
8th July, 2013

iii | P a g e
LETTER OF TRANSMITTAL
Dr. K M Sakib
Associate Professor
Institute of Information Technology (IIT)
University of Dhaka
July 8, 2013
Dear Sir,
We have prepared the enclosed report on Software Requirements Specifications of “Library
Circulation System” for your approval. This report details the requirements we gathered for the
project.
The primary purpose of this report is to summarize our findings from the work that we
completed as our Software Requirements Specifications and Analysis course project. This report
includes the details of each steps we followed to collect the requirements.
Sincerely Yours,
Lamisha Rawshan
Md. Shafiuzzaman
Nadia Nahar
Enclosure: SRS Report

iv | P a g e
Executive Summary
The purpose of Library Circulation System (LCS) is to provide a convenient, easy-to-use,
Internet-based application for Librarians to track and manage the circulation of resources at a
university, which include books, magazines, journals, Compact Disks (CD), videocassettes,
Digital Video Disks (DVD) etc. In addition, the purpose of LCS is also to provide a convenient,
Internet-based method for Students and Faculty of a university to search for items in the library’s
circulation, renew items they have checked out, and reserve items .This report provides the
Software Requirements Specifications (SRS) to develop the system.

v | P a g e
Acknowledgements
By the Grace of ALMIGHTY ALLAH we have completed our Report on Software
Requirements Specification of Library Circulation System.
We are grateful to the project supervisor Dr. K M Sakib Sir for his supervision throughout the
working time. He helped us a lot by sharing his valuable knowledge with us.

vi | P a g e
Table of Contents
Chapter 1: Introduction ..............................................................................................................1
1.1 Purpose.................................................................................................................................1
1.2 Intended Audience..............................................................................................................1
Chapter 2: Inception ....................................................................................................................3
2.1 Introduction.........................................................................................................................3
2.1.1 Identifying Stakeholders.............................................................................................3
2.1.2 Recognizing multiple viewpoints...............................................................................5
2.1.3 Working towards collaboration ................................................................................6
2.1.4 Asking the First Questions.........................................................................................7
2.2 Conclusion............................................................................................................................7
Chapter 3: Elicitation...................................................................................................................9
3.1 Introduction.........................................................................................................................9
3.2 Eliciting Requirements ......................................................................................................9
3.3 Collaborative Requirements Gathering..........................................................................9
3.4 Quality Function Deployment ........................................................................................10
3.4.1 Normal Requirements...............................................................................................10
3.4.2 Expected Requirements............................................................................................10
3.4.3 Exciting requirements...............................................................................................11
3.5 Usage Scenarios.................................................................................................................12
3.5.1 In case of Issue the available book..........................................................................12
3.5.2 In case of Issue the reserved book...........................................................................12
3.6 Elicitation work product .................................................................................................12
Chapter 4: Scenario-Based Model ...........................................................................................14

vii | P a g e
4.1 Introduction.......................................................................................................................14
4.2 Use Case Scenario.............................................................................................................14
4.3 Use Case Descriptions......................................................................................................15
4.3.1 Authentication............................................................................................................15
4.3.2 Configure ....................................................................................................................17
4.3.3 Update..........................................................................................................................19
4.3.4 Return..........................................................................................................................21
4.3.5 Borrow.........................................................................................................................22
4.4 Use Case Diagram.............................................................................................................25
4.3 Activity Diagram and Swimlane Diagram of generated Use Cases..........................29
Chapter 5: Data Model ..............................................................................................................62
5.1 Data Modeling Concepts .................................................................................................62
5.2 Data Objects......................................................................................................................62
5.3 E-R Diagram......................................................................................................................64
5.4 Data Schema......................................................................................................................65
Chapter 6: Class-Based Model .................................................................................................66
6.1 Introduction.......................................................................................................................66
6.2 Identifying Analysis Classes............................................................................................66
6.3 Class Responsibility Collaboration (CRC)...................................................................68
Chapter 7: Flow-Oriented Model.............................................................................................69
7.1 Introduction.......................................................................................................................69
7.2 Data Flow Diagram(DFD)...............................................................................................69
Chapter 8: Behavioral Model ...................................................................................................75
8.1 State Diagram....................................................................................................................75

viii | P a g e
8.2 Sequence Diagram............................................................................................................80
Chapter 9: Conclusion ...............................................................................................................85
Appendix......................................................................................................................................86
List of Figures
Figure Description Page
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
Level 0 for circulation system
Level 2.1(Authentication) for circulation system
Level 2.2(Configure) for circulation system
Level 2.3(Borrow) for circulation system
Level 2.4(Return) for circulation system
Level 2.5(Update) for circulation system
Activity Diagram of Sign Up
Swimlane Diagram of Sign Up
Activity Diagram of Sign In
Swimlane Diagram of Sign In
Activity Diagram of Sign Out
Swimlane Diagram of Sign Out
Activity Diagram of Change Password(s)
Swimlane Diagram of Change Password(s)
Activity Diagram of Change User Type
Swimlane Diagram of Change User Type
Activity Diagram of Configure the Due Date for an Item(s)
Swimlane Diagram of Configure the Due Date for an Item(s)
Activity Diagram of Configure the Fine for an Over Due Item(s)
Swimlane Diagram of Configure the Fine for an Over Due Item(s)
Activity Diagram of Change default Due date for Item
Swimlane Diagram of Change default Due date for Item
Activity Diagram of Add an Item
Swimlane Diagram of Add an Item
Activity Diagram of Edit an Item
Swimlane Diagram of Edit an Item
Activity Diagram of Delete an Item
Swimlane Diagram of Delete an Item
Activity Diagram of Issue an Item
Swimlane Diagram of Issue an Item
Activity Diagram of Retrieve an Item
Swimlane Diagram of Retrieve an Item
Activity Diagram of Reports on Over Due Item(s)
Swimlane Diagram of Reports on Over Due Item(s)
Activity Diagram of Search for Item(s)
Swimlane Diagram of Search for Item(s)
Activity Diagram of Renew Item(s)
25
25
26
26
27
28
28
29
30
31
32
33
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

ix | P a g e
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
Swimlane Diagram of Renew Item(s)
Activity Diagram of Booking Item(s)
Swimlane Diagram of Booking Item(s)
E-R Diagram
Data Schema
CRC
Level 1.1 (User) for circulation system
Level 1.2 (Admin) for circulation system
Level 1.3(Librarian) for circulation system
Level 2.1(User) for circulation system
Level 2.2 (Admin) for circulation system
Level 2.3(Librarian) for circulation system
Level 3.1(User) for circulation system
State diagram (Item Class)
State diagram (Admin Class)
State diagram (Librarian Class)
State diagram (System Class)
State diagram (Database Class)
State diagram (User Class)
Sequence diagram (Registration)
Sequence diagram (Sign In)
Sequence diagram (Borrow)
Sequence diagram (Return)
Sequence diagram (Configure)
Sequence diagram (Update)
59
60
61
64
65
68
69
70
70
71
71
72
73
74
75
75
76
77
78
79
80
81
82
83
83
84
List of Tables
Figure Description Page
1
2
3
Use Case Scenario
Identifying and categorize all nouns
Essential requirement for potential class
14
66
67

1 | P a g e
Chapter 1
Introduction
This chapter is intended to specify the purpose of this document and the intended audiences
of it.
1.1 Purpose
This document is the Software Requirements Specification (SRS) for the Library Circulation
System (LCS). It contains detailed functional, non-functional, and support requirements and
establishes a requirements baseline for development of the system. The requirements
contained in the SRS are independent, uniquely numbered, and organized by topic. The SRS
serves as the official means of communicating user requirements to the developer and
provides a common reference point for both the developer team and stakeholder
community. The SRS will evolve over time as users and developers work together to
validate, clarify and expand its contents.
1.2 Intended Audience
This SRS is intended for several audiences, including the customer, as well as the project
managers, designers, developers, and testers.
 The customer will use this SRS to verify that the developer team has created a product
that is acceptable to the customer.
 The project managers of the developer team will use this SRS to plan milestones and
a delivery date, and ensure that the developing team is on track during development of
the system.
 The designers will use this SRS as a basis for creating the system’s design. The
designers will continually refer back to this SRS to ensure that the system they are
designing will fulfill the customer’s needs.
 The developers will use this SRS as a basis for developing the system’s
functionality. The developers will link the requirements defined in this SRS to the
software they create to ensure that they have created software that will fulfill all of the
customer’s documented requirements.

2 | P a g e
 The testers will use this SRS to derive test plans and test cases for each documented
requirement. When portions of the software are complete, the testers will run their
tests on that software to ensure that the software fulfills the requirements documented
in this SRS. The testers will again run their tests on the entire system when it is
complete and ensure that all requirements documented in this SRS have been fulfilled.

3 | P a g e
Chapter 2
Inception
In this chapter, the Inception part of the SRS will be discussed briefly.
2.1 Introduction
Inception is the beginning phase of requirements engineering. It defines how does a software
project get started and what is the scope and nature of the problem to be solved. The goal of
the inception phase is to identify concurrence needs and conflict requirements among the
stakeholders of a software project. To establish the groundwork we have worked with the
following factors related to the inception phases:
 Identifying Stakeholders
 Recognizing multiple viewpoints
 Working towards collaboration
 Asking the First Questions
2.1.1 Identifying Stakeholders
Stakeholder refers to any person or group who will be affected by the system directly or
indirectly. Stakeholders include end-users who interact with the system and everyone else in
an organization that may be affected by its installation. To identify the stakeholders we
consulted with Assistant Librarian (Program) and asked her following questions:
 Who is paying for the project?
 Who will be using the project outcomes?
 Who gets to make the decisions about the project (if this is different from the money
source)?
 Who has resources I need to get the project done?
 Whose work will my project affect? (During the project and also once the project is
completed).

4 | P a g e
Concluding thoughts on Stakeholders, We identified following stakeholders for our
automated book circulation system of a library:
1. The University Librarian (Project Sponsor): The University Librarian is the person who
has the final authority over our budget, our personal resources, and ultimately the finished
product. His position empowers him to veto a decision made by the other Stakeholders.
2. The Associate University Librarian (Systems Head): As head of Library Systems, the
Associate University Librarian has direct authority over our Systems budget, and our team
— the people developing the site and doing much of the “management” end of this project.
3. The Circulation Manager(Adminstrator):The Circulation Manager has the
administrative power to handle the software.
4. System Operator: System Operator will directly interact with this software.
5. Student and Faculty: The largest user group of the system. They will search for items,
renew items and reserve items
6. Developers: 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.
7. University: University will finance the project and it has some has rules and regulation to
maintain our system. We have to follow them strictly.

5 | P a g e
2.1.2 Recognizing multiple viewpoints
We collect these view points by discussing with the chief librarian, associate librarian, chief
circulation manager and some students and teachers from different departments of University
of Dhaka.
1. The University Librarian (Project Sponsor)’s view points:
 Maintain a database of all items in the library’s circulation.
 Restrict access to functionality of the system based upon user roles. For example,
only Administrators of the system will be provided functionality to change user types,
configure how long items may be checked out and the fines for overdue items.
2. The Associate University Librarian (Systems Head)’s view points:
 Web-Based Interfaces
 Allow the system to be accessed via the Internet.
 Restrict access to functionality of the system based upon user roles.
 The application can be accessed from any computer that has Internet access.
3. The Circulation Manager(Adminstrator)’s view points :
 Allow Librarians to check-out and check-in items for valid users.
 The application only needs to be installed and maintained on one computer.
 Allow Librarians to generate reports on the items in the system (e.g., all overdue
items, all missing items.)
 A user guide describing how to use LCS need to be deployed with the system.
 A product reference manual describing how to install, setup, and run the application
shall be provided.
4. Borrowers’ view points:
 Allow the system to be accessed via the Internet.
 Easy Access
 Allow any user to search for items
 Allows valid users to renew items online by logging into the system

6 | P a g e
5. University’s view points:
 No disruption of rules and regulation
2.1.3 Working towards collaboration
Every stakeholder has their own requirements. We followed following steps to merge these
requirements:
 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.
Common requirements:
 Web-Based Interfaces
 The application can be accessed from any computer that has Internet access
 Allow any user to search for items
Conflicting Requirements:
We found some requirements conflicting each other .We had to trade-off between the
requirements.
 Easy access and Strong Authentication
 Allow any user to use the system and allow valid user to use the system
Final Requirements:
We finalized following requirements for the system by categorizing and prioritizing the
requirements:
 Error free system (Maximum 5% error may be considerable)
 Web-based interfaces
 Accessible via the Internet.
 Allow valid users to login and logout.
 Restrict access to functionality of the system based upon user roles

7 | P a g e
 Allow administrators of the system to change user types and configure parameters of
the system
 Allow any user to search for items in the library’s circulation without having to log in
to the system
 Allow valid users that log in to renew items, reserve items, and view the items they
have checked out.
 Allow Librarians to check-out and check-in items for valid users
 Allow Librarians to generate reports on the items in the system (e.g., all overdue
items, all missing items.)
 The application only needs to be installed and maintained on one computer
 Allows valid users to renew items online by logging into the system
 Restrict access to functionality of the system based upon user roles. For example,
only Administrators of the system will be provided functionality to change user types,
configure how long items may be checked out and the fines for overdue items.
2.1.4 Asking the First Questions
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.
2.2 Conclusion
Inception phase helped us to establish basic understanding about book circulation system in a
library, identify the people who will be benefited if book circulation system becomes
automated, define the nature of the book circulation software and establish a preliminary
communication with our stakeholders.

8 | P a g e
Group meeting
1.
Date: 06.09.2012
Place: IIT
Subject: Identifying Stakeholders
Members:
Lamisha Rawshan BIT-0311
Shafiuzzaman BIT-0322
Nadia Nahar BIT-0327
2.
Date: 13.09.2012
Place: Central Library, University of Dhaka
Subject: Collecting requirements from the stakeholders
Members:
3.
Date: 15.09.2012
Place: IIT, University of Dhaka
Subject: Discussion on requirements
Members:

9 | P a g e
Chapter 3
Elicitation
The purpose of this chapter is to specify the elicitation part.
3.1 Introduction
Elicitation is a task that helps the customer to define what is required. To complete the
elicitation step we face many problems like problems of scope, problems of volatility and
problems of understanding. However, this is not an easy task. To help overcome these
problems, we have worked with the Eliciting requirements activity in an organized and
systematic manner.
3.2 Eliciting Requirements
Unlike inception where Q&A (Question and Answer) approach is used, elicitation makes use
of a requirements elicitation format that combines the elements of problem solving,
elaboration, negotiation, and specification. It requires the cooperation of a group of end-users
and developers to elicit requirements .To elicit requirements we completed following four
works.
1. Collaborative Requirements Gathering
2. Quality Function Deployment
3. Usage Scenarios
4. Elicitation work products
3.3 Collaborative Requirements Gathering
Many different approaches to collaborative requirements gathering have been proposed. Each
makes use of a slightly different scenario .We completed following steps to do it.
 The meetings were conducted with the assistant librarian (program) of the Central
Library, University of Dhaka; the librarian was questioned about their requirements and
expectations from the automated book circulation system.
 The librarian was asked about the problems she is facing with the current manual system.

10 | P a g e
 At last we selected our final requirement list from the meetings.
3.4 Quality Function Deployment
Quality Function Deployment (QFD) is a technique that translates the needs of the customer
into technical requirements for software .It concentrates on maximizing customer satisfaction
from the Software engineering process .With respect to our project the following
requirements are identified by a QFD.
3.4.1 Normal Requirements
Normal requirements consist of objectives and goals that are stated during the meeting with
the customers. Normal requirements of our project are:-
1. Accessible via the Internet.
2. Allow any user to search for items.
3. Allow Librarians to check items for valid users.
4. Allow valid users to login and logout
5. Restrict access to functionality of the system based upon user roles
6. Allow valid users that log in to renew items, reserve items, and view the items
7. Allow Librarians to generate reports on the items in the system (e.g., all overdue items, all
missing items.)
8. The application only needs to be installed and maintained on one computer.
9. Help feature to explain what they are looking for
10. A product reference manual describing how to install, setup, and run the application will
be provided.
3.4.2 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.
1. Maintain a database of all items in the library’s circulation.
2. The system shall enable the Administrator to change a user’s type to any user type.
3. The system shall enable the Administrator to change user passwords.
4. The system shall enable the Administrator to configure the due date calculation for an
item.

11 | P a g e
5. The system shall enable the Librarian to change the number of items each user can check-
out.
6. The system shall enable the Administrator to configure the fine/item/day for an overdue
item.
7. The system shall enable any Librarian to give Librarian rights to other users.
8. The system shall allow the user to log in based upon an assigned login id and password.
9. The system shall automatically compute the due date for every item
10. The system shall automatically set the user status to “ABLE TO BORROW” and
“UNABLE TO BORROW”
11. The system shall automatically send e-mail to the user when an item is overdue.
12. The system shall compute fines automatically for overdue items.
13. The system shall automatically set the Item Status to
“AVAILABLE”,“UNAVAILABLE” ,”RENEWED”,”MISSING”.
14. The system shall enable Librarians to add, edit or delete an item.
15. The user interface of the system shall be easy to use and shall make use of drop-down
boxes, radio buttons, and other selectable fields wherever possible instead of fields that
require the user to type in data
3.4.3 Exciting requirements
These requirements are for features that go beyond the customer's expectations and prove to
be very satisfying when present
1. The user interface should provide appropriate error messages for invalid input as well as
tool-tips and online help
2. The user interface should follow standard web practices such that the web interface is
consistent with typical internet applications.
3. Offer log in with mobile phone
4. The system’s configuration shall be documented and updated as changes to the system are
made due to patches, new releases, etc.
5. Connect user account with facebook or other social media

12 | P a g e
3.5 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.
3.5.1 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.
3.5.2 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.6 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:
 Make a statement of our requirements for automated book circulation system.
 Make a bounded statement of scope for our system.
 Make a list of customer, user and other stakeholder who participated in requirements

13 | P a g e
elicitation.
 Set of usage scenarios.
 Description of the system’s technical environment
Group meetings
1.
Date: 24.09.2012
Place: Central Library, University of Dhaka
Subject: Meeting with Assistant Librarian (program) of the Central Library, University of
Dhaka
Members:
2.
Date: 26.09.2012
Subject: Defining the QFD
Members:
3.
Date: 27.09.2012
Subject: Preparing the user scenario
Members:

14 | P a g e
Chapter 4
Scenario-Based Model
This chapter describes the scenario based model for the library circulation system.
4.1 Introduction
In this model the system is described from the user’s point of view. As this is the first model,
it serves as input for creation of other modeling elements.
4.2 Use Case Scenario:
Level – 0 Level – 1 Level – 2 Actors
Circulation
System
Authentication Sign Up Student, Faculty
Sign In Administrator, Student,
Faculty, Librarian
Sign Out Administrator, Student,
Faculty, Librarian
Change Passwords Administrator, Student,
Faculty
Configure Change User Types Administrator, Librarian
Configure the Due Date for an Item Administrator
Configure the Fine for Overdue Items Administrator
Change default Item Due dates Librarian
Update Add an Item Librarian
Edit an Item Librarian
Delete an Item Librarian
Return Retrieve an Item Librarian
Reports on Over Due Items Student, Faculty
Borrow Search for Items Librarian, Student,
Faculty, Administrator
Issue an Item Librarian
Renew Items Student, Faculty
Booking Items Students, Faculty
Table 1: Use Case Scenario

15 | P a g e
4.3 Use Case Descriptions
In this section use case scenarios are described elaborately.
4.3.1 Authentication
Authentication system is divided into four sub-systems.
4.3.1.1 Sign Up
Use Case: Sign Up
Primary Actors: Student, Faculty
Goal in context:To register in the system
Precondition:
1. System has been programmed for add new user in database
2. System has interface for registration
Triggers:The student and faculty has a need to register
Scenario:
1. Visit the register page
2. Input required information
3. Check availability for username & check validity of Password
4. Authentication and Robot checking
5. E-mail sent to user e-mail address
6. User confirm from his/ her e-mail address
7. Confirmation message showed
Exception:
 User in not authorized for registration
 Ambiguous Input
 Authentication Fail
Priority: Essential, must be implemented
When Available: First increment

16 | P a g e
4.3.1.2 Sign In
Use Case: Sign In
Primary Actors: Student, Faculty, Administrator, Librarian
Goal in context:To enter the system
Precondition: Must be registered
Triggers:Need to log in the system
Scenario:
1. Visit the login page
2. Input Username & Password
3. Proceed to the next activity
Exception:
 Unrecognized Username
 Wrong Password
 User is blocked
4.3.1.3 Sign Out
Use Case: Sign Out
Primary Actors: Student, Faculty, Administrator, Librarian
Goal in context:To exit from the system
Precondition: Must be logged in
Triggers: Need to log out from the system
Scenario: Click the logout button
4.3.1.4 Change Password(s)
Use Case: Change Password(s)
Goal in context:To change the existing password to a new password
Precondition: System has been programmed for a password
Triggers:The student and faculty has a need to change the existing password to a new one

17 | P a g e
Scenario:
1. Visit the login page and login
2. Click on Edit button
3. Change Password
Exception: Weak Password: Password length is too short
4.3.2 Configure
4.3.2.1 Change User Type(s)
Use Case: Change User Type(s)
Primary Actors: Administrator, Librarian
Goal in context: To change the user type
Precondition: Must be logged in as Administrator/ librarian
Triggers: The administrator and librarian have a need to change the user type.
Scenario:
1. Visit Login page and Log in
2. Click the Edit User button
3. Select the User
4. Click on the Edit button
5. Change the type for the selected User
Exception:
 Invalid User: User may not be eligible for that type
 Unrecognized: User does not exist
4.3.2.2 Configure the Due Date for an Item(s)
Use Case: Configure the Due Date for an Item(s)
Primary Actors: Administrator
Goal in context:To configure the due date for an item

18 | P a g e
Precondition:
 Must be logged in as Administrator
 System has been programmed for editing due date
Triggers:The administrator has a need to configure the due date for an item.
Scenario:
 Visit Login page and Log in
 Click on Maintain Item button
 Select the Item
 Click on Edit Due Date for an Item button
 Change the Due Date for selected Item
 Proceed to the next activity
Exception:
 Item Unavailable: Requested item does not exist
 Ambiguous Input
Priority: Expected
When Available: Second increment
4.3.2.3 Configure the Fine for Overdue Item(s)
Use Case: Configure the Fine for Overdue Item(s)
Primary Actors: Administrator
Goal in context:To configure the fine for overdue item
Precondition:
 Must be logged in as Administrator
 System has been programmed for editing due fine
Triggers:The administrator has a need to configure the fine for overdue item.
Scenario:
 Click on Maintain Validation Data button
 Click on Configure the Fine for an Overdue Item button
 Update the Fine for selected Overdue Item
 Click on Update button
Exception: Ambiguous Input

19 | P a g e
Priority: Expected
4.3.2.4 Change default Due date for Item
Use Case: Change default Due date for Item
Primary Actors: Librarian
Goal in context:To change the default due date for item
Precondition: Must be logged in as Librarian
Triggers:The librarian has a need to change the default due date for item.
Scenario:
 Click on Change default Due date for Item button
 Update the Due date for selected Item
Exception: Ambiguous Input
Priority: Expected
4.3.3 Update
4.3.3.1 Add an Item(s)
Use Case: Add an Item(s)
Goal in context:To add new item(s)
Precondition:
 System has been programmed for adding item in database
 Must be logged in as Librarian
Trigger:The librarian has a need to add new item(s)
Scenario:
 Click on Add Item button to add new item
 Enter the new Item data (select Location) and confirm changes

20 | P a g e
Exception: Already Exist: Requested item is already added in the database
4.3.3.2 Edit an Item(s)
Use Case: Edit an Item(s)
Goal in context:To edit an item
Precondition:
 System has been programmed for editing item in database
Trigger:The librarian has a need to edit an item(s).
Scenario:
2. Click on Maintain Item button
3. Search and Select the Item to edit
4. Click on Edit Item button
5. Edit the Item details and confirm changes
Exception:
 Does not exist: Requested item does not exist in the database
 Ambiguous Input
4.3.3.3 Delete an Item(s)
Use Case: Delete an Item(s)
Goal in context:To delete an item
Precondition:
 System has been programmed for deleting item in database

21 | P a g e
Trigger:The librarian has a need to delete an item(s).
Scenario:
 Search and Select the Item to delete
 Click on Delete Item button
 Delete the selected Item and confirm changes
Exception: Does not exist: Requested item does not exist in the database
4.3.4 Return
4.3.4.1 Retrieve an Item(s)
Use Case: Retrieve an Item(s)
Goal in context:To retrieve an item
Precondition: Item must be issued for the particular user
Trigger:The librarian has a need to retrieve an item
Scenario:
 Click on Retrieve button
 Enter User name and Click Search for user
 Select the User
 Enter Item Name and Click Search item
 Select the Item
 Click Retriever button and Status changes from Issued to Retrieved
 A message is displayed

22 | P a g e
4.3.4.2 Reports on Over Due Item(s)
Use Case: Reports on Over Due Item(s)
Goal in context:To generate reports on overdue item(s)
Precondition:
 System has been programmed for automated report generation
Triggers: Report need to be automatically generated of overdue item(s).
Scenario:
 Database is automatically checked daily for Over Due
 Send mail to users having Over Due
 Increase fine if not cleared
 Update database
Exception: Error: System is not ready
4.3.5 Borrow
4.3.5.1 Search for Item(s)
Use Case: Search for Item(s)
Primary Actors: Librarian, Student, Faculty, Administrator
Goal in context:To perform a search for item(s)
Precondition: System has been programmed for searching all items in database
Triggers:The student, faculty, librarian, administrator has a need to search for item(s)
Scenario:
1. Visit the main page
2. Enter data and information such as title, author’s name etc.
3. Click the Search button
4. View the search result
Exception:
 Search item does not exist

23 | P a g e
 User is not eligible for searching that item
4.3.5.2 Issue an Item(s)
Use Case: Issue an Item(s)
Primary Actors:Librarian
Goal in context:To issue an item
Precondition:
 User must be eligible for taking requested item
 Item is available
Trigger:The librarian has a need to issue an item.
Scenario:
2. Click on Issue button
3. Search for the Person/User
4. Select User and list of items issued to the user is displayed
5. Click on Issue button and Status changes from Available to Issued to Library
6. A message is displayed
Exception:
 Invalid User: User status is not supported for this event
 Item does not exist
4.3.5.3 Renew Item(s)
Use Case: Renew Item(s)
Goal in context:To extend the item(s) that has/have reached the due date.
Precondition:
 Valid User
 Valid and Available Item

24 | P a g e
Triggers:The student, faculty, librarian has a need to extend item(s) due date.
Scenario:
 Visit the login page and log in
 List of Issued items for that User will be displayed
 Extend due date button will be shown for all the items which were not
renewed in the past
 Click on the Extend due date button to renew the item
 Item(s) due date will be extended for 14 days
Exception:
 Time Limit Exceeded: Renew chance has been finished
 Unavailable: Item is unavailable for renew
4.3.5.3 Booking Item(s)
Use Case: Booking Item(s)
Goal in context:To book item(s) that are unavailable at that particular time.
Precondition:
 Valid User
 Valid but unavailable Item at the particular time
Triggers:The student and faculty have a need to book item(s) that is/are unavailable at that
particular time.
Scenario:
 Visit the login page and log in
 Enter data and information such as title, author’s name etc. or
 Click the Search button
 View the search result
 Click on the Booking button
Exception: Missing: Item is missing

25 | P a g e
4.4 Use case Diagram
Fig 1: Level 0 for circulation system
Administrator
Librarian
Student
Faculty
Fig 2: Level 1 for circulation system
Circulation
System Database
Authentication
Configure
Borrow
Update
Return
User
Database
Item
Database
System
Database

26 | P a g e
Administrator
Librarian
Student
Faculty
Fig 3: Level 2.1(Authentication) for circulation system
Administrator
Librarian
Fig 4: Level 2.2(Configure) for circulation system
Sign up
Sign in
Sign out
Change
password
User
Database
Change user types
Configure due date
Configure fine for
overdue
Change default due
dates
Item
Database
System
Database
User
Database

27 | P a g e
Administrator
Librarian
Student
Faculty
Fig 5: Level 2.3(Borrow) for circulation system
Search
Issue
Renew
Booking
Item
Database
User
Database

28 | P a g e
Librarian
Student
Faculty
Fig 6: Level 2.4(Return) for circulation system
Librarian
Fig 7: Level 2.5(Update) for circulation system
Retrieve
Reports on over
due
Item
Database
User
Database
Add
Edit
Delete
Item
Database

29 | P a g e
4.5 Activity Diagram and Swimlane Diagram of generated Use Cases:
Use case 1: Sign Up
Activity Diagram:
Fig 8: Activity Diagram of Sign Up
OK
Failed
Valid
Password not Valid
(Max length 6)
Available
Username not
availableCheck availability
of Username
Click Registration
Enter Required Information
Check validity of
Password
Authentication and
Robot checking
Confirm E-mail Address
E-mail sent to Users Mail Address
Registration Complete

30 | P a g e
Swimlane Diagram:
Fig 9: Swimlane Diagram of Sign Up
User Interface
OK
Failed
Valid
Password not Valid
(Max length 6)
Available
Username not
availableAvailability
of Username
Click Registration
Enter Required Information
Validity of
Password
Authentication
and Robot
checking
Confirm E-mail Address
E-mail sent to Users Mail Address
Registration Complete

31 | P a g e
Use case 2: Sign In
Activity Diagram:
Fig 10: Activity Diagram of Sign In
Retries
remain
No retry
remain
Invalid
Password
Valid
Password
Logged in
Visit log in Page
Prompt for
Re-entry
Enter User ID
Enter Password
Invalid User ID
Valid User ID

32 | P a g e
Swimlane Diagram:
Fig 11: Swimlane Diagram of Sign In
User Interface
Retries
remain
No retry
remain
Invalid
Password
Valid
Password
Logged in
Visit log in Page
Prompt for
Re-entry
Enter User ID
Enter Password
Invalid User ID
Valid User ID

33 | P a g e
Use case 2: Sign Out
Activity Diagram:
Fig 12: Activity Diagram of Sign Out
Swimlane Diagram:
Fig 13: Swimlane Diagram of Sign Out
Click Log Out
Logged Out
User Interface
Click Log Out Logged Out

34 | P a g e
Use case 4: Change Password(s)
Activity Diagram:
Fig 14: Activity Diagram of Change Password(s)
Retries
remain
No retry
remain
Invalid
Password/ID
Valid
Password/ID
Valid
Password
Password length
is too short
Logged in
Click Edit
Button
Change
Password
Password Successfully
Changed
Weak
Password
Log in
Prompt for
Re-entry

35 | P a g e
Swimlane Diagram:
User Interface
Invalid
Password/ID
Valid
Password/ID
Logged in
Click Edit
Button
Change
Password
Password Successfully
Changed
Weak
Password
Log in
Prompt for
Re-entry
No retry
remain
Retries
remain
Fig 15: Swimlane Diagram of Change Password(s)

36 | P a g e
Use case 5: Change User Types
Activity Diagram:
User not
Recognized
User not Eligible
for Type
No retry
remain
Invalid
Password/ID
Valid
Password/ID
Logged in
Click Edit User
Select User
User Type Changed Invalid User
Log in as
Administrator
Prompt for
Re-entry
Click Edit
Change User Type
Retries
remain
Fig 16: Activity Diagram of Change User Type

37 | P a g e
Swimlane Diagram:
Administrator Interface
Invalid
Password/ID
Valid
Password/ID
Logged in
User Type Changed
Administrator
Log in
No retry
remain
Retries
remain
Click Edit User
Select User
Click Edit
Change User Type
User not Eligible
for Type
Invalid User
User not
Recognized
Prompt for
Re-entry
Fig 17: Swimlane Diagram of Change User Types

38 | P a g e
Use case 6: Configure the Due Date for an Item(s)
Activity Diagram:
No retry
remain
Item not
Available
Ambiguous Input
Invalid
Password/ID
Valid
Password/ID
Logged in
Click Maintain Item
Due Date
Configured
Invalid Input
Log in as
Administrator
Prompt for
Re-entry
Click Edit Due Date
Input Due Date
Retries
remain
Select Item
Fig 18: Activity Diagram of Configure the Due Date for an Item(s)

39 | P a g e
Swimlane Diagram:
Interface
Invalid
Password/ID
Valid
Password/ID
Retries
remain
Logged in
Due Date Configured
Administrator
Log in
Click Maintain Item
Select Item
Click Edit Due Date
Input Due Date
Item not
Available
Prompt for
Re-entry
Ambiguous Input
Invalid Input
No retry
remain
Administrator
Fig 19: Swimlane Diagram of Configure the Due
Date for an Item(s)

40 | P a g e
Use case 7: Configure the Fine for Overdue Item(s)
Activity Diagram:
No retry
remain
Item not
Available
Ambiguous Input
Invalid
Password/ID
Valid
Password/ID
Logged in
Click Maintain
Validation Data
Fine Updated for
Over Due Items
Invalid Input
Log in as
Administrator
Prompt for
Re-entry
Click Configure the Fine
Update the Fine
Retries
remain
Select Over Due Item
Fig 20: Activity Diagram of Configure the Fine for an Over Due Item(s)

41 | P a g e
Swimlane Diagram:
Interface
Invalid
Password/ID
Valid
Password/ID
Retries
remain
Logged in
Fine Updated for
Over Due Items
Administrator
Log in
Click Maintain
Validation Data
Select Over Due Item
Click Configure the Fine
Update the Fine
Item not
Available
Ambiguous Input
Invalid Input
Prompt for
Re-entry
No retry
remain
Administrator
Fig 21: Swimlane Diagram of Configure the
Fine for an Over Due Item(s)

42 | P a g e
Use case 8: Change default Due date for Item
Activity Diagram:
No retry
remain
Item not
Available
Ambiguous Input
Invalid
Password/ID
Valid
Password/ID
Logged in
Click Maintain Item
Due Date
Updated
Invalid Input
Log in as
Librarian
Prompt for
Re-entry
Click Change Due Date
Input Due Date
Retries
remain
Select Item
Fig 22: Activity Diagram of Change default Due date for Item

43 | P a g e
Swimlane Diagram:
Interface
Invalid
Password/ID
Valid
Password/ID
Retries
remain
Logged in
Due Date Updated
Log in as
Librarian
Click Maintain Item
Select Item
Click Change Due Date
Input Due Date
Item not
Available
Ambiguous Input
Invalid Input
Prompt for
Re-entry
No retry
remain
Librarian
Fig 23: Swimlane Diagram of Change default Due date for Item

44 | P a g e
Use case 9: Add an Item(s)
Activity Diagram:
No retry
remain
Item already exist
Invalid
Password/ID
Valid
Password/ID
Logged in
Click Maintain Item
Item Added Invalid Input
Log in as
Librarian
Prompt for
Re-entry
Select Location
Enter Item
Retries
remain
Click Add Item
Fig 24: Activity Diagram of Add an Item

45 | P a g e
Swimlane Diagram:
Interface
Invalid
Password/ID
Valid
Password/ID
Retries
remain
Logged in
Item Added
Log in as
Librarian
Click Maintain Item
Click Add Item
Select Location
Enter Item
Item already
exist
Invalid Input
Prompt for
Re-entry
No retry
remain
Librarian
Fig 25: Swimlane Diagram of Add an Item

46 | P a g e
Use case 10: Edit an Item(s)
Activity Diagram:
No retry
remain
Invalid
Password/ID
Valid
Password/ID
Logged in
Click Maintain Item
Item Edited
Log in as
Librarian
Prompt for
Re-entry
Edit Item Details
Retries
remain
Item does
not exist
Item not
Matched
Click Edit Item
Search & Select Item
Fig 26: Activity Diagram of Edit an Item

47 | P a g e
Swimlane Diagram:
Interface
Invalid
Password/ID
Valid
Password/ID
Retries
remain
Prompt for
Re-entry
Logged in
Item Edited
Log in as
Librarian
Click Maintain Item
Click Edit Item
Edit Item Details
Item does
not exist
Item not
Matched
No retry
remain
Librarian
Fig 27: Swimlane Diagram of Edit an Item

48 | P a g e
Use case 11: Delete an Item(s)
Activity Diagram:
No retry
remain
Invalid
Password/ID
Valid
Password/ID
Logged in
Click Maintain Item
Item Deleted
Log in as
Librarian
Prompt for
Re-entry
Click Delete Item
Retries
remain
Item does
not exist
Item not
Matched
Fig 28: Activity Diagram of Delete an Item

49 | P a g e
Swimlane Diagram:
Interface
Invalid
Password/ID
Valid
Password/ID
Retries
remain
Prompt for
Re-entry
Logged in
Item Deleted
Log in as
Librarian
Click Maintain Item
Click Delete Item
Item does
not exist
Item not
Matched
No retry
remain
Librarian
Fig 29: Swimlane Diagram of Delete an Item

50 | P a g e
Use case 12: Issue an Item(s)
Activity Diagram:
Yes
Yes
No
Yes
No
Found
No retry
remain
Search Item
Availability
Check the borrower
If valid
Change the status
of the book in DB
Generate call slip
Update the
user in DB
Booking
Invalid
Password/ID
Valid
Password/ID
Logged in
Log in as
Librarian
Prompt for
Re-entry
Retries
remain
No
Fig 30: Activity Diagram of Issue an Item

51 | P a g e
Swimlane Diagram:
Interface
Invalid
Password/ID
Valid
Password/ID
Retries
remain
Prompt for
Re-entry
Logged in
Log in as
Librarian
Librarian
Search Item
Yes
NoFound
Booking No
Yes
Availability
Yes
No
Check the borrower
If valid
Change the status
of the book in DB
Generate call slip
Update the
user in DB
No
Fig 31: Swimlane Diagram of Issue an Item

52 | P a g e
Use case 13: Retrieve an Item(s)
Activity Diagram:
Yes
No
Yes
No
Invalid
Password/ID
Valid
Password/ID
Log in as
Librarian
No retry
remain
Logged in Prompt for
Re-entry
Retries
remain
Enter Book ID
If Valid
Show message
Get issue details
Get user type
Check for fine
Add fine against
the user
Create a bill
Change the status
of the book in DB
Update the
user in DB
Fig 32: Activity Diagram of Retrieve an Item

53 | P a g e
Swimlane Diagram:
Interface
Valid
Password/ID
Logged in
Log in as
Librarian
Librarian
Invalid
Password/ID
Prompt for
Re-entry
Retries
remain
No
Yes
Enter Book ID
No
If Valid
Get issue details
Get user type
Yes
Add fine against
the user
Create a bill
No
Change the status
of the book in DB
Update the
user in DB
Check for fine
Fig 33: Swimlane Diagram of Retrieve an Item

54 | P a g e
Use case 14: Reports on Over Due Item(s) – Fine Generate
Activity Diagram:
Not
If yes
Check the DB daily for
searching fines
Give Warning (via mail)
Generate request
Increase
the fine
If not
Yes
Cleared?
If Request
limit exceeds
Update Database
Fig 34: Activity Diagram of Reports on Over Due Item(s)

55 | P a g e
Swimlane Diagram:
InterfaceUser
Check the DB daily for
searching fines
Give Warning (via mail)
If yes
If not
Cleared?
Not
Generate request
Increase the fine daily
Yes
If Request
limit Exceeds
Update Database
Fig 35: Swimlane Diagram of Reports on Over Due
Item(s)

56 | P a g e
Use case 15: Search for Item(s)
Activity Diagram:
Yes
Not eligible for
searching the Item
Enter Data to be Searched
Click Search
Result
No Result
FoundNo
If found
Fig 36: Activity Diagram of Search for Item(s)

57 | P a g e
Swimlane Diagram:
InterfaceUser
Yes
Not eligible for
searching the Item
Enter Data to be Searched
Click Search
Result
No Result
Found
No
If found
else
Fig 37: Swimlane Diagram of Search for Item(s)

58 | P a g e
Use case 16: Renew Item(s)
Activity Diagram:
No retry
remain
Invalid
Password/ID
Valid
Password/ID
Logged in
List of Issued Item
Due Date Extended
Log in
Prompt for
Re-entry
Retries
remain
Time Limit
Exceed
Can’t be
Extended
Click Extend Due Date
Select Item
Fig 38: Activity Diagram of Renew Item(s)

59 | P a g e
Swimlane Diagram:
InterfaceUser
Valid
Password/ID
Logged in
Log in
Invalid
Password/ID
Prompt for
Re-entry
Retries
remain
No
List of Issued Item
Due Date Extended
Time Limit
Exceed
Can’t be
Extended
Click Extend Due Date
Select Item
Fig 39: Swimlane Diagram of Renew Item(s)

60 | P a g e
Use case 17: Booking Item(s)
Activity Diagram:
Fig 40: Activity Diagram of Booking Item(s)
Item found
Not found
Retries
remain
Request Generated
Invalid
Password/ID
Valid
Password/ID
Logged in
Log in
Prompt for
Re-entry
Click Booking
Search Item
Item missing
Not available
Item Available
Issue

61 | P a g e
Swimlane Diagram:
InterfaceUser
Valid
Password/ID
Logged in
Log in
Invalid
Password/ID
Prompt for
Re-entry
Retries
remain
No
Item found
Not found
Request Generated
Search Item
Not available
Item Available
Issue
Item missing
Click Booking
Fig 41: Activity Diagram of Booking Item(s)

62 | P a g e
Chapter 5
Data Model
5.1 Data Modeling Concepts
If software requirements include the need to create, extend, or interface with a database or if
complex data structures must be constructed and manipulated, the software team may choose
to create a data model as part of overall requirements modeling.
5.2 Data Objects
A data object is a representation of information which has different properties or attributes
that must be understood by software. We found following data objects in our Library
Circulation System.
Data Object: User
Attributes:
 User_id
 Password
 Name
 Address
 Email
 User-Type
 Date of Birth
 Department/Institution
Data Object: Item
Attributes:
 Call Number
 ISBN
 Title
 Author
 Publisher
 Location
 Subject
 Resource Type
 Item status

63 | P a g e
Data Object: Report
Attributes:
 User_id
 Issue date
 Fine amount
Data Object: Librarian
Attributes:
 Id
 Password
 Name
 Ema

64 | P a g e
5.3 E-R Diagram
User
ID
Username
Max Items
Password
Date of Birth
Department/
Institution
User Type
E-mail
Address
Name
Collected Items
Borrower
Return Date
Issue Date
Item
Call No.
ISBN
Item
Status
Resource Type
Location
Title
Publisher
Subject
Author
Administrator/
Librarian
E-mail
Name
PasswordID
Update User
Database
Date
Update Item
Database
Date
Report
StatusFine AmountDate
Generate
Report
Interface
Type
ID
No. of Copy

65 | P a g e
5.4 Data
Schema
USER
User_id : String
Password : String
Name : String
Address : String
Email : String
User-Type : String
Date of Birth: String
Department/Institution:
String
BORROWING
User_id
Call number
Issue Date
Return Date
ITEM
Call Number
ISBN
Title
Author
Publisher
Location
Subject
Resource Type
Item status
UPDATE USER
DATABASE
User-id
Library-ID
UPDATE ITEM
DATABASE
Call number
Library-ID
REPORT
User-id
Fine-amount
Issue-date
LIBRARIAN
ID
Password
Name
E-mail
Update
Fig 43: Data Schema

66 | P a g e
Chapter 6
Class-Based Model
This Chapter is intended to describe class based modeling of library circulation system.
6.1 Class Based Modeling Concept
Class-based modeling represents the objects that the system will manipulate, the operations that
will applied to the objects, relationships between the objects and the collaborations that occur
between the classes that are defined.
6.2 Identifying Analysis Classes
Step-1: Identifying and categorize all nouns
External Entities Student, Faculty, Database, Interface, User
Things Report, Interface, E-mail, Button, Fine, Password,
Message, Item
Occurrence or
events
Search, Issue, Retrieve, Renew, Update, Configure,
Booking, Generate Report, Return
Roles Administrator, Librarian
Organizational
units
Department/Institute, Item type, User type
Places Item location
Structures System, Internet, Server, Computer
Table 2: Identifying and categorize all nouns
Step-2: Selection of potential class
Selection characteristics:
1. Retained information
2. Needed services
3. Multiple attributes
4. Common attributes
5. Common operations

67 | P a g e
6. Essential requirements
Potential Class Characteristic Number That Applies
Student Rejected: 3 fails
Faculty Rejected: 3 fails
Database Accepted: all apply
System Accepted: all apply
Interface Rejected:1,4,5 fails
Report Rejected:1,3,6 fails
E-mail Rejected:1,3,6 fails
Password Rejected: 3 fails
Button Rejected: 1,3,5,6 fails
Fine Rejected: 1,3,4,6 fails
Administrator Accepted: all apply
Librarian Accepted: all apply
Item Accepted: all apply
Search Rejected: 3 fails
Issue Rejected: 3 fails
Retrieve Rejected: 3 fails
Renew Rejected: 3 fails
Booking Rejected: 3 fails
Update Rejected: 3 fails
Department/Institute Rejected: 4,5,6 fails
Location Rejected: 3 fails
Type Rejected: 3 fails
User Accepted: all apply
Server Rejected: 3 fails
Computer Rejected: 3 fails
Internet Rejected: 3 fails
Table 3: Essential requirement for potential class

68 | P a g e
6.3 Class Responsibility Collaboration (CRC)
Item
Call number
Title
Publish
Author
Admin
Configure()
System
generate email()
generate report()
Librarian
ID
Password
Name
Mail
issue()
retrieve()
update()
add()
edit()
delete()
User
ID
Password
Name
borrower()
renew()
sign up()
sign in()
sign out()
search()
booking()
Database
ID
Type
Total-
amount
update()
insert()
check()
select()
delete()
Database
ID
Type
Total-
amount
update()
insert()
check()
select()
delete()
Fig 44: CRC

69 | P a g e
Chapter 7
Flow-Oriented Model
This chapter focuses on the flow oriented modeling.
7.1 Introduction
Although data flow-oriented modeling is perceived as an outdated technique by some software
engineers, it continues to be one of the most widely used requirements analysis notations in use
today. It provides additional insight into system requirements and flow.
7.2 Data Flow Diagram (DFD)
The DFD takes an input-process-output view of a system. In the figures, data objects are
represented by labeled arrows and transformations are represented by circles.
Figure 45: Level 0 for circulation system
User
Admin
Librarian
Circulation System
Database

70 | P a g e
Figure 46: Level 1.1 (User) for circulation system
Figure 47: Level 1.2 (Admin) for circulation system
User
Input and
accept
User
Database
Item
Database
Admin
Input and
accept
System
Database

71 | P a g e
Figure 48: Level 1.3(Librarian) for circulation system
Figure 49: Level 2.1(User) for circulation system
Librarian
Input and
accept
User
Database
User
Authentication
User
Database
Borrow Item
Database

72 | P a g e
Figure 50: Level 2.2 (Admin) for circulation system
Admin
Authentication
System
Database
Borrow

73 | P a g e
Figure 51: Level 2.3(Librarian) for circulation system
Librarian
Authentication
Update
Issue
Return
User
Database

74 | P a g e
Figure 52: Level 3.1(User) for circulation system
User
Sign up
Sign In
Search
Booking
Change
Password
Renew
User
Database
Item
Database

75 | P a g e
Chapter 8
Behavioral Model
The behavioral model indicates how software will respond to external events.
8.1 State Diagram
State diagram represents active states for each class the events (triggers).
Need of
configuration
Done
available
Not available
request
return
Idle
Change
Status
Checking
Do: availability
Issue
Fig 53: State diagram (Item Class)
Issued
Idle Configure
Update
Databas
updated
Fig 54: State diagram (Admin Class)

76 | P a g e
booked
collected
Item
update
updated
issued Item
available
return item
has
fine
no fine
Item not available
User valid
User not valid
request
Idle User DB Check
Do: check
Item DB Check
Do: check
issueDB
Update
Add, Edit,
Delete
Collect
Fine
Retrieve Check Fine
Fig 55: State diagram (Librarian Class)
Booking

77 | P a g e
Done
Done
Match
with DBLog in requested
time up
ID, Password doesn’t match
and No. of Tries < MaxTry
Item taken
Idle Set
Timer
Comparing
Do: validatePassword
Generate
Report
Send
E-mail
Feedback
Fig 56: State diagram (System Class)

78 | P a g e
done
done
request
Request search
done
valid
Information not valid
request
Idle User DB Check
Do: check
Insert,
update
Delete
Send to
Interface
d
Select
Fig 57: State diagram (Database Class)

79 | P a g e
Search for
Item
Register into
System
Exit from
System
time up
Enter in
System
Idle Sign In Borrow
Renew
Search
Sign Up
Booking
Sign
Out
Fig 58: State diagram (User Class)

80 | P a g e
8.2 Sequence Diagram
Sequence diagram indicates how events cause transitions from object to object.
Insert into
database
send
result
Information
lookup
Enter
Information
System
ready
User System Database
Reading
Checking
Confirmation
Mail
Confirm
Update
Fig 59: Sequence diagram (Registration)

81 | P a g e
Password
correct
No. of
tries>maxTry
result
lookup
Enter
Username,
Password
System
ready
User System Database
Reading
Compare
Block
Access in
Database
Fig 60: Sequence diagram (Sign In)

82 | P a g e
not available
available
Check item
availability
update
update
valid
Check user
validityrequest
Librarian User DB Item DB
Issue
Booking
Fig 61: Sequence diagram (Borrow)

83 | P a g e
Check for
finerequest
Librarian User DB Item DB
Collect
no fine
Update
has fine
Update
Fig 62: Sequence diagram (Return)
Need
configuration
Admin System DB
Update configured data
Update
Fig 63: Sequence diagram (Configure)

84 | P a g e
Requirement
of add, edit,
delete
Libration Item DB
Update new/change in data
Update
Fig 64: Sequence diagram (Update)

85 | P a g e
Chapter 9
Conclusion
We are pleased to submit the final SRS report on Library circulation system. From this, the
readers will get a clear and easy view of library circulation system. To improve Library
System efficiency, library management needs to automate the acquisition and circulation
tasks. A library with automated software system is more effective than paper based manual
system. This SRS document can be used effectively to maintain software development cycle.
It will be very easy to conduct the whole project using this SRS. Hopefully, this document
can also help our junior BSSE batch students. We tried our best to remove all dependencies
and make effective and fully designed SRS. We believe that reader will find it in order.

86 | P a g e
Appendix
References
1. Pressman, Roger S. Software Engineering: A Practitioner's Approach (7th ed.). Boston,
Mass: McGraw-Hill. ISBN 0-07-285318-2
2. Ralph, Paul (2012). "The Illusion of Requirements in Software Development".
Requirements Engineering
3. Sommerville, I. Software Engineering, 7th ed. Harlow, UK: Addison Wesley, 2006
4. http://www.mnhe.com/pressman, accessed on 7th
November, 2012
5. http://www.mks.com/solutions/discipline/rm/requirements-engineering, accessed on 6th
November, 2012
6. http://www-01.ibm.com/software/awdtools/reqpro/, accessed on 29th
October, 2012

SRS of Library Circulation System

More Related Content

What's hot

Viewers also liked

Similar to SRS of Library Circulation System

More from Md. Shafiuzzaman Hira

Recently uploaded

In this document

SRS of Library Circulation System