srs of library circulation system

Institute of Information Technology , University of Dhaka

Library Circulation System Software Requirements Specification

7/8/2013

ii | P a g e

Library Circulation System Software Requirements Specification

Software Requirements Specification and Analysis

SE 406

Submitted by:

Lamisha Rawshan (BIT0311)

Md. Shafiuzzaman (BIT0322)

Nadia Nahar (BIT0327)

Submitted to:

Dr. Kazi Muheymin-Us-Sakib

Associate Professor,

Institute of Information Technology,

University of Dhaka

Submission Date:

8th July, 2013

iii | P a g e

LETTER OF TRANSMITTAL

Dr. K M Sakib

Associate Professor

Institute of Information Technology (IIT)

University of Dhaka

July 8, 2013

Dear Sir,

We have prepared the enclosed report on Software Requirements Specifications of “Library

Circulation System” for your approval. This report details the requirements we gathered for the

project.

The primary purpose of this report is to summarize our findings from the work that we

completed as our Software Requirements Specifications and Analysis course project. This report

includes the details of each steps we followed to collect the requirements.

Sincerely Yours,

Lamisha Rawshan

Md. Shafiuzzaman

Nadia Nahar

Enclosure: SRS Report

iv | P a g e

Executive Summary

The purpose of Library Circulation System (LCS) is to provide a convenient, easy-to-use,

Internet-based application for Librarians to track and manage the circulation of resources at a

university, which include books, magazines, journals, Compact Disks (CD), videocassettes,

Digital Video Disks (DVD) etc. In addition, the purpose of LCS is also to provide a convenient,

Internet-based method for Students and Faculty of a university to search for items in the library’s

circulation, renew items they have checked out, and reserve items .This report provides the

Software Requirements Specifications (SRS) to develop the system.

v | P a g e

Acknowledgements

By the Grace of ALMIGHTY ALLAH we have completed our Report on Software

Requirements Specification of Library Circulation System.

We are grateful to the project supervisor Dr. K M Sakib Sir for his supervision throughout the

working time. He helped us a lot by sharing his valuable knowledge with us.

vi | P a g e

Table of Contents

Chapter 1: Introduction .............................................................................................................. 1

1.1 Purpose ................................................................................................................................. 1

1.2 Intended Audience .............................................................................................................. 1

Chapter 2: Inception .................................................................................................................... 3

2.1 Introduction ......................................................................................................................... 3

2.1.1 Identifying Stakeholders ............................................................................................. 3

2.1.2 Recognizing multiple viewpoints ............................................................................... 5

2.1.3 Working towards collaboration ................................................................................ 6

2.1.4 Asking the First Questions ......................................................................................... 7

2.2 Conclusion............................................................................................................................ 7

Chapter 3: Elicitation ................................................................................................................... 9

3.1 Introduction ......................................................................................................................... 9

3.2 Eliciting Requirements ...................................................................................................... 9

3.3 Collaborative Requirements Gathering .......................................................................... 9

3.4 Quality Function Deployment ........................................................................................ 10

3.4.1 Normal Requirements ............................................................................................... 10

3.4.2 Expected Requirements ............................................................................................ 10

3.4.3 Exciting requirements ............................................................................................... 11

3.5 Usage Scenarios ................................................................................................................. 12

3.5.1 In case of Issue the available book .......................................................................... 12

3.5.2 In case of Issue the reserved book ........................................................................... 12

3.6 Elicitation work product ................................................................................................. 12

Chapter 4: Scenario-Based Model ........................................................................................... 14

vii | P a g e

4.1 Introduction ....................................................................................................................... 14

4.2 Use Case Scenario ............................................................................................................. 14

4.3 Use Case Descriptions ...................................................................................................... 15

4.3.1 Authentication ............................................................................................................ 15

4.3.2 Configure .................................................................................................................... 17

4.3.3 Update.......................................................................................................................... 19

4.3.4 Return .......................................................................................................................... 21

4.3.5 Borrow ......................................................................................................................... 22

4.4 Use Case Diagram ............................................................................................................. 25

