Gyan Vihar School Of Engineering &

Technology, jaipur

Online Library Management System

Software
Requirements Specification

Team:-

Sharp Shooters

Team Members:-
Nilay Sancheti

Pradeep

Rohit Khandelwal
Saurabh Mittal

Project Guide:-
Mr. Gajanand Sharma sir

Index & Tables

1) Introduction:

1.1)Purpose:

1.2)Scope:

1.3)Abbreviations:

1.4)Refrences:

1.5)Technologies:

1.6)Overview:

2) Overall Description:

2.01)Product Perspective:

2.02)Software Interface:

2.03)Hardware Interface:

2.04)Communication Interface:

2.05)Product Function:

2.06)User Characteristics:

2.07)Constraints:

2.08)Use – Case Model Survey:

2.09)Architecture Diagram:

2.10)Database Design:
 2.11)Assumptions & Dependencies:

3) Specific Requirements:

3.1)Use – Case Reports:

3.2)Supplimentary Requirements:

1)INTRODUCTION
1.1)Purpose :- This project ia an intranet based application that
can be accessed throughout the campus . This system can be
used for search for books/magazines, reserve books, find out who
is having a particular book, put in request to buy a new book.etc.
This is one integrated system that contains both the user
component and the librarian component. There are features like
e-mail notification / reminders, report generators etc. in this
system.

1.2)Scope of the Project:-

• Create different system users and assign different roles with related
permissions.
• Manage all the details such as user name, password, phone
numbers, address, e-mail addresses of all the users from one
central location.
• Track all the fine details of the users and their book, magazines,
newspapers, reserve books ownership detail.
• Maintain history of each user and their related information about
the books issued.
• View all the details of all the issue / submission made by the users.
 • Activities like updations, creations done in the system by the
system administrator will be maintained.
Every user of the campus can view his/her own details and can
view the details of the others user also.

1.3)Abbreviations:-

• DB2: DB2 Database is the database management system that

delivers a flexible and cost effective database platform to build
robust on demand business applications.
• EJB: Enterprise Java Beans.
• HTTP: Hypertext Transfer Protocol is a transaction oriented
client/server protocol between web browser & a Web Server.
• HTTPS: Secure Hypertext Transfer Protocol is a HTTP over SSL
(Secure Socket Layer).
• HTML: Hypertext Markup Language is a markup language used
to design static web pages.
• J2EE: Java 2 Enterprise Edition is a programming platform— part
of the Java Platform—for developing and running distributed multi
tier architecture Java applications, based largely on modular
software components running on an application server.
 • RSA: IBM® Rational Software Architect is an integrated
development toolset that supports the management and evolution
of enterprise solutions and services. Rational Software Architect is
a toolkit which is designed for the creation of more complex
projects, providing fully dynamic web application utilizing EJB’s.
This consist of EJB tools , CMP ,data mapping tools & a universal
test client that is designed to aid testing of EJB’s.
• WAS: Web Sphere application server is an application server that
runs business applications and supports the J2EE and web services
standards
• RDA: Rational Data Architect is a Database Design and
Modeling tool

1.4)Refrences:

• Problem Definition (Provided by IBM)

• IEEE SRS Format

• www.tgmc.resources.com
• www.google.com
1.5)Technologies:

• JAVA Script + JSP: Application Architecture

• J2EE:Application Architecture

• DB2: Database
 • WSAD: Development Tool

• WAS: Web Server

• AJAX

• Rational: Design Tool

1.6)Overview:
SRS will include two sections:
• Overall Description will describe major components of the
system, interconnection and external interfaces.
• Specific Requirements will describe the functions of actors,
their role in the system and constraints.
2)Overall Description:

Describe the general factors that affect the product

and its requirements.

2.01)Product Perspective:

HTML HTTP/HTTPS

CLIENT

(USERS)

WAS DB2
Client

Software

(System
TCP/IP
Administra
tor)
 Client
