Institute of Information Technology , University of Dhaka

Library Circulation
System
Software Requirements Specification

7/8/2013
 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

ii | 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

iii | 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.

iv | 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.

v|Page
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

vi | 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

vii | P a g e
 8.2 Sequence Diagram ............................................................................................................ 80

Chapter 9: Conclusion ............................................................................................................... 85

Appendix ...................................................................................................................................... 86

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

viii | P a g e
 39 Swimlane Diagram of Renew Item(s) 59
40 Activity Diagram of Booking Item(s) 60
41 Swimlane Diagram of Booking Item(s) 61
42 E-R Diagram 64
43 Data Schema 65
44 CRC 68
45 Level 0 for circulation system 69
46 Level 1.1 (User) for circulation system 70
47 Level 1.2 (Admin) for circulation system 70
48 Level 1.3(Librarian) for circulation system 71
49 Level 2.1(User) for circulation system 71
50 Level 2.2 (Admin) for circulation system 72
51 Level 2.3(Librarian) for circulation system 73
52 Level 3.1(User) for circulation system 74
53 State diagram (Item Class) 75
54 State diagram (Admin Class) 75
55 State diagram (Librarian Class) 76
56 State diagram (System Class) 77
57 State diagram (Database Class) 78
58 State diagram (User Class) 79
59 Sequence diagram (Registration) 80
60 Sequence diagram (Sign In) 81
61 Sequence diagram (Borrow) 82
62 Sequence diagram (Return) 83
63 Sequence diagram (Configure) 83
64 Sequence diagram (Update) 84

List of Tables

Figure Description Page

1 Use Case Scenario 14
2 Identifying and categorize all nouns 66
3 Essential requirement for potential class 67

ix | 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.

1|Page
  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.

2|Page
 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).

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

4|Page
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

5|Page
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

 Maintain a database of all items in the library’s circulation.

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

6|Page
  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

 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.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.

7|Page
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:
Lamisha Rawshan BIT-0311
Shafiuzzaman BIT-0322
Nadia Nahar BIT-0327

3.
Date: 15.09.2012
Place: IIT, University of Dhaka
Subject: Discussion on requirements
Members:
Lamisha Rawshan BIT-0311
Shafiuzzaman BIT-0322
Nadia Nahar BIT-0327

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

9|Page
 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.

10 | 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

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

12 | 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:
Lamisha Rawshan BIT-0311
Shafiuzzaman BIT-0322
Nadia Nahar BIT-0327
2.
Date: 26.09.2012
Place: IIT, University of Dhaka
Subject: Defining the QFD
Members:
Lamisha Rawshan BIT-0311
Shafiuzzaman BIT-0322
Nadia Nahar BIT-0327
3.
Date: 27.09.2012
Place: IIT, University of Dhaka
Subject: Preparing the user scenario
Members:
Lamisha Rawshan BIT-0311
Shafiuzzaman BIT-0322
Nadia Nahar BIT-0327

13 | 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
Authentication Sign Up Student, Faculty
Sign In Administrator, Student,
Faculty, Librarian
Circulation Sign Out Administrator, Student,
System 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

14 | 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

15 | 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
Priority: Essential, must be implemented
When Available: First increment

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
Priority: Essential, must be implemented
When Available: First increment

4.3.1.4 Change Password(s)

Use Case: Change Password(s)
Primary Actors: Student, Faculty
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

16 | P a g e
Scenario:
1. Visit the login page and login
2. Click on Edit button
3. Change Password
4. Proceed to the next activity
Exception: Weak Password: Password length is too short
Priority: Essential, must be implemented
When Available: First increment

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
6. Proceed to the next activity
Exception:
 Invalid User: User may not be eligible for that type
 Unrecognized: User does not exist
Priority: Essential, must be implemented
When Available: First increment

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

17 | 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:
 Visit Login page and Log in
 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
 Proceed to the next activity