4.3 Activity Diagram and Swimlane Diagram of generated Use Cases .......................... 29

Chapter 5: Data Model .............................................................................................................. 62

5.1 Data Modeling Concepts ................................................................................................. 62

5.2 Data Objects ...................................................................................................................... 62

5.3 E-R Diagram...................................................................................................................... 64

5.4 Data Schema ...................................................................................................................... 65

Chapter 6: Class-Based Model ................................................................................................. 66

6.1 Introduction ....................................................................................................................... 66

6.2 Identifying Analysis Classes ............................................................................................ 66

6.3 Class Responsibility Collaboration (CRC) ................................................................... 68

Chapter 7: Flow-Oriented Model ............................................................................................. 69

7.1 Introduction ....................................................................................................................... 69

7.2 Data Flow Diagram(DFD) ............................................................................................... 69

Chapter 8: Behavioral Model ................................................................................................... 75

8.1 State Diagram .................................................................................................................... 75

viii | P a g e

8.2 Sequence Diagram ............................................................................................................ 80

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

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

List of Figures

Figure Description Page 1 2 3 4 5 6 7 8 9

10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

Level 0 for circulation system Level 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


Conflicting Requirements:

We found some requirements conflicting each other .We had to trade-off between the

requirements.

Easy access and Strong Authentication

Allow any user to use the system and allow valid user to use the system

Final Requirements:

We finalized following requirements for the system by categorizing and prioritizing the

requirements:

Error free system (Maximum 5% error may be considerable)

Web-based interfaces

Accessible via the Internet.

Allow valid users to login and logout.

Restrict access to functionality of the system based upon user roles

7 | P a g e

Allow administrators of the system to change user types and configure parameters of

the system

Allow any user to search for items in the library’s circulation without having to log in

to the system

Allow valid users that log in to renew items, reserve items, and view the items they

have checked out.

Allow Librarians to check-out and check-in items for valid users

Allow Librarians to generate reports on the items in the system (e.g., all overdue

items, all missing items.)

The application only needs to be installed and maintained on one computer

Allows valid users to renew items online by logging into the system


Restrict access to functionality of the system based upon user roles. For example,

only Administrators of the system will be provided functionality to change user types,

configure how long items may be checked out and the fines for overdue items.

2.1.4 Asking the First Questions

We set our first set of context-free questions focuses on the customer and other stakeholders,

overall project goals and benefits. The questions are mentioned above. These questions

helped us to identify all stakeholders, measurable benefit of the successful implementation

and possible alternatives to custom software development. Next set of question helped us to

gain a better understanding of problem and allows the customer to voice his or her perception

about the solution. The final set of question focused on the effectiveness of the

communication activity itself.

2.2 Conclusion

Inception phase helped us to establish basic understanding about book circulation system in a

library, identify the people who will be benefited if book circulation system becomes

automated, define the nature of the book circulation software and establish a preliminary

communication with our stakeholders.

8 | P a g e

Group meeting

1.

Date: 06.09.2012

Place: IIT

Subject: Identifying Stakeholders

Members:

Lamisha Rawshan BIT-0311

Shafiuzzaman BIT-0322

Nadia Nahar BIT-0327

2.

Date: 13.09.2012

Place: Central Library, University of Dhaka

Subject: Collecting requirements from the stakeholders

Members:




3.

Date: 15.09.2012

Place: IIT, University of Dhaka

Subject: Discussion on requirements

Members:




9 | P a g e

Chapter 3

Elicitation

The purpose of this chapter is to specify the elicitation part.

3.1 Introduction

Elicitation is a task that helps the customer to define what is required. To complete the

elicitation step we face many problems like problems of scope, problems of volatility and

problems of understanding. However, this is not an easy task. To help overcome these

problems, we have worked with the Eliciting requirements activity in an organized and

systematic manner.

3.2 Eliciting Requirements

Unlike inception where Q&A (Question and Answer) approach is used, elicitation makes use

of a requirements elicitation format that combines the elements of problem solving,

elaboration, negotiation, and specification. It requires the cooperation of a group of end-users

and developers to elicit requirements .To elicit requirements we completed following four

works.

