NITTE MEENAKSHI INSTITUTE OF TECHNOLOGY

(AN AUTONOMOUS INSTITUTION, AFFILIATED TO VISVESVARAYA TECHNOLOGICAL UNIVERSITY, BELGAUM, APPROVED

BY AICTE & GOVT.OF KARNATAKA

Software Engineering (14CS61)

SRS on

LIBRABRY MANAGEMENT SOFTWARE

FOR (national public school, bangalore )

Submitted in partial fulfilment of the requirement for the course on SE

(14CS61)
Computer Science and Engineering

Submitted by:
1) DIVYANSHU D V Usn: 1NT16CS025
2) D ARUN SAKETH Usn: 1NT16CS030
3) MIHIR M Usn: 1NT16CS048
4) P SANJEEV TEJA Usn: 1NT16CS098

Department of Computer Science and Engineering

2018-19
 NITTE MEENAKSHI INSTITUTE OF TECHNOLOGY
(AN AUTONOMOUS INSTITUTION, AFFILIATED TO VISVESVARAYA TECHNOLOGICAL UNIVERSITY, BELGAUM
, APPROVED BY AICTE & GOVT.OF KARNATAKA)

Department of Computer Science and Engineering

CERTIFICATE

This is to certify that the Software Requirement Specification on E-store (Software) is an

authentic work carried out by DIVYANSHU D V (1NT16CS025), D ARUN SAKETH--1NT16CS030
MIHIR M--1NT16CS048 and P SANJEEV TEJA--1NT16CS098 bonafide students of
Nitte Meenakshi Institute of Technology, Bangalore in partial fulfilment for the course in
Software Engineering (14CS61), Department of COMPUTER SCIENCE AND ENGINEERING during
the academic year 2018-2019.

Course In-charge

Vinay.T.R
A.Ass Assistant. Professor, Dept. Of CSE,
NMIT, Bangalore
 ACKNOWLEDGEMENT

The completion of this undertaking could not have been possible without the
participation and assistance of so many people. Their contribution are sincerely
appreciated and gratefully acknowledged. However the group would like to express our
sincere gratitude to our Software Engineering lecturer Mr. Vinay. T.R for his vital
support, guidance and constant supervision as well as for providing necessary
information regarding the Software Requirement Document of library management
system

without which this project would not have completed.

We have taken efforts in this project. However, it would not have been possible without
the kind support and help of many individuals who in one or the another shared their
support, either morally or physically . We would like to extend our sincere thanks to all
of them.
 LIBRABY MANAGEMENT SOFTWARE
Project
Software Requirements Specification
FOR

NATIONAL PUBLIC SCHOOL,BANGALORE.

ABSTRACT

The main objective of the document is to develop a software for "NATIONAL PUBLIC
SCHOOL” library management software. The purpose of the document is to collect all
the requirements from the client and analyze all assorted ideas along with the budget
that have come up to define and develop the system, its functional and non-functional
requirements with respect to consumers.

The main purpose of this SRS document is to provide a detailed overview of our
software product planned to develop, its parameters and goals. This document
describes the project's target audience and its user interface, hardware and software
requirements. It defines how our client, team and audience see the product and its
functionality.
 Table of Contents
1. Introduction
1.1 Scope
1.2 Type of Software
1.3 Motivation of need of project
1.4 An Introduction about Client
2. Glossary
3. User Requirement Definition
3.1 Functional Requirements
3.2 Non - Functional Requirements
3.2.1 Performance Requirements
3.2.2 Scalability Requirements
3.2.3 Usability
3.2.4 Reliability / Availability Requirements
3.2.5 Security Requirements
3.3 User Levels /Characteristic
3.4 Representation for client
4. System Architecture
5. System requirement Specification
5.1 Detailed Description of Functional Requirements

5.2 Detailed Description of Non - Functional Requirements

5.2.1 Usability
5.2.1.1 Graphical User Interface
5.2.1.2 Accessibility
5.2.2 Reliability & Availability
5.2.2.1 Back-end Internal Computers
5.2.3 Performance
5.2.4 Security
5.2.4.1 Data transfer
5.2.4.2 Data Storage
5.2.5 Supportability
5.3 Design Constraints
5.3.1 Standard Development Tools
5.3.2 Desktop client
5.3.3 Online User Documentation and Help system requirement
5.4 Interfaces
5.4.1 User Interfaces
5.4.2 Hardware Interfaces
5.4.3 Software Interfaces
5.4.4 Communication Interfaces
5.5 Licensing Requirements
5.5.1 Legal, Copyright and Other Notices
5.5.2 Applicable Standards
6 System Models
6.1 Software Use-case Diagram
 6.2 Software Sequence Diagram