Application
side
Database

Server Server

• The web pages (XHTML/JSP) are present to provide the

user interface on customer clientside. Communication
between customer and server is provided through
HTTP/HTTPS protocols.
• The Client Software is to provide the user interface on
system user client side and for this TCP/IP protocols are
used.
• On the server side web server is for EJB and database
server is for storing the information.
2.02)Software Interface:

For_Client_Side_Web_interface:

Client on Internet: Browser Netscape 9 or above, Google

chrome, internet explorer 7 or above,Opera 9 or above, Support
HTTP/HTTPS on local system.

For_Client_Side_Application_interface:
JVM, TCP/IP support .

For _Server_side:
Web_server Apache Tomcat 5 OR Jakarta Tomcat 5 OR Apache
1.5 or above.
Database :DB2

Application_Servers:
SMTP,POP3, JBOSS or J2EE SDK1.5 or above
Language Compiler/Interpreter : JVM, JDK1.6
---------------------------------------------------------
IDE and Supportive Software for Devlopement.

Net Beans 1.6- Java Core and Application Devlopement

IntellJidea : Web based JSP devlopement
Dreamweaver for Static Web Page Design .

----------------

Client on Intranet:
Client Software, Web Browser, Operating System (any).

Web Server:
WAS, Operating System (any)

Data Base Server:

DB2, Operating System (any)

Development End:
WSAD (J2EE, Java, Java Bean, Servlets, HTML),
DB2, OS (Windows), Web Server.
2.03) Hardware Interface:
Client Side
 Processor Ram
Disk
Internet Space Pentium II at 64 MB
1 GB

Explorer 500

6.0 MHz

Server Side
Web sphere Pentium III at 1 512 MB
2 GB

Application server GHz

DB2 V8.1 Pentium III at 1 512 MB

1GB (Excluding data size)

2.04) Communication Interface:

• Users of remote branch will be using HTTP/HTTPS
protocols.
• Users of the same branch will be using TCP/IP protocol.

2.05)Product Function:
• PRODUCT OWNERSHIP DETAILS:-It maintains the
information that which user (student or faculty) owns
which books, journals, magazine.
 • USER CONTACT INFORMATION:-It maintains all the
details (personal,official,contact and department)of the
user.
• Maintaining Logs: Activities of the System Users can be
tracked through the logs, which is maintained by the
system.
2.06) USER CHARACTERISTICS:
Every user should be comfortable of working with
computer and net browsing. He must have basic
knowledge of English too.
2.07)Constraints:
• GUI is only in English.
• Login and password is used for identification of all the
system users and there is no facility for outsiders(i.e.
student without permission of admin can’t register).
• There is maintainability of back up in case of main system
data loss.

2.08) Use-Case Model Survey:

Add New Student :

InsertStudentRecord

ViewStudentDetails VerifyStudent
Librarian

Failure

Update Delete Student:

Failure

ViewStudentDetails VerifyStudent
Librarian

UpdateDeleteStudentRecord

Add Book:

Failure

ViewBookDetail
Librarian

AddBookRecord
Update Delete Book

Failure

ViewBookDetail
Librarian

UpdateDeleteBookRecord

Search Book

ViewBookDetail

Success

EnterSearchParameters DispalySearchResult
Librarian
AddToMyList
<<extends>> Failure

ShowMyList CheckInBook

<<extends>>

CheckOutBook

CheckIn Book
<<extends>>

Success PayLateFee
EnterStudentID
Librarian

Failure
Checkout Book

Success

EnterBookCallNo EnterStudentID
Librarian

Failure

USE-CASE DIAGRAM
Add New student

Astudent :
Librarian
Student

View student details

Add student
Validate

Error
Update Delete Student

Astudent :
Librarian
Student

View Student details

Delete student
Validate student
Delete successfully
return error (if delete unsuccessfully)

Add Book

Abook : Book
Librarian

View book details