1. Collaborative Requirements Gathering

2. Quality Function Deployment

3. Usage Scenarios

4. Elicitation work products

3.3 Collaborative Requirements Gathering

Many different approaches to collaborative requirements gathering have been proposed. Each

makes use of a slightly different scenario .We completed following steps to do it.

The meetings were conducted with the assistant librarian (program) of the Central

Library, University of Dhaka; the librarian was questioned about their requirements and

expectations from the automated book circulation system.

The librarian was asked about the problems she is facing with the current manual system.

10 | P a g e

At last we selected our final requirement list from the meetings.

3.4 Quality Function Deployment

Quality Function Deployment (QFD) is a technique that translates the needs of the customer

into technical requirements for software .It concentrates on maximizing customer satisfaction

from the Software engineering process .With respect to our project the following

requirements are identified by a QFD.

3.4.1 Normal Requirements

Normal requirements consist of objectives and goals that are stated during the meeting with

the customers. Normal requirements of our project are:-

1. Accessible via the Internet.

2. Allow any user to search for items.

3. Allow Librarians to check items for valid users.

4. Allow valid users to login and logout

5. Restrict access to functionality of the system based upon user roles

6. Allow valid users that log in to renew items, reserve items, and view the items

7. Allow Librarians to generate reports on the items in the system (e.g., all overdue items, all

missing items.)

8. The application only needs to be installed and maintained on one computer.

9. Help feature to explain what they are looking for

10. A product reference manual describing how to install, setup, and run the application will

be provided.

3.4.2 Expected Requirements

These requirements are implicit to the system and may be so fundamental that the customer

does not explicitly state them .Their absence will be a cause for dissatisfaction.

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

2. The system shall enable the Administrator to change a user’s type to any user type.

3. The system shall enable the Administrator to change user passwords.

4. The system shall enable the Administrator to configure the due date calculation for an

item.

11 | P a g e

5. The system shall enable the Librarian to change the number of items each user can check-

out.

6. The system shall enable the Administrator to configure the fine/item/day for an overdue

item.

7. The system shall enable any Librarian to give Librarian rights to other users.

8. The system shall allow the user to log in based upon an assigned login id and password.

9. The system shall automatically compute the due date for every item

10. The system shall automatically set the user status to “ABLE TO BORROW” and

“UNABLE TO BORROW”

11. The system shall automatically send e-mail to the user when an item is overdue.

12. The system shall compute fines automatically for overdue items.

13. The system shall automatically set the Item Status to

“AVAILABLE”,“UNAVAILABLE” ,”RENEWED”,”MISSING”.

14. The system shall enable Librarians to add, edit or delete an item.

15. The user interface of the system shall be easy to use and shall make use of drop-down

boxes, radio buttons, and other selectable fields wherever possible instead of fields that

require the user to type in data

3.4.3 Exciting requirements

These requirements are for features that go beyond the customer's expectations and prove to

be very satisfying when present

1. The user interface should provide appropriate error messages for invalid input as well as

tool-tips and online help

2. The user interface should follow standard web practices such that the web interface is

consistent with typical internet applications.

3. Offer log in with mobile phone

4. The system’s configuration shall be documented and updated as changes to the system are

made due to patches, new releases, etc.

5. Connect user account with facebook or other social media

12 | P a g e

3.5 Usage Scenarios

At first a user authenticate in our system by creating an account .If a user already has an

account then he/she will log in the system with his/her own password and username. Then

our system will search the book that is requested by a user. If the book is not found, the

system will exit. Otherwise system will check the availability of the book.

3.5.1 In case of Issue the available book

If the book is available the system will check the user database to confirm about the

validation of the user. For an invalid user the system will exit and for valid user librarian will

generate a call slip number manually for the user. Then our system will change the status of

the book and user in our database. The system also generates a return date for the book.

3.5.2 In case of Issue the reserved book

If the user wants to issue a book which is already issued by a second user, the user is

supposed to reserves the book and gets a reservation number on the basis of waiting list

which is already in the reservation queue for that book.

User is supposed to check his reservation number on the notice board database in our system

