Post on 15-Apr-2017
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 1 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 0 for circulation system 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
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
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
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.
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:
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
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:
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
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
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
17 | 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
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:
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
19 | 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
20 | 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
21 | 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
22 | 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
23 | 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
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
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
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 available Check 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 available Availability
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
Search & Select 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
Search & Select Item
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
Search & Select 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
No Found
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:
Interface User
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 Found No
If found
Fig 36: Activity Diagram of Search for Item(s)
57 | P a g e
Swimlane Diagram:
Interface User
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:
Interface User
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:
Interface User
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
Address
Name
Collected Items
Borrower
Return Date
Issue Date
Item
Call No. ISBN
Item Status
Resource Type
Location
Title
Publisher
Subject
Author
Administrator/ Librarian
Name
Password ID
Update User Database
Date
Update Item Database
Date
Report
Status Fine Amount Date
Generate Report
Interface
Type
ID
No. of Copy
Fig 43: E-R Diagram
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
issue DB 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 DB Log 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 validity request
Librarian User DB Item DB
Issue
Booking
Fig 61: Sequence diagram (Borrow)
83 | P a g e
Check for fine request
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