Software Design Specification

<LIBRARY MANAGEMENT SYSTEM >

Project Code:

Project Manager: Dr. Muhammad Ilyas

Project Team: Abeer zafar

Submission Date: FEB 20 ,2023

_____________________
Project Manager’s Signature
<Project code> Software Design Specification
<Version x>

Document Information

Category Information
Customer Department of CS & IT
Project Library Management system
Document Software Design Specification
Document Version 1.0
Identifier <PGBH01-2003-DS>
Status Draft
Author(s) Abeer Zafar
Approver(s) Dr.Muhammad Ilyas
Issue Date Sept. 15, 2022
Document Location University of Sargodha
1. Advisor
Distribution 2. PM
3. Project Office

Definition of Terms, Acronyms and Abbreviations

This section should provide the definitions of all terms, acronyms, and abbreviations required to interpret the terms
used in the document properly.

Term Description
FS Functional specification

Feb 20, 2023 Page 2 of 11

<Project code> Software Design Specification
<Version x>

Table of Contents

1. Introduction..............................................................................................................................4
1.1 Purpose of Document.....................................................................................................................4
1.2 Project Overview.............................................................................................................................4
1.3 Scope................................................................................................................................................4

2. Design Considerations.............................................................................................................4
2.1 Assumptions and Dependencies..................................................................................................4
2.2 Risks and Volatile Areas................................................................................................................4

3. System Architecture................................................................................................................4
3.1 System Level Architecture.............................................................................................................4
3.2 Sub-System / Component / Module Level Architecture............................................................5
3.3 Sub-Component / Sub-Module Level Architecture (1…n)........................................................5

4. Design Strategies......................................................................................................................5
4.1 Strategy 1…n....................................................................................................................................5

5. Detailed System Design...........................................................................................................5

6. References.................................................................................................................................6

7. Appendices................................................................................................................................6

Feb 20, 2023 Page 3 of 11

<Project code> Software Design Specification
<Version x>

1. Introduction
1.1 Purpose of Document
the purpose of a software design specification document for a project is to provide a detailed
description of the software design and architecture of the system being developed. It outlines
the software’s functionality, features, and operation, as well as the design principles,
patterns, and methodologies that were used to develop the system. The document serves as a
guide for developers, stakeholders, and other members of the project team, helping them to
understand the design goals, how the software works, and how to implement new features
and functionalities. It also serves as a reference document for future maintenance and
enhancement of the software.

1.2 Project Overview

the software system is a library management system that allows users to manage books,
library users, and book transactions .The basic design approach for the software system
would likely involve a modular design, where each function or feature is designed and
developed as a separate module. This would allow for easier testing and maintenance of the
system
1.3 Scope
What the System Will Do:
 Allow librarians to add, edit, and delete book records
 Allow librarians to view all book records in the library
 Allow librarians to search for books by title, author, or ISBN
 Allow librarians to add, edit, and delete library user records
 Allow librarians to view all library user records
 Allow librarians to search for library users by name or ID
 Allow librarians to issue and return books to/from library users
 Allow librarians to view all book transactions, including checkouts and returns
What the System Will Not Do:
The system will not perform any tasks or functions outside of the scope of the project. It will not
perform any tasks that are not related to managing the library collection books , and library user
accounts.

2. Design Considerations
2.1 Assumptions and Dependencies
Assumptions:
 The system will be designed for use on a desktop or laptop computer.
 Users of the system will have basic computer literacy skills.
 The system will be developed using a specific programming language .
Dependencies:

Feb 20, 2023 Page 4 of 11

<Project code> Software Design Specification
<Version x>

 The design of the system will be informed by the functional and non-functional
requirements outlined in the FS document.
 The availability of resources, including hardware, software, and personnel, may impact
the design of the system.
 The design of the system may need to accommodate future scalability or expansion,
based on the library’s needs and growth over time.

2.2 System Architecture

This section should provide a high-level overview of how the functionality and responsibilities of the system are
partitioned and then assigned to subsystems or components. The main purpose is to gain a general
understanding of how the system is decomposed, and how the individual parts work together to provide the
desired functionality.

2.3 System Level Architecture

The decomposition of the online Library mangemnt system is the following
User Interface:
 main_menu()

 view_all_book()

 add_book()

 edit_book()

 delete_book()

 add_library_user()

 view_library_user()

 edit_user()

 delete_user()

 search_user()

 issue_book()

 delete_issue_book()
The online library management system can be decomposed into several functional areas such as book
management, user management, and book issue management. The relationships between these areas can be
defined by the interfaces between the subsystems.

Feb 20, 2023 Page 5 of 11

<Project code> Software Design Specification
<Version x>

2.4 Sub-System / Component / Module Level Architecture

2.4.3 Sub-System Level Architecture:
Here’s a possible decomposition of the system into sub-systems:
Book Management Sub-System: responsible for managing the books in the library, including adding,
editing, viewing, and deleting books.
User Management Sub-System: responsible for managing library users, including adding, editing,
viewing, and deleting user accounts, and searching for users.
Issue Management Sub-System: responsible for managing the process of issuing and returning books to
users.
Menu Sub-System: responsible for displaying the menu options and receiving user input.
2.4.2 Component Level Architecture:
1. User Interface Component: This component would be responsible for presenting the main menu
to the user and providing options to add, edit, view, or delete books and library users, search for
users, issue, and return books, and view the issued books.
2. Book Management Component: This component would manage the book-related operations,
including adding, editing, deleting, and viewing all books.
3. User Management Component: This component would handle the user-related operations,
including adding, editing, deleting, searching, and viewing all library users.
4. Issue Management Component: This component would manage the book issuing and returning
operations, including issuing a book to a user, deleting issued books, and viewing issued books.
The components would interact with each other based on the defined interfaces to support the overall
functionality of the library management system.
2.4.3 Module level Architecture:
Database Module: This module would be responsible for storing and retrieving book and user data.
Authentication Module: This module would handle user authentication, ensuring that only authorized
users have access to the system.

Feb 20, 2023 Page 6 of 11

<Project code> Software Design Specification
<Version x>

2.5 Sub-Component / Sub-Module Level Architecture (1…n)

3. Design Strategies
3.1 Separation of Concerns: The system should be designed to separate the concerns of different
components, such as user interface, book management, user management, and issue management.
This will make the system more modular, maintainable, and extensible
3.2 Data Persistence: The system should be designed to persist data in a database, which will allow the
system to store and retrieve data effectively. This will enable the system to handle a large amount of
data, and support data consistency and data integrity
3.3 Error Handling: The system should be designed to handle errors effectively, including providing
error
messages, logging, and preventing system failures. This will improve the system’s reliability and
help users to understand the system’s behavior.

4. Detailed System Design

 Class diagram
 Sequence diagram

Feb 20, 2023 Page 7 of 11

<Project code> Software Design Specification
<Version x>

CLASS DIAGRAM:

Feb 20, 2023 Page 8 of 11

<Project code> Software Design Specification
<Version x>

SEQUENCE DIAGRAM:

Feb 20, 2023 Page 9 of 11

<Project code> Software Design Specification
<Version x>

Feb 20, 2023 Page 10 of

11
<Project code> Software Design Specification
<Version x>

Feb 20, 2023 Page 11 of

11