and list is put up on the library notice board also by the librarian. Whenever they got the book

free from the second user they give the book to the user who have priority in the reservation

queue and second user is supposed to pay fine if he/she is returning the book after due date.

User is supposed to issue the reserved book within three days from the day when his/her turns

on the reservation list otherwise his reservation will be cancelled and he will not get the book

(if there is waiting queue for that book).

Now the user issues the book and the system automatically generates the return date (+7

days) and the user is required to return the book within the due date otherwise fine is imposed

on him by the librarians.

3.6 Elicitation work product

The output of the elicitation task can vary depending on size of the system or product to be

built. Our elicitation work product includes:

Make a statement of our requirements for automated book circulation system.

Make a bounded statement of scope for our system.

Make a list of customer, user and other stakeholder who participated in requirements

13 | P a g e

elicitation.

Set of usage scenarios.

Description of the system’s technical environment

Group meetings

1.

Date: 24.09.2012

Place: Central Library, University of Dhaka

Subject: Meeting with Assistant Librarian (program) of the Central Library, University of

Dhaka

Members:




2.

Date: 26.09.2012


Subject: Defining the QFD

Members:




3.

Date: 27.09.2012


Subject: Preparing the user scenario

Members:




14 | P a g e

Chapter 4

Scenario-Based Model

This chapter describes the scenario based model for the library circulation system.

4.1 Introduction In this model the system is described from the user’s point of view. As this is the first model,

it serves as input for creation of other modeling elements.

4.2 Use Case Scenario: Level – 0 Level – 1 Level – 2 Actors

Circulation

System

Authentication Sign Up Student, Faculty

Sign In Administrator, Student,

Faculty, Librarian

Sign Out Administrator, Student,

Faculty, Librarian

Change Passwords Administrator, Student,

Faculty

Configure Change User Types Administrator, Librarian

Configure the Due Date for an Item Administrator

Configure the Fine for Overdue Items Administrator

Change default Item Due dates Librarian

Update Add an Item Librarian

Edit an Item Librarian

Delete an Item Librarian

Return Retrieve an Item Librarian

Reports on Over Due Items Student, Faculty

Borrow Search for Items Librarian, Student,

Faculty, Administrator

Issue an Item Librarian

Renew Items Student, Faculty

Booking Items Students, Faculty

Table 1: Use Case Scenario

15 | P a g e

4.3 Use Case Descriptions

In this section use case scenarios are described elaborately.

4.3.1 Authentication

Authentication system is divided into four sub-systems.

4.3.1.1 Sign Up

Use Case: Sign Up

Primary Actors: Student, Faculty

Goal in context: To register in the system

Precondition:

1. System has been programmed for add new user in database

2. System has interface for registration

Triggers: The student and faculty has a need to register

Scenario:

1. Visit the register page

2. Input required information

3. Check availability for username & check validity of Password

4. Authentication and Robot checking

5. E-mail sent to user e-mail address

6. User confirm from his/ her e-mail address

7. Confirmation message showed

Exception:

User in not authorized for registration

Ambiguous Input

Authentication Fail

Priority: Essential, must be implemented

When Available: First increment

16 | P a g e

4.3.1.2 Sign In

Use Case: Sign In

Primary Actors: Student, Faculty, Administrator, Librarian

Goal in context: To enter the system

Precondition: Must be registered

Triggers: Need to log in the system

Scenario:

1. Visit the login page

2. Input Username & Password

3. Proceed to the next activity

Exception:

Unrecognized Username

Wrong Password

User is blocked



4.3.1.3 Sign Out

Use Case: Sign Out

Primary Actors: Student, Faculty, Administrator, Librarian

Goal in context: To exit from the system

Precondition: Must be logged in

Triggers: Need to log out from the system

Scenario: Click the logout button



4.3.1.4 Change Password(s)

Use Case: Change Password(s)


Goal in context: To change the existing password to a new password

Precondition: System has been programmed for a password

Triggers: The student and faculty has a need to change the existing password to a new one

17 | P a g e

Scenario:

1. Visit the login page and login

2. Click on Edit button

3. Change Password