Exception: Ambiguous Input

18 | P a g e
Priority: Expected
When Available: Second increment

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:
 Visit Login page and Log in
 Click on Maintain Item button
 Click on Change default Due date for Item button
 Update the Due date for selected Item
 Proceed to the next activity
Exception: Ambiguous Input
Priority: Expected
When Available: Second increment

4.3.3 Update
4.3.3.1 Add an Item(s)
Use Case: Add an Item(s)
Primary Actors: Librarian
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:
 Visit Login page and Log in
 Click on Maintain Item button
 Click on Add Item button to add new item
 Enter the new Item data (select Location) and confirm changes

19 | P a g e
  Proceed to the next activity
Exception: Already Exist: Requested item is already added in the database
Priority: Essential, must be implemented
When Available: First increment

4.3.3.2 Edit an Item(s)

Use Case: Edit an Item(s)
Primary Actors: Librarian
Goal in context: To edit an item
Precondition:
 System has been programmed for editing item in database
 Must be logged in as Librarian
Trigger: The librarian has a need to edit an item(s).
Scenario:
1. Visit Login page and Log in
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
6. Proceed to the next activity
Exception:
 Does not exist: Requested item does not exist in the database
 Ambiguous Input
Priority: Essential, must be implemented
When Available: First increment

4.3.3.3 Delete an Item(s)

Use Case: Delete an Item(s)
Primary Actors: Librarian
Goal in context: To delete an item
Precondition:
 System has been programmed for deleting item in database
 Must be logged in as Librarian

20 | P a g e
Trigger: The librarian has a need to delete an item(s).
Scenario:
 Visit Login page and Log in
 Click on Maintain Item button
 Search and Select the Item to delete
 Click on Delete Item button
 Delete the selected Item and confirm changes
 Proceed to the next activity
Exception: Does not exist: Requested item does not exist in the database
Priority: Essential, must be implemented
When Available: First increment

4.3.4 Return
4.3.4.1 Retrieve an Item(s)
Use Case: Retrieve an Item(s)
Primary Actors: Librarian
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:
 Visit Login page and Log in
 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
 Proceed to the next activity
Priority: Essential, must be implemented
When Available: First increment

21 | P a g e
4.3.4.2 Reports on Over Due Item(s)
Use Case: Reports on Over Due Item(s)
Primary Actors: Student, Faculty
Goal in context: To generate reports on overdue item(s)
Precondition:
 System has been programmed for automated report generation
 Must be logged in as Librarian
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
 Proceed to the next activity
Exception: Error: System is not ready
Priority: Essential, must be implemented
When Available: First increment

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
5. Proceed to the next activity
Exception:
 Search item does not exist

22 | P a g e
  User is not eligible for searching that item
Priority: Essential, must be implemented
When Available: First increment

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:
1. Visit Login page and Log in
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
7. Proceed to the next activity
Exception:
 Invalid User: User status is not supported for this event
 Item does not exist
Priority: Essential, must be implemented
When Available: First increment

4.3.5.3 Renew Item(s)

Use Case: Renew Item(s)
Primary Actors: Student, Faculty
Goal in context: To extend the item(s) that has/have reached the due date.
Precondition:
 Valid User
 Valid and Available Item

23 | 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
Priority: Essential, must be implemented
When Available: First increment

4.3.5.3 Booking Item(s)

Use Case: Booking Item(s)
Primary Actors: Student, Faculty
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
 Proceed to the next activity
Exception: Missing: Item is missing
Priority: Essential, must be implemented
When Available: First increment

24 | P a g e
4.4 Use case Diagram

Circulation
System Database

Fig 1: Level 0 for circulation system

Authentication
User
Administrator Database

Configure

Librarian Borrow
Item
Database

Return

Student

System
Database
Update

Faculty
Fig 2: Level 1 for circulation system

25 | P a g e
 Sign up
Administrator

Sign in