6.3 State Diagram
6.4 Object Class Diagram
7. System Evolution
8. Financial Aspects
9. Duration
9.1 project plan
9.2 Duration time
10. Conclusion
11. Bibliography
 1. INTRODUCTION
The introduction of the Software Requirements Specification (SRS) provides an overview
of the entire SRS with purpose, scope, definitions, acronyms, abbreviations, references
and overview of the SRS. The aim of this document is to gather and analyze and give an
in-depth insight of the complete National Public School Library Management Software
System that needs to be developed by defining the problem statement in detail.
Nevertheless, it also concentrates on the capabilities required by stakeholders and their
needs while defining high-level product features. The detailed requirements of the
National Public School Library Management are provided in this document.

1.1 Scope

Primarily, the scope pertains to the library management in a given

organization/institution. It focuses on the stakeholders and applications, which allow for
management of library books, users and staff.
This SRS is also aimed at specifying requirements of software to be developed.

1.2 Type of Software

The Software to be developed for the school is a Customized Software.

Customized Software also known as tailor-made software is specially developed for some specific
user or organization, which is the contrast to the widely used software.

1.3 Motivation or Need of the System

This project is developed in response to the need to maintain the details of books and library
members of different libraries.
The maintenance of a physical log book could be tedious and might require higher expense in
long term which cannot be backed up. Also searching and updating records in such a system
could be tiresome.

Department of Computer Science and Engineering 2018-19 Page 1

Therefore, this project is developed to maintain an easy circulation system between clients and
the libraries, to issue books using single library card libraries and to maintain details about the
user.
Hence, we’ll be replacing the existing physical record system with a software that makes library
management easier.

1.4 An Introduction about the Client

The Client is staff member of the school which is located in Jeevan Bheema Nagar, Bangalore.
The school’s library contains various books that can be issued to users based on the availability
of the books and many more. We interacted with the client and collected all the requirements
needed for client organisation’s software.
Client Name : Hima Bindu D
Contact Number of the Client : 9900975826

Department of Computer Science and Engineering 2018-19 Page 2

 2.Glossary
Configuration : It means a product which is available / Selected from a catalogue can be
customized.
FAQ : Frequently Asked Questions.
Functional Requirements : The Functional Requirements Specification documents the
operations and activities that a system must be able to perform.
Non- Functional Requirements : The Non-functional requirements tell you how the
system will run or work properly. The Non-functional requirements are the limitations
on the functions available by the system which are limitations on timing, limitations on
the development process and standards.

Database: A database is a structured collection of records or data which is stored in a