Add the book

Error
Update/Delete Book

Abook : Book
Librarian

View book details

Delete the book

Delete successfully

Return error if delete unsuccessfully

Search Book

System : Abook : Book

Librarian
System

Enter search parameters

Search

search result

Display search result

View book details

Add to my list
View my list

display my list

Error (if operated unsuccessfully)

Ceck In Book

Atransction :
Librarian
Transction

Check in ( StudentID, Book)

Validate CheckIn

Compute latefine
Check in successfully

Error
Checkout Book

Atransaction :
Librarian : Librarian
Transction

Check out (StudentID, Book call#)

validate checkout
Check out successfully

Error

ViewBookDetail

Abook : Book
Librarian

View book details

display book details

ViewtudentDetails

Librarian AStudent :
Student

View student details

display student details

2.09)E-R Diagram:
2.10)Data base Design:
 AddNewStudent
(from csi518team)
UpdateDeleteStudent
(from csi518team)

AddBook
(from csi518team)

UpdateDeleteBook
(from csi518team)

SearchBook
(from csi518team)

Librarian
(from csi518team)

CheckInBook
(from csi518team)

CheckOutBook
(from csi518team)

PayLateFee
(from csi518team)
ViewStudentDetails ViewBookDetail
(from csi518team) (from csi518team)

2.11)Assumptions & Dependencies:

• The details related to books , journals, users,
newspapers and issue & submission provided
manually.
 • Data Administrator(Librarian) is created in the system
already.

• Roles and tasks are predefined.

3)Specific Requirements:
3.1)Use-Case Reports:
Use case diagrams:
A use case describes what a system does from the standpoint of a user (anything external).

A use case diagram is easy to understand by a user of a system and it allows the communication
between a system developer and its users.

A use case is represented by an oval, representing a task or function of a system. An external

entity (e.g., a person) interacting with the use case is called an actor, usually shown as a stick
person. A use case diagram may show more than one use case. The box enclosing the use cases
indicate the system boundary. This boundary is labeled with the name of the system. The
following is a use case diagram for a library system:

Library System

Reserve a book

Borrow copy of book

* *

*
* Return copy of book

Book Borrower *

Update catolog
* *

Librarian

Use cases are used to identify the user requirements for a particular software product.
A use case is a task (called functional requirement in software engineering) that an
actor is expecting the software to perform.

Use cases are related to scenarios. A scenario is a written interaction between a user
and a system. There is a normal scenario for a task when everything works as
expected. Several other scenarios associated with a normal scenario respond to
unusual situations of the interaction between a user and a system.

Example of scenarios for the use case “Borrow copy of book.”

Normal scenario: Book borrower Joe Doe needs to borrow a copy of the book
“Programming Languages. He finds a copy of the book and proceeds to check out the
book. The system verifies that the Joe has not borrowed the maximum number of
books, and the system let him borrows the book.

Unusual scenario 1: Book borrower Joe Doe needs to borrow a copy of the book
“Programming Languages. The library does not have a copy of the book. Joe simply
leaves the system.

Unusual scenario 2: Book borrower Joe Doe needs to borrow a copy of the book
“Programming Languages. He finds a copy of the book and proceeds to check out the
book. The system finds out that Joe has borrowed the maximum number of books
allowed by the library. The system refuses to loan the book to Joe.

These three scenarios are possible instances of the use case. The outcome of any of
these scenarios differs from the others.

Relationship between use cases

Two types of relationship between use cases have been identified: <<include>> and
<<extend>>.

The <<include>> relationship (<<uses>> in Visio use case diagram) is used when a
common behavior, feature, or subtask from two or more use cases are abstracted in a
use case. That is, a use case “includes” the functionality of another use case. For
instance, in the use cases “Borrow copy of book” and “Extend loan”, both use cases
require the system to check whether another borrower has reserved the book. The
<<include>> relationship is shown in the following diagram.
 *