Exception: Weak Password: Password length is too short



4.3.2 Configure

4.3.2.1 Change User Type(s)

Use Case: Change User Type(s)

Primary Actors: Administrator, Librarian

Goal in context: To change the user type

Precondition: Must be logged in as Administrator/ librarian

Triggers: The administrator and librarian have a need to change the user type.

Scenario:

1. Visit Login page and Log in

2. Click the Edit User button

3. Select the User

4. Click on the Edit button

5. Change the type for the selected User


Exception:

Invalid User: User may not be eligible for that type

Unrecognized: User does not exist



4.3.2.2 Configure the Due Date for an Item(s)

Use Case: Configure the Due Date for an Item(s)

Primary Actors: Administrator

Goal in context: To configure the due date for an item

18 | P a g e

Precondition:

Must be logged in as Administrator

System has been programmed for editing due date

Triggers: The administrator has a need to configure the due date for an item.

Scenario:

Visit Login page and Log in

Click on Maintain Item button

Select the Item

Click on Edit Due Date for an Item button

Change the Due Date for selected Item

Proceed to the next activity

Exception:

Item Unavailable: Requested item does not exist

Ambiguous Input

Priority: Expected

When Available: Second increment

4.3.2.3 Configure the Fine for Overdue Item(s)

Use Case: Configure the Fine for Overdue Item(s)

Primary Actors: Administrator

Goal in context: To configure the fine for overdue item

Precondition:

Must be logged in as Administrator

System has been programmed for editing due fine

Triggers: The administrator has a need to configure the fine for overdue item.

Scenario:


Click on Maintain Validation Data button

Click on Configure the Fine for an Overdue Item button

Update the Fine for selected Overdue Item

Click on Update button


Exception: Ambiguous Input

19 | P a g e

Priority: Expected


4.3.2.4 Change default Due date for Item

Use Case: Change default Due date for Item

Primary Actors: Librarian

Goal in context: To change the default due date for item

Precondition: Must be logged in as Librarian

Triggers: The librarian has a need to change the default due date for item.

Scenario:



Click on Change default Due date for Item button

Update the Due date for selected Item


Exception: Ambiguous Input

Priority: Expected


4.3.3 Update

4.3.3.1 Add an Item(s)

Use Case: Add an Item(s)


Goal in context: To add new item(s)

Precondition:

System has been programmed for adding item in database

Must be logged in as Librarian

Trigger: The librarian has a need to add new item(s)

Scenario:



Click on Add Item button to add new item

Enter the new Item data (select Location) and confirm changes

20 | P a g e


Exception: Already Exist: Requested item is already added in the database



4.3.3.2 Edit an Item(s)

Use Case: Edit an Item(s)


Goal in context: To edit an item

Precondition:

System has been programmed for editing item in database


Trigger: The librarian has a need to edit an item(s).

Scenario:


2. Click on Maintain Item button

3. Search and Select the Item to edit

4. Click on Edit Item button

5. Edit the Item details and confirm changes


Exception:

Does not exist: Requested item does not exist in the database

Ambiguous Input



4.3.3.3 Delete an Item(s)

Use Case: Delete an Item(s)


Goal in context: To delete an item

Precondition:

System has been programmed for deleting item in database


21 | P a g e

Trigger: The librarian has a need to delete an item(s).

Scenario:



Search and Select the Item to delete

Click on Delete Item button

Delete the selected Item and confirm changes


Exception: Does not exist: Requested item does not exist in the database



4.3.4 Return

4.3.4.1 Retrieve an Item(s) Use Case: Retrieve an Item(s)


Goal in context: To retrieve an item

Precondition: Item must be issued for the particular user

Trigger: The librarian has a need to retrieve an item

Scenario:


Click on Retrieve button

Enter User name and Click Search for user

Select the User

Enter Item Name and Click Search item

Select the Item

Click Retriever button and Status changes from Issued to Retrieved

A message is displayed




22 | P a g e

4.3.4.2 Reports on Over Due Item(s)

Use Case: Reports on Over Due Item(s)


Goal in context: To generate reports on overdue item(s)

Precondition:

System has been programmed for automated report generation


Triggers: Report need to be automatically generated of overdue item(s).

Scenario:

Database is automatically checked daily for Over Due

Send mail to users having Over Due

Increase fine if not cleared

Update database


Exception: Error: System is not ready



4.3.5 Borrow

4.3.5.1 Search for Item(s)

Use Case: Search for Item(s)

Primary Actors: Librarian, Student, Faculty, Administrator

Goal in context: To perform a search for item(s)

Precondition: System has been programmed for searching all items in database

Triggers: The student, faculty, librarian, administrator has a need to search for item(s)

Scenario:

1. Visit the main page

2. Enter data and information such as title, author’s name etc.

3. Click the Search button

4. View the search result


Exception:

Search item does not exist

23 | P a g e

User is not eligible for searching that item



4.3.5.2 Issue an Item(s) Use Case: Issue an Item(s)


Goal in context: To issue an item

Precondition:

User must be eligible for taking requested item

Item is available

Trigger: The librarian has a need to issue an item.

Scenario:


2. Click on Issue button

3. Search for the Person/User

4. Select User and list of items issued to the user is displayed

5. Click on Issue button and Status changes from Available to Issued to Library

6. A message is displayed


Exception:

Invalid User: User status is not supported for this event

Item does not exist



4.3.5.3 Renew Item(s)

Use Case: Renew Item(s)


Goal in context: To extend the item(s) that has/have reached the due date.

Precondition:

Valid User

Valid and Available Item

24 | P a g e

Triggers: The student, faculty, librarian has a need to extend item(s) due date.

Scenario:

Visit the login page and log in

List of Issued items for that User will be displayed

Extend due date button will be shown for all the items which were not

renewed in the past

Click on the Extend due date button to renew the item

Item(s) due date will be extended for 14 days

Exception:

Time Limit Exceeded: Renew chance has been finished

Unavailable: Item is unavailable for renew



4.3.5.3 Booking Item(s)

Use Case: Booking Item(s)


Goal in context: To book item(s) that are unavailable at that particular time.

Precondition:

Valid User

Valid but unavailable Item at the particular time

Triggers: The student and faculty have a need to book item(s) that is/are unavailable at that

particular time.

Scenario:

Visit the login page and log in

Enter data and information such as title, author’s name etc. or

Click the Search button

View the search result

Click on the Booking button


Exception: Missing: Item is missing



25 | P a g e

4.4 Use case Diagram

Fig 1: Level 0 for circulation system

Administrator

Librarian

Student

Faculty

Fig 2: Level 1 for circulation system

Circulation System Database

Authentication

Configure

Borrow

Update

Return

User Database

Item Database

System Database

26 | P a g e

Administrator

Librarian

Student

Faculty

Fig 3: Level 2.1(Authentication) for circulation system

Administrator

Librarian

Fig 4: Level 2.2(Configure) for circulation system

Sign up

Sign in

Sign out

Change password

User Database

Change user types

Configure due date

Configure fine for overdue

Change default due dates

Item Database

System Database

User Database

27 | P a g e

Administrator

Librarian

Student

Faculty

Fig 5: Level 2.3(Borrow) for circulation system

Search

Issue

Renew

Booking

Item Database

User Database

28 | P a g e

Librarian

Student

Faculty

Fig 6: Level 2.4(Return) for circulation system

Librarian

Fig 7: Level 2.5(Update) for circulation system

Retrieve

Reports on over due

Item Database

User Database

Add

Edit

Delete

Item Database

29 | P a g e

4.5 Activity Diagram and Swimlane Diagram of generated Use Cases:

Use case 1: Sign Up

Activity Diagram:

Fig 8: Activity Diagram of Sign Up

OK

Failed

Valid

Password not Valid (Max length 6)

Available

Username not 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


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)


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


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


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


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


Click Maintain Validation Data

Select Over Due Item

Click Configure the Fine

Update the Fine

Item not Available

Ambiguous Input

Invalid Input

Prompt for Re-entry

No retry remain

Administrator

Fig 21: Swimlane Diagram of Configure the Fine for an Over Due Item(s)