computer so that a program can consult it to answer queries. Think of it as an electronic
filing system and a computer program to access and select desired pieces of data.
Profiles: The Customer information (address, telephone #,email address) created by the
user when he/she registers with the software.


 JAVA -> platform independence
 SQL -> Structured query Language
 DFD -> Data Flow Diagram
 CFD -> Context Flow Diagram
 ER -> Entity Relationship
 IDE -> Integrated Development Environment
 SRS -> Software Requirement Specification
 MTTR -> Mean Time to Repair

Department of Computer Science and Engineering 2018-19 Page 3

 3. USER REQUIREMENTS DEFINITION
Requirements analysis, also called requirements engineering, is the process of
determining user expectations for a new or modified product. These features, called
requirements, must be quantifiable, relevant and detailed.
The user requirement(s) document (URD) or user requirement(s) specification (URS) is a
document usually used in software engineering that specifies what the user expects the
software to be able to do.

3.1 Functional Requirements :-


 R.1:Register
Description : First the user will have to register/sign up. There are two different type of
users.
The library manager/head : The manager have to provide details about the name of
library ,address, phone number, email id.
Regular person/student : The user have to provide details about his/her name of
address, phone number, email id.

 R.1.1: Sign up
Input: Detail about the user as mentioned in the description.
Output: Confirmation of registration status and a membership number and password
will be generated and mailed to the user.
Processing: All details will be checked and if any error are found then an error message
is displayed else a membership number and password will be generated.

 R.1.2 : Login
Input: Enter the membership number and password provided.
Output : User will be able to use the features of software.

 R.2 : Manage books by user.

 R.2.1 : Books issued. Description : List of books will be displaced along with data
of return.

 R.2.2 : Search
Input : Enter the name of author's name of the books to be issued.
Output : List of books related to the keyword.

Department of Computer Science and Engineering 2018-19 Page 4

  R.2.3 : Issues book
State : Searched the book user wants to issues.
Input : click the book user wants.
Output : conformation for book issue and apology for failure in issue.
Processing : if selected book is available then book will be issued else error will be
displayed.

 R.2.4 : Renew book

State : Book is issued and is about to reach the date of return.
Input : Select the book to be renewed.
Output : conformation message.
Processing : If the issued book is already reserved by another user then error message
will be send and if not then conformation message will be displayed.

 R.2.5 : Return
Input ; Return the book to the library.
Output : The issued list will be updated and the returned book will be listed out.

 R.2.6 : Reserve book

Input ; Enter the details of the book.
Output : Book successfully reserved.
Description : If a book is issued by someone then the user can reserve it ,so that later the
user can issue it.

 R.2.6 Fine
Input : check for the fines.
Output : Details about fines on different books issued by the user.
Processing : The fine will be calculated, if it crossed the date of return and the user did
not renewed if then fine will be applied by Rs 10 per day.

 R.3 Manage book by librarian

 R.3.1 Update details of books

 R.3.1.1 Add books

Input : Enter the details of the books such as names ,author ,edition, quantity.
Output : confirmation of addition.

 R.3.1.2 Remove books

Input : Enter the name of the book and quantity of books.
Output : Update the list of the books available.

Department of Computer Science and Engineering 2018-19 Page 5

3.2 Non - Functional Requirements :-
3.2.1 Performance Requirements
 Any record in the database should be easily and quickly accessible to avoid delay.
 The system may be throttled or slowed down on heavy loads to ensure service
for everybody. By throttling is meant that certain functionality may be
unavailable during heavy server load.
 The application should be able to support 100 concurrent users without any
performance degradation.
 Mean Time to Repair (MTTR) - Even if the system fails, the system will be
recovered back up within an hour or less.
2. 3.2.2 Scalability Requirements
The system should be able to scale up to 100 concurrent users (if there is a need in the
future) by installing additional hardware components.
3. 3.2.3 Usability
The user interface of the system should be very user friendly.
It should not take more than 120 seconds for a new user to register for an account.
It should not take more than 90 seconds for a registered user to issue/return a book.
4. 3.2.4 Reliability/Availability Requirements
 The system has to be online 24 hours a day, 7 days a week. There is no place for
an extended downtime.
 The system has to be easily maintainable and recover from crashes quickly.
5. 3.2.5 Security Requirements
 There needs to be clearly defined roles of the users. These roles are 'user’ and
'administrator'. Each person that uses to the system will be required to register if
they want to do more than browse for available books.
 Because of the different roles, passwords and user accounts must be
implemented properly. It should be difficult to gain access to the site in an illegal
manner.

Department of Computer Science and Engineering 2018-19 Page 6

 PERFORMANCE

USABILITY SCALABILITY

NON- FUNCTIONAL
REQUIREMENTS

SECURITY RELIABILITY/ AVAILABILITY

3.3 USER CHARACTERSTICS

We have 3 levels of users :

User module: In the user module, user will check the availability of the books.

1. Issue book

2. Reserve book

3. Return book

4. Fine details

Library module:

1. Add new book

2. Remove books

3. Update details of book

Administration module: The following are the sub module in the administration module :
1. Register user

2. Entry book details

3. Book issue

Department of Computer Science and Engineering 2018-19 Page 7

3.4 Representation for client :

Department of Computer Science and Engineering 2018-19 Page 8

 4. SYSTEM ARCHITECTURE

DATA FLOW DIAGRAM :-

Start

Department of Computer Science and Engineering 2018-19 Page 9

Stop

Department of Computer Science and Engineering 2018-19 Page 10

 5. SYSTEM REQUIREMENT SPECIFICATION

5.1. Detailed Description of Functional Requirements :-

Department of Computer Science and Engineering 2018-19 Page 11

Department of Computer Science and Engineering 2018-19 Page 12
5.2. Detailed Description of Non- Functional Requirements :-
5.2.1 Usability
5.2.1.1 Graphical User Interface
 The system shall provide a uniform look and feel between all the web
pages.
 The system shall provide a digital image for each product in the product
catalog.
 The system shall provide use of icons and toolbars.
5.2.1.2 Accessibility
 The system shall provide handicap access.
 The system shall provide multi language support.
5.2.2 Reliability & Availability
5.2.2.1 Back-end Internal Computers
 The system shall provide storage of all databases on redundant computers
with automatic switchover.
 The system shall provide for replication of databases to off-site storage
locations.
5.2.3 Performance
 The product shall be based on web and has to be run from a web server.
 The product shall take initial load time depending on internet connection
strength which also depends on the media from which the product is run.
 The performance shall depend upon hardware components of the
client/customer.
5.2.4 Security
5.2.4.1 Data Transfer
 The system shall use secure sockets in all transactions that include any
confidential customer information.
 The system shall automatically log out all customers after a period of
inactivity
 The system shall confirm all transactions with the customer’s web browser.
 The system shall not leave any cookies on the customer’s computer
containing the user’s password.

Department of Computer Science and Engineering 2018-19 Page 13

 5.2.4.2 Data Storage
 The customer’s web browser shall never display a customer’s password. It
shall always be echoed with special characters representing typed
characters.
 The customer’s web browser shall never display a customer’s credit card
number after retrieving from the database. It shall always be shown with
just the last 4 digits of the credit card number.
 The system’s back-end servers shall never display a customer’s password.
The customer’s password may be reset but never shown.
 The system’s back-end servers shall only be accessible to authenticated
administrators.
 The system’s back-end databases shall be encrypted.
5.2.5 Supportability
The source code developed for this system shall be maintained in configuration
management tool.

5.3. Design Constraints

5.3.1 Standard Development Tools

The system shall be built using a standard javafx development tool that conforms to
Microsoft’s GUI standards.Javafx will be helping for building desktop client.
5.3.2 Desktop client
 There are no memory requirements
 The product must be stored in such a way that allows the client easy access to it.
 Response time for loading the book should take no longer than five minutes.
 A general knowledge of basic computer skills is required to use the product

Department of Computer Science and Engineering 2018-19 Page 14

5.4. Interfaces
There are many types of interfaces as such supported by the Library management
software system namely;
User Interface, Software Interface and Hardware Interface.
The driver used shall be JDBC.
The Port number used will be 80 for SQL connection for database.
TCP is the transport protocol that manages the exchange of data between hosts.
5.4.1 User Interfaces
The user interface for the software shall be compatible to any browser such as Internet
E5xplorer, Mozilla or Netscape Navigator by which user can access to the system.
The user interface shall be implemented using any tool or software package like Java
Applet, MS Front Page, EJB etc.
5.4.2 Hardware Interfaces
Since the application must run over the internet, all the hardware shall require to connect
internet will be hardware interface for the system. As for e.g. Modem, WAN – LAN,
Ethernet Cross-Cable.
5.4.3 Software Interfaces
1. The e-store shall communicate with the content manager to get the product
specifications, offerings and promotions.
2. The e-store system shall communicate with billPay system to identify
available payment methods , validate the payments and process payment.
3. The e-store system shall communicate to credit management system for
handling financing options.
4. The e-store system shall communicate with Sales system for order
management.
5. The e-store system shall communicate with shipping system for tracking
orders and updating of shipping methods.
6. The e-store system shall communicate with external Tax system to calculate
tax.
5.4.4 Communications Interfaces
The e-store system shall use the HTTP protocol for communication over the internet and
for the intranet communication will be through TCP/IP protocol suite.

Department of Computer Science and Engineering 2018-19 Page 15

5.5. Licensing Requirements
Not Applicable
5.5.1 Legal, Copyright, and Other Notices
E-store should display the disclaimers, copyright, word mark, trademark and product
warranties of the Bhumika electronics, home entertainment and communications.
5.5.2 Applicable Standards
It shall be as per the industry standard.

Department of Computer Science and Engineering 2018-19 Page 16

 6. SYSTEM MODELS

6.1 Software Use-case Diagram :-

Department of Computer Science and Engineering 2018-19 Page 17

Department of Computer Science and Engineering 2018-19 Page 18
6.2 Software Sequence Diagram :-

(a). Register and login sequence diagram

(b) Services user could use

Department of Computer Science and Engineering 2018-19 Page 19

 (c) Services of a library

(d) Full working of the system

Department of Computer Science and Engineering 2018-19 Page 20

6.3 State Diagram :-

6.4 Object Class Diagram :-

Department of Computer Science and Engineering 2018-19 Page 21

7. SYSTEM EVOLUTION
Software change is inevitable to meet all the expectations and demands of the client. As
technology, market and business changes along with time it is very essential to build a
software which is flexible. The necessity to change the Software may occur due to
following reasons :-
 New requirements emerge when the software is used
 The school requirement environment changes
 Errors must be repaired
 New computers and equipment is added to the system
 The performance or reliability of the system may have to be improved
A key problem for developers is implementing and managing change to the existing
software. We planned to keep the copy of the software and it's code and improve it
using new technologies whenever client demands and provide it to client.
After the application is installed on the server, no additional installation will be
necessary since the end-users will be using their desktop client to access.

8. FINANCIAL ASPECTS
The application is estimated to be developed and deployed within the budget of 200000.
For the proposed software there is no requirements of any additional hardware. Only
Basic computer system requirement along with installation of required software is to be
provided. The number of people chosen to work for the project is approximately around
10 members among whom one is a project manager who can be assigned with different
parts of software development.

Department of Computer Science and Engineering 2018-19 Page 22

9. DURATION
9.1 Project Plan :
 Defining the goals and objectives of E-store software.
 Creating a firmware.
 Organizing the contents and creating a content list.
 Creating a task list.
 Setting a timeline.
 Establishing a budget.
 Assemble a team.
 Create a site design and navigation structure.
9.2 Duration Time :
The estimated time to complete the project and deliver a completely working software
to the client is 60 days ( 2 months ).

Department of Computer Science and Engineering 2018-19 Page 23