Borrow copy of book
«uses»
*

Check for
* «uses» reservation

Book Borrower Extend loan

*

The <<extend>> relationship is used for a use case that have different scenarios, with a
main case (normal scenario) and one or more special (unusual scenarios) cases. An
arrow from use case A to use case B (main case) indicates that A is a special case of B.
Keep in mind that the direction of the arrow is opposite to the direction of the
<<include>> relationship. Example of an <<extend>> relationship is shown in the
diagram below. Here, the “Refuse loan” is a special use case of the main case “Borrow
copy of book”. “Refuse loan” represents the unusual scenario when a borrower has
already borrowed the maximum number of books allowed for him or her.

«extends»
Borrow copy of book Refuse loan
* *

Book Borrower

A use case analysis involves the following steps:

1. Determine the actors (people, systems, etc.) that interact with the software
produce to be implemented. Some actors (primary) initiate the interaction with
the system, others (secondary) respond to system requests.
2. Identify use cases. Use cases are functionality of a system satisfying actor’s
needs.
3. Determine the goal of the use case.
4. Identify pre- and post conditions. That is, identify the state of the system at the
start and at the end of a use case.
5. Specify the main scenario that would result in a normal operation for the use
case, and the various unusual or alternate scenarios that can happen during the
process of a use case.
6. Draw the use case diagram.
7. Identify <<include>> and <<extend>> relationships and modify the use case
diagram with these identified relationships.
 Example of the documentation of a use case:

Use case: Book a Reservation

Goal: A customer books a reservation using an online airline reservation system.

Actors:

Customer: person who makes the reservation.

FlightsDB: Database with the scheduled flights

BillingSystem: System for processing the charger to credit cards

Precondition: Graphical user interface displays main web page for the search of
flights. The database and web server are active for the processing of the searches.

Main scenario:

1. User types information required to search for flights for a trip.

2. FlightDB searches the DB and lists available flights satisfying the trip.
3. GUI displays matching flights.
4. Customer selects a particular set of flights.
5. FlightDB puts on hold for 30 minutes on selected flights and seats
6. GUI displays the price and final itinerary for the selected flights.
7. Customer continue with the purchase of the tickets
8. GUI displays forms to enter credit card information.
9. Customer enters the information and click “Submit purchase”
10. Billing System verifies the CC information and charges the CC
11. FlightDB is updated, generates and records a confirmation number of the
purchase.
12. GUI displays itinerary, confirmation number and other information regarding
the trip.
13. Customer closes the session.

Several alternate or unusual scenarios can be written after the main scenarios.

For example, in step 5, if the customer did not purchase the trip within 30
minutes, the system will not let the customer to purchase the tickets.
3.2) Supplementary Requirements:

 Have hours of operation that are 24 x 7 - Because

system can be an automated process, so it can stay
open for 24 hours a day. System is required to be
available 24X7 so UPS support must be on server
site for at least 8 hours in case of power failure.
System will remain inaccessible to users at 2:00 to
4:00 am for backup and maintenance purpose.

 Make the existing Web site more dynamic in

nature - Many early Web implementations
consisted of static HTML pages. This becomes
very difficult to manage if the number of pages
gets too large. An effective system should be
largely dynamic taking advantage of technology
that automates this process rather than relying on
manual processes. Application should serve
dynamic user based customized web pages to its
clients from server.
 Tie the existing Web site into existing enterprise
systems – Any existing Web site that relies on the
manual duplication of data from another system is
one that can be improved. Most of the business
data in the world today exists in enterprise servers
 that can be connected to the Web servers to make
this process far more effective.

 Provide good performance and the ability to scale

the server – The Web Application Server should
provide good performance and the ability to
manage performance with techniques, such as
support for caching, clustering, and load
balancing.

 Providing session management capability - Web

application developers should not spend valuable
time worrying about how to maintain sessions
within the application. The Web Application
Server should provide these services.