User
Librarian Database

Sign out

Student Change
password

Faculty
Fig 3: Level 2.1(Authentication) for circulation system

Change user types User

Database

Configure due date

Administrator Item
Database

Configure fine for

overdue

System
Database
Librarian Change default due
dates

Fig 4: Level 2.2(Configure) for circulation system

26 | P a g e
 Search

Item
Administrator Database

Issue

Renew
Librarian
User
Database

Booking

Student

Faculty

Fig 5: Level 2.3(Borrow) for circulation system

27 | P a g e
 Retrieve
Item
Database
Librarian

Reports on over
due User
Database
Student

Faculty

Fig 6: Level 2.4(Return) for circulation system

Add

Edit
Item
Database

Librarian

Delete

Fig 7: Level 2.5(Update) for circulation system

28 | P a g e
4.5 Activity Diagram and Swimlane Diagram of generated Use Cases:
Use case 1: Sign Up

Activity Diagram:

Click Registration

Enter Required Information

Username not
Check availability available
of Username
Available
Password not Valid
Check validity of (Max length 6)

Password
Valid

Failed
Authentication and
Robot checking
OK

E-mail sent to Users Mail Address

Confirm E-mail Address

Registration Complete

Fig 8: Activity Diagram of Sign Up

29 | P a g e
Swimlane Diagram:

User Interface

Click Registration

Enter Required Information

Username not
Availability available
of Username
Available
Password not Valid
Validity of (Max length 6)

Password
Valid

Authentication Failed
and Robot
checking
E-mail sent to Users Mail Address

Confirm E-mail Address OK

Registration Complete

Fig 9: Swimlane Diagram of Sign Up

30 | P a g e
Use case 2: Sign In

Activity Diagram:

Visit log in Page

Enter User ID

Enter Password

Invalid User ID

Valid User ID

Invalid
Password

Valid
Password
Prompt for
Re-entry
Logged in

Retries
No retry
remain
remain

Fig 10: Activity Diagram of Sign In

31 | P a g e
Swimlane Diagram:

User Interface

Visit log in Page

Enter User ID

Enter Password

Invalid User ID

Valid User ID

Invalid
Password

Valid
Password
Prompt for
Re-entry
Logged in

Retries
No retry
remain
remain

Fig 11: Swimlane Diagram of Sign In

32 | P a g e
Use case 2: Sign Out

Activity Diagram:

Click Log Out

Logged Out

Fig 12: Activity Diagram of Sign Out

Swimlane Diagram:

User Interface

Click Log Out Logged Out

Fig 13: Swimlane Diagram of Sign Out

33 | P a g e
 Use case 4: Change Password(s)

Activity Diagram:

Log in

Valid Invalid
Password/ID Password/ID

Logged in
Prompt for
Re-entry

Click Edit
Button
Retries
No retry remain
remain
Change
Valid
Password
Password

Password length
is too short

Password Successfully Weak

Changed Password

Fig 14: Activity Diagram of Change Password(s)

34 | P a g e
Swimlane Diagram:

User Interface

Log in

Valid
Password/ID Invalid
Password/ID

Logged in
Prompt for
Re-entry
Click Edit
Button
No retry Retries
remain remain

Change
Password

Password Successfully
Weak
Changed
Password

Fig 15: Swimlane Diagram of Change Password(s)

35 | P a g e
 Use case 5: Change User Types

Activity Diagram:

Log in as
Administrator
Valid Invalid
Password/ID Password/ID

Logged in
Prompt for
Re-entry
Click Edit User

User not
Select User Recognized
Retries
No retry remain
remain

Click Edit

Change User Type

User not Eligible

for Type

User Type Changed Invalid User

Fig 16: Activity Diagram of Change User Type

36 | P a g e
Swimlane Diagram:

Administrator Interface

Administrator
Log in
Valid
Password/ID Invalid
Password/ID