42 | P a g e

Use case 8: Change default Due date for Item

Activity Diagram:

No retry remain

Item not Available

Ambiguous Input

Invalid Password/ID

Valid Password/ID

Logged in

Click Maintain Item

Due Date Updated

Invalid Input

Log in as Librarian

Prompt for Re-entry

Click Change Due Date

Input Due Date

Retries remain

Select Item

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

43 | P a g e

Swimlane Diagram:

Interface

Invalid Password/ID

Valid Password/ID

Retries remain

Logged in

Due Date Updated

Log in as Librarian

Click Maintain Item

Select Item

Click Change Due Date

Input Due Date

Item not Available

Ambiguous Input

Invalid Input

Prompt for Re-entry

No retry remain

Librarian

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

44 | P a g e

Use case 9: Add an Item(s)

Activity Diagram:

No retry remain

Item already exist

Invalid Password/ID

Valid Password/ID

Logged in

Click Maintain Item

Item Added Invalid Input

Log in as Librarian

Prompt for Re-entry

Select Location

Enter Item

Retries remain

Click Add Item

Fig 24: Activity Diagram of Add an Item

45 | P a g e

Swimlane Diagram:

Interface

Invalid Password/ID

Valid Password/ID

Retries remain

Logged in

Item Added

Log in as Librarian

Click Maintain Item

Click Add Item

Select Location

Enter Item

Item already exist

Invalid Input

Prompt for Re-entry

No retry remain

Librarian

Fig 25: Swimlane Diagram of Add an Item

46 | P a g e

Use case 10: Edit an Item(s)

Activity Diagram:

No retry remain

Invalid Password/ID

Valid Password/ID

Logged in

Click Maintain Item

Item Edited

Log in as Librarian

Prompt for Re-entry

Edit Item Details

Retries remain

Item does not exist

Item not Matched

Click Edit Item

Search & Select Item

Fig 26: Activity Diagram of Edit an Item

47 | P a g e

Swimlane Diagram:

Interface

Invalid Password/ID

Valid Password/ID

Retries remain

Prompt for Re-entry

Logged in

Item Edited

Log in as Librarian

Click Maintain Item


Click Edit Item

Edit Item Details

Item does not exist

Item not Matched

No retry remain

Librarian

Fig 27: Swimlane Diagram of Edit an Item

48 | P a g e

Use case 11: Delete an Item(s)

Activity Diagram:

No retry remain

Invalid Password/ID

Valid Password/ID

Logged in

Click Maintain Item

Item Deleted

Log in as Librarian

Prompt for Re-entry

Click Delete Item

Retries remain


Item does not exist

Item not Matched

Fig 28: Activity Diagram of Delete an Item

49 | P a g e

Swimlane Diagram:

Interface

Invalid Password/ID

Valid Password/ID

Retries remain

Prompt for Re-entry

Logged in

Item Deleted

Log in as Librarian

Click Maintain Item


Click Delete Item

Item does not exist

Item not Matched

No retry remain

Librarian

Fig 29: Swimlane Diagram of Delete an Item

50 | P a g e

Use case 12: Issue an Item(s)

Activity Diagram:

Yes

Yes

No

Yes

No Found

No retry remain

Search Item

Availability

Check the borrower

If valid

Change the status of the book in DB

Generate call slip

Update the user in DB

Booking

Invalid Password/ID

Valid Password/ID

Logged in

Log in as Librarian

Prompt for Re-entry

Retries remain

No

Fig 30: Activity Diagram of Issue an Item

51 | P a g e

Swimlane Diagram:

Interface

Invalid Password/ID

Valid Password/ID

Retries remain

Prompt for Re-entry

Logged in

Log in as Librarian

Librarian

Search Item

Yes

No Found

Booking No

Yes

Availability

Yes

No

Check the borrower

If valid


Generate call slip


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



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



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

E-mail

Address

Name

Collected Items

Borrower

Return Date

Issue Date

Item

Call No. ISBN

Item Status

Resource Type

Location

Title

Publisher

Subject

Author

Administrator/ Librarian

E-mail

Name

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