(Team Name)

Library management system

Software Design Document

Name (s) : 1. K.M Saumya Dubey

(1CD18MCA11)

2. Sunitha S

(1CD18MCA18)

Lab Section:

Workstation:

Date: (O4/27/2019)
TABLE OF CONTENTS

1. INTRODUCTION

1.1 Purpose

1.2 Scope

1.3 Overview

1.4 Reference Material

1.5 Definitions and Acronyms

2. SYSTEM OVERVIEW

3. SYSTEM ARCHITECTURE

3.1 Architectural Design

3.2 Decomposition Description

3.3 Design Rationale

4. DATA DESIGN

4.1 Data Description

4.2 Data Dictionary

5. COMPONENT DESIGN

6. HUMAN INTERFACE DESIGN

6.1 Overview of User Interface

6.2 Screen Images

6.3 Screen Objects and Actions

7. REQUIREMENTS MATRIX
8. APPENDICES

1. INTRODUCTION

1.1 A Library Management System is a software built to handle the primary

housekeeping functions of a library. Libraries rely on library management
systems to manage asset collections as well as relationships with their members.
Library management systems help libraries keep track of the books and their
checkouts, as well as members’ subscriptions and profiles.

Library management systems also involve maintaining the database for entering
new books and recording books that have been borrowed with their respective
due dates.
 1. 1.2 Any library member should be able to search books by their title,
author, subject category as well by the publication date.

2. Each book will have a unique identification number and other details
including a rack number which will help to locate the book.

3. There could be more than one copy of a book, and library members should
be able to check-out and reserve any copy. We will call each copy of a book,
a book item.

4. The system should be able to retrieve information like who took a

particular book or what are the books checked-out by a specific library
member.

5. There should be a maximum limit on how many books a member can

check-out.

6. The system should be able to collect fines for books returned after the due
date.

7. Members should be able to reserve books that are not currently available.

8. The system should be able to send notifications whenever the reserved

books become available, as well as when the book is not returned within
the due date.

9. The system will be able to read barcodes from books and members’ library
cards.

1.3

The implementation of Library Management starts with entering and updating master records like
book details, library information. Any further transaction like book issue, book return will automatically
update the current books.

1.4 Requirements Document Version 1.0

Rational Unified Process – Software Architecture Document template

1.5 ● 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

2. SYSTEM OVERVIEW

The proposed Library Management System will take care of the current book detail at any point of
time. The book issue, book return will update the current book details automatically so that user will get
the update current book details.

● The main purpose of this project is to reduce the manual work.

● This software is capable of managing Book Issues, Returns, and Calculating/Managing Fine.
Generating various Reports for Record-Keeping according to end user requirements

3. SYSTEM ARCHITECTURE
. Architectural Representation
This section describes what software architecture is for the current system, and how it is
represented.

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)

3.1 Architectural Design

This section describes the software requirements and objectives that have some significant
impact on the architecture.
 The key design goals would be:
- Usability
- Stability
- Platform independence
- 3-Tier design methodologies to enable efficient and responsive system

3.2 Decomposition Description

3.3 Design Rationale

Discuss the rationale for selecting the architecture described in 3.1 including critical issues and
trade/offs that was considered. You may discuss other architectures that were considered, provided
that you explain why you didn’t choose them.

4. DATA DESIGN

4.1 Data Description Explain how the information domain of your system is transformed into data
structures. Describe how the major data or system entities are stored, processed and organized. List any
databases or data storage items.

4.2 Data Dictionary

Alphabetically list the system entities or major data along with their types and descriptions. If you
provided a functional description in Section 3.2, list all the functions and function parameters. If you
provided an OO description, list the objects and its attributes, methods and method parameters.

5. COMPONENT DESIGN In this section, we take a closer look at what each component does in a more
systematic way. If you gave a functional description in section 3.2, provide a summary of your algorithm
for each function listed in 3.2 in procedural description language (PDL) or pseudo code. If you gave an
OO description, summarize each object member function for all the objects listed in 3.2 in PDL or
pseudocode. Describe any local data when necessary.

6. HUMAN INTERFACE DESIGN

6.1 Overview of User Interface

Describe the functionality of the system from the user’s perspective. Explain how the user will be able to
use your system to complete all the expected features and the feedback information that will be
displayed for the user.

6.2 Screen Images Display screenshots showing the interface from the user’s perspective. These can be
handdrawn or you can use an automated drawing tool. Just make them as accurate as possible. (Graph
paper works well.)

6.3 Screen Objects and Actions A discussion of screen objects and actions associated with those objects.

7. REQUIREMENTS MATRIX

Provide a crossreference that traces components and data structures to the requirements in your SRS
document. Use a tabular format to show which system components satisfy each of the functional
requirements from the SRS. Refer to the functional requirements by the numbers/codes that you gave
them in the SRS.
8. APPENDICES

Appendices may be included, either directly or by reference, to provide supporting details that could aid
in the understanding of the Software Design Document.