Logged in
Prompt for
Click Edit User Re-entry
User not
Recognized

Select User Retries

No retry
remain
remain

Click Edit

Change User Type

User not Eligible
for Type
User Type Changed
Invalid User

Fig 17: Swimlane Diagram of Change User Types

37 | P a g e
Use case 6: Configure the Due Date for an Item(s)

Activity Diagram:

Log in as
Administrator
Valid Invalid
Password/ID Password/ID

Logged in
Prompt for
Re-entry
Click Maintain Item

Item not
Select Item Available Retries
No retry remain
remain
Click Edit Due Date

Input Due Date

Ambiguous Input

Due Date Invalid Input

Configured

Fig 18: Activity Diagram of Configure the Due Date for an Item(s)

38 | P a g e
Swimlane Diagram:

Administrator Interface

Administrator
Log in
Valid
Password/ID Invalid
Password/ID

Logged in
Prompt for
Click Maintain Item Re-entry
Item not
Available

Select Item Retries

No retry remain
remain

Click Edit Due Date

Input Due Date

Ambiguous Input

Due Date Configured

Invalid Input

Fig 19: Swimlane Diagram of Configure the Due

Date for an Item(s)
39 | P a g e
 Use case 7: Configure the Fine for Overdue Item(s)

Activity Diagram:

Log in as
Administrator
Valid Invalid
Password/ID Password/ID

Logged in
Prompt for
Click Maintain Re-entry
Validation Data

Item not
Select Over Due Item Available Retries
No retry remain
remain
Click Configure the Fine

Update the Fine

Ambiguous Input

Fine Updated for Invalid Input

Over Due Items

Fig 20: Activity Diagram of Configure the Fine for an Over Due Item(s)

40 | P a g e
Swimlane Diagram:

Administrator Interface

Administrator
Log in
Valid
Password/ID Invalid
Password/ID
Logged in

Prompt for
Click Maintain Re-entry
Item not
Validation Data
Available

Select Over Due Item Retries

No retry remain
remain

Click Configure the Fine

Update the Fine

Ambiguous Input
Fine Updated for
Over Due Items Invalid Input

Fig 21: Swimlane Diagram of Configure the

Fine for an Over Due Item(s)
41 | P a g e
Use case 8: Change default Due date for Item

Activity Diagram:

Log in as
Librarian
Valid Invalid
Password/ID Password/ID

Logged in
Prompt for
Re-entry
Click Maintain Item

Item not
Select Item Available Retries
No retry remain
remain
Click Change Due Date

Input Due Date

Ambiguous Input

Due Date Invalid Input

Updated

Fig 22: Activity Diagram of Change default Due date for Item

42 | P a g e
Swimlane Diagram:

Librarian Interface

Log in as
Librarian
Valid
Password/ID Invalid
Password/ID

Logged in
Prompt for
Click Maintain Item Re-entry
Item not
Available

Select Item Retries

No retry remain
remain

Click Change Due Date

Input Due Date

Ambiguous Input

Due Date Updated

Invalid Input

Fig 23: Swimlane Diagram of Change default Due date for Item

43 | P a g e
Use case 9: Add an Item(s)

Activity Diagram:

Log in as
Librarian
Valid Invalid
Password/ID Password/ID

Logged in
Prompt for
Re-entry
Click Maintain Item

Click Add Item Retries

No retry remain
remain
Select Location

Enter Item

Item already exist

Item Added Invalid Input

Fig 24: Activity Diagram of Add an Item

44 | P a g e
Swimlane Diagram:

Librarian Interface

Log in as
Librarian
Valid
Password/ID Invalid
Password/ID

Logged in
Prompt for
Click Maintain Item Re-entry

Click Add Item No retry Retries

remain remain

Select Location

Enter Item
Item already
exist
Item Added
Invalid Input

Fig 25: Swimlane Diagram of Add an Item

45 | P a g e
Use case 10: Edit an Item(s)

Activity Diagram:

Log in as
Librarian
Valid Invalid
Password/ID Password/ID

Logged in
Prompt for
Re-entry
Click Maintain Item

Search & Select Item No retry Retries

remain remain
Item does
Click Edit Item not exist

Item not
Edit Item Details Matched

Item Edited

Fig 26: Activity Diagram of Edit an Item

46 | P a g e
Swimlane Diagram:

Librarian Interface

Log in as
Librarian
Valid
Password/ID Invalid
Password/ID

Logged in
Prompt for
Click Maintain Item Re-entry

Search & Select Item Retries

No retry remain
remain
Click Edit Item

Edit Item Details

Item does
not exist
Item Edited
Item not
Matched

Fig 27: Swimlane Diagram of Edit an Item

47 | P a g e
Use case 11: Delete an Item(s)

Activity Diagram:

Log in as
Librarian
Valid Invalid
Password/ID Password/ID

Logged in
Prompt for
Re-entry
Click Maintain Item

Search & Select Item Retries

No retry
remain
remain
Item does
Click Delete Item
not exist

Item not
Item Deleted Matched

Fig 28: Activity Diagram of Delete an Item

48 | P a g e
Swimlane Diagram:

Librarian Interface

Log in as
Librarian
Valid
Password/ID Invalid
Password/ID

Logged in
Prompt for
Click Maintain Item Re-entry

Search & Select Item Retries

No retry remain
remain

Click Delete Item

Item Deleted
Item does
not exist

Item not
Matched

Fig 29: Swimlane Diagram of Delete an Item

49 | P a g e
Use case 12: Issue an Item(s)

Activity Diagram:

Log in as
Librarian
Valid Invalid
Password/ID Password/ID

Logged in Prompt for

Re-entry
Search Item

No
Found Retries
No retry
remain
Yes remain

Availability Booking
No
Yes
Check the borrower

No
If valid
Yes

Generate call slip

Change the status

of the book in DB

Update the
user in DB

Fig 30: Activity Diagram of Issue an Item

50 | P a g e
Swimlane Diagram:

Librarian Interface

Log in as
Librarian
Valid Invalid
Password/ID Password/ID

Logged in Prompt for

Re-entry

Search Item
Retries
No
remain

Found No

Yes
Booking No
Availability
Yes
Check the borrower

Generate call slip Yes

If valid
Change the status No
of the book in DB

Update the
user in DB

51 | P a g e
Fig 31: Swimlane Diagram of Issue an Item
Use case 13: Retrieve an Item(s)

Activity Diagram:

Log in as
Librarian
Valid Invalid
Password/ID Password/ID

Logged in Prompt for

Re-entry
Enter Book ID

If Valid
Retries
Yes No retry
remain
remain
Get issue details No

Get user type

Show message

Check for fine

No
Yes
Change the status
Add fine against
of the book in DB
the user

Update the
Create a bill
user in DB

Fig 32: Activity Diagram of Retrieve an Item

52 | P a g e
Swimlane Diagram:

Librarian Interface

Log in as
Librarian
Valid Invalid
Password/ID Password/ID

Logged in Prompt for

Re-entry
Enter Book ID
Retries
No
Get issue details remain

Yes
Get user type
No
If Valid

No
Check for fine
Yes
Change the status
of the book in DB Add fine against
the user
Update the
user in DB Create a bill

Fig 33: Swimlane Diagram of Retrieve an Item

53 | P a g e
Use case 14: Reports on Over Due Item(s) – Fine Generate
Activity Diagram:

Check the DB daily for

searching fines

Give Warning (via mail)

If yes
Cleared?

If not

If Request Yes
Increase
limit exceeds the fine

Not
Update Database
Generate request

Fig 34: Activity Diagram of Reports on Over Due Item(s)

54 | P a g e
Swimlane Diagram:

User Interface

Check the DB daily for

searching fines

Give Warning (via mail)

If yes
Cleared?

If not
If Request
limit Exceeds
Yes

Not

Generate request

Increase the fine daily

Update Database

Fig 35: Swimlane Diagram of Reports on Over Due

Item(s)

55 | P a g e
Use case 15: Search for Item(s)

Activity Diagram:

Enter Data to be Searched

Click Search

Not eligible for

searching the Item

If found No Result
No Found
Yes

Result

Fig 36: Activity Diagram of Search for Item(s)

56 | P a g e
Swimlane Diagram:

User Interface

Enter Data to be Searched

Click Search

else
Not eligible for
searching the Item

Result If found
Yes
No

No Result
Found

Fig 37: Swimlane Diagram of Search for Item(s)

57 | P a g e
Use case 16: Renew Item(s)

Activity Diagram:

Log in
Valid Invalid
Password/ID Password/ID

Logged in
Prompt for
Re-entry
List of Issued Item

Select Item No retry Retries

remain remain

Click Extend Due Date

Time Limit
Exceed

Due Date Extended Can’t be

Extended

Fig 38: Activity Diagram of Renew Item(s)

58 | P a g e
Swimlane Diagram:

User Interface

Log in

Valid
Invalid
Password/ID
Password/ID

Logged in Prompt for

Re-entry

List of Issued Item

Retries
No remain
Select Item

Click Extend Due Date

Time Limit
Exceed

Due Date Extended Can’t be

Extended

Fig 39: Swimlane Diagram of Renew Item(s)

59 | P a g e
Use case 17: Booking Item(s)

Activity Diagram:

Log in
Valid Invalid
Password/ID Password/ID

Logged in
Prompt for
Re-entry
Search Item

Not found
Retries
remain
Item found
Item missing
Item Available

Not available
Issue

Click Booking

Request Generated

Fig 40: Activity Diagram of Booking Item(s)

60 | P a g e
Swimlane Diagram:

User Interface

Log in

Valid
Invalid
Password/ID
Password/ID

Logged in Prompt for

Re-entry

Search Item
Retries
No remain

Not found

Item found
Item missing
Item Available

Not available
Issue
Click Booking

Request Generated

Fig 41: Activity Diagram of Booking Item(s)

61 | 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

62 | P a g e
Data Object: Report

Attributes:

 User_id
 Issue date
 Fine amount

Data Object: Librarian

Attributes:

 Id
 Password
 Name
 Ema

63 | P a g e
 5.3 E-R Diagram
Max Items

ID Password

Collected Items Username Issue Date

Name Return Date

Department/
User Institution
Address

User Type Borrower

Date of Birth
E-mail No. of Copy

Publisher Author

Title Subject
Update User
Database Item
Location

Call No.
Date ISBN
Resource Type
Item
E-mail Interface Status
Type
Administrator/
Librarian Name
Update Item
ID Password Database

Date
Generate
Report Report
64 | P a g e ID

Fine Amount Status

Date
 USER BORROWING ITEM
User_id : String User_id Call Number 5.4 Data
Password : String Call number ISBN Schema
Name : String Issue Date Title
Address : String Return Date Author
Email : String Publisher
User-Type : String Location
Date of Birth: String Subject
Department/Institution: Resource Type
String Item status

UPDATE USER UPDATE ITEM REPORT

DATABASE DATABASE User-id
User-id Call number Fine-amount
Library-ID Library-ID Issue-date

LIBRARIAN
ID
Password
Name
E-mail
Update

65 | P a g e Fig 43: Data Schema

 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 Search, Issue, Retrieve, Renew, Update, Configure,
events Booking, Generate Report, Return
Roles Administrator, Librarian
Organizational Department/Institute, Item type, User type
units
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

66 | 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

67 | P a g e
6.3 Class Responsibility Collaboration (CRC)

System
Item
Call number
Admin
Title
generate email() Publish
generate report() Author

Configure()

Database

ID User
Librarian
Type ID
ID
Total- Password
Password
amount Name
Name
update()
Mail
insert()
check()
select() borrower()
issue()
delete() renew()
retrieve()
sign up()
update()
sign in()
add()
sign out()
edit()
search()
delete()
booking()

Fig 44: CRC

68 | 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.

User

Circulation System
Admin Database

Librarian

Figure 45: Level 0 for circulation system

69 | P a g e
 User

Database
Input and
User accept

Item

Database

Figure 46: Level 1.1 (User) for circulation system

Input and
System
Admin accept
Database

Figure 47: Level 1.2 (Admin) for circulation system

70 | P a g e
 Input and
User
Librarian accept
Database

Figure 48: Level 1.3(Librarian) for circulation system

Authentication
User
User
Database

Borrow Item

Database

Figure 49: Level 2.1(User) for circulation system

71 | P a g e
 Authentication
System
Admin
Database

Borrow

Figure 50: Level 2.2 (Admin) for circulation system

72 | P a g e
 Update

Authentication

Librarian Issue User

Database
Return

Figure 51: Level 2.3(Librarian) for circulation system

73 | P a g e
 Change
Sign up User
Password
Database

Booking
User Sign In

Item
Search Renew
Database

Figure 52: Level 3.1(User) for circulation system

74 | 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).

Change
Status

Not available
return Done

Idle Checking
request available
Do: availability

Issued Issue

Fig 53: State diagram (Item Class)

Idle Need of Configure

configuration

updated Update
Databas
75 | P a g e
Fig 54: State diagram (Admin Class)
 collected

Retrieve Check Fine Collect

has
fine Fine

no fine
return item
User not valid

Idle User DB Check

request User valid
Do: check

updated

Item Item DB Check

DB issued issue Item
update
Update available
Do: check

Add, Edit, Booking Item not available

booked
Delete

Fig 55: State diagram (Librarian Class)

76 | P a g e
 ID, Password doesn’t match
and No. of Tries < MaxTry

Comparing Feedback
Match
Log in requested with DB
Do: validatePassword

Done

Idle Set Generate

Item taken Timer time up Report

Done Send
E-mail

Fig 56: State diagram (System Class)

77 | P a g e
 done

Select Send to
Interface
d
Request search
Information not valid

Idle User DB Check

request valid
Do: check

request

done Insert,
done
update
Delete

Fig 57: State diagram (Database Class)

78 | P a g e
 Sign Up

Booking
Exit from Sign
Register into System Out
System

Idle Enter in Sign In Borrow

System time up

Search for
Item Renew

Search

Fig 58: State diagram (User Class)

79 | P a g e
8.2 Sequence Diagram
Sequence diagram indicates how events cause transitions from object to object.

User System Database

System
ready Reading
Enter
Information

Checking
Information
lookup
result

Confirmation
Mail

send
Confirm
Insert into Update
database

Fig 59: Sequence diagram (Registration)

80 | P a g e
 User System Database

System
ready Reading
Enter
Username,
Password

lookup
Compare
result
No. of Password
tries>maxTry
Access in
correct
Block Database

Fig 60: Sequence diagram (Sign In)

81 | P a g e
 Librarian User DB Item DB

Check user
request validity
valid
Check item
availability
available
Issue
update
update

Booking not available

Fig 61: Sequence diagram (Borrow)

82 | P a g e
 Librarian User DB Item DB

Check for
request fine no fine
Update
has fine
Collect
Update

Fig 62: Sequence diagram (Return)

Admin System DB

Need
configuration
Update configured data
Update

Fig 63: Sequence diagram (Configure)

83 | P a g e
 Libration Item DB

Requirement
of add, edit,
Update new/change in data
delete Update

Fig 64: Sequence diagram (Update)

84 | 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.

85 | 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

86 | P a g e