LIBRARY

MANAGEMEN
T
SYSTEM

1.) Megha Jain

roll no:
B.Sc. (Hons.) Comp. Sc. (2nd year)
 ACKNOWLWDGEMENT

Exchange of ideas generates the new object to work in a better way whenever a person
is helped and cooperated by others his heart is bound to pay gratitude and obligation to
them. To develop a project is not a one-man show. It is essentially a collective work,
where every step taken with all precautions and care. Therefore our first duty is to
thanks all persons who took pain in completing this project.

Firstly, we thank Mrs. RACHNA SETHI, who gave us inspiration to do work in this field
and gave us her precious time whenever needed. Thanks may be matter of merely
formality but with us it is expression of heartfelt gratitude to our project supervision. We
are highly indebted for her gestures, invaluable suggestions and boosting confidence to
make this successful. The success of this work is mostly due to her suitable guidance.

We also thank our class fellows and friends, who helped us a lot during our project work.
 CERTIFICATE

This is to certify that the project entitled “LIBRARY MANAGEMENT SYSTEM” prepared
by us, Shobhna & Megha Jainfor the partial fulfilment of the requirements of the B.Sc.
(Hons.) Comp. Sc. degree, embodies the work, we all are doing during 4th semester of
our course under due supervision of the supervisor from this college.

SIGNATURE
 INDEX

S.N Contents Page

N
o
.
Chapter 1
Project Introduction 6-11

1. • Introduction about the project.

7
• Statement of Objectives.
8
• Statement of Scope. 9
• Problems with the current system. 10
• Advantages of the new system being designed. 11

Chapter 2
Project Management 12-33

13
• Introduction about Project Management.
15
• S/W Process Model.
18
2. • Team Structure. 20
• Introduction about S/W Project Scheduling. 21
• Introduction to Time-Line Chart. 22
• Time-Line Chart. 23
• Risk Analysis & Management. 27
• Complexity Tables. 32
• FPA Calculation.

Chapter – 3
Requirement Analysis & Management 34-52

• Introduction about Requirement Analysis & 35

3. Management.
36
• What is Requirement Analysis?
38
• Analysis Principles.
39
• Functional & Non-Functional Requirements. 41
• Data Dictionary.
• Entity Relationship Diagram (ERD). 46
• Data Flow Diagrams (DFD’s). 48
 Chapter – 4
Design 53-86

• Introduction about Design Concepts & Principles. 54

4. 55
• Design Model
56
• Database Design.
61
• Pseudo Code. 64
• Architectural Design. 65
• Interface Design.
 Chapter – 1
Project Introduction

• Introduction about the project.

• Statement of Objectives.
• Statement of Scope.
• Problems with the current system.
• Advantages of the new system being
designed.
 INTRODUCTION
Library Management System is a comprehensive library management
solution that is suitable for both large and small libraries.

Its flexible design enables Library Management System to be installed in a

range of Library organizations, ranging from public libraries, through to
academic, joint use and special libraries.
This Library Management System Software is capable of handling Books &
Periodicals with equal ease and efficiency.

This is a Windows-based Library Management System, utilizing the latest

advancements in the Information Technology to provide and improve Library
Services.
 OBJECTIVE

The objective of this project is to develop an application that will automate the whole
procedure of a library. The software that would be developed should have facilities like
Add / Delete Members, Add / Delete Books, Issue & Return. The application should be
secured, as well as with limited access.
.
The main requirement of the project will be the ease of use, besides being the most
efficient and effective tool for the purpose. The application should be user friendly .It
should be robust and scalable.
An automated solution would be very beneficial to the organization, as it would bring
structure to the whole process so that it can be traced for any kind of query. Also an
automated solution will lead to optimal utilization of the available resources, reducing
duplication of effort, increasing efficiency and minimizing time-delays.

Following are the main objectives of computerization:

• To provide services to all the employees for issue, return & search etc. at one
place.
• To improve co-ordination in staff.
• To reduce paper filling work
• To reduce risk of fraud.
• To reduce chances of information leaking.
 SCOPE

For Members
• Facility for SEARCH of Books based on Accession Number, Title, Author,
Subject, Keyword.

• Facility for ISSUE / RETURN Books.

• Facility for RENEWAL of Books.

For Library Staff

• Automatic installation

• Simple and intuitive GUI for performing all functions

• Short-cut keys and point-and-click operation.

• Security features like access control using passwords and login-i.d.

• Automatic calculation of late-fee.

• Facility to ADD / DELETE Members, Library Staff & Books and Maintain an easy
record of all these.
 PROBLEMS WITH THE
CURRENT SYSTEM

• Issue / Return a book from / to the library is a cumbersome process. Various

details need to be remembered by the staff members. It is very difficult to keep
a track of all the members / books manually.

• Maintenance of the record of each member / book is a very tedious job. Large
amount of human efforts are required to keep a track of members who have
issued a book, who have returned a book and which book is issued / returned.

• Modifying the details of members or books is a very tedious job if done manually.
 ADVANTAGES
The benefits of the proposed software are as follow:

Reliability
The application would efficiently store all the information related to the various processes
in the system and output the relevant information.

Availability
The application would be available to all the employees of the organizations with an
authorized access to the workstations and those who are subject to the authorization
permissions.

Security
The system would have adequate security checking through the authentication of the
users. The reports would only be available to the employees of the library as per their
specific requirements.

Cost Reduction
It can be achieved by minimizing the use of the stationary for reports. Soft copy of all the
reports. Soft copy of all the reports can be viewed and hence reducing the need of the
hard copy.
 Chapter – 2
Project Management

• Introduction about Project Management.

• S/W Process Model.
• Team Structure.
• Introduction about S/W Project
Scheduling.
• Introduction to Time-Line Chart.
• Time-Line Chart.
• Risk Analysis & Management.
• Complexity Tables.
• FPA Calculation.
 PROJECT MANAGEMENT
SYSTEM
Project management involves the planning, monitoring, and control of the people,
process, and events that occur as software evolves from a preliminary concept to an
operational implementation. Effective software project management focuses on the four
principles: people, product, process, and project.

THE PEOPLE

Software engineering institute has developed a people management capability

maturity model (PM-CMM). The people management maturity model defines the key
practice areas for software people like: recruiting, selection, performance management,
training, compensation, carrier development, organization and work design, and
team/culture development.

THE PRODUCT

Before a project can be planned, product objectives and scope should be established,
alternative solutions should be considered and technical and management constraints
should be identified. Scope identifies the primary data, functions and behaviours that
characterize the product.

THE PROCESS

A software process provides the framework from which a comprehensive plan for
Software development can be established.

Framework activities are populated with tasks, milestones, work products and
Quality assurance points. These activities characterize the software product and the
project team.

Umbrella activities i.e. software quality assurance, software configuration management

and measurement overlay the process model.
THE PROJECT

Planned and controlled software projects are conducted to manage complexity.

To avoid project failure, the project manager must avoid a set of common warning signs,
understand critical success factors and develop a common sense approach for planning,
monitoring and controlling the project.
 SOFTWARE PROCESS MODEL
(Linear Sequential Model)

A process model for software engineering is chosen based upon:-

• Nature of the Project.

• Methods and Tools to be used.
• Control and desired deliverables.

The process model, we have chosen to develop this software is a Linear Sequential
Model

Linear Sequential Model suggests a systematic, sequential approach to software

development that begins at the system level and progresses through analysis, design,
coding, testing and support.

Linear Sequential Model approach has the following phases:-

Software requirements analysis

In this, software engineer understand the nature of a program to be built, he must
understand the information domain for the software as well as required function,
behaviour, performance and interface. Requirements for both the system and the
software are documented and reviewed with the customer.

Design
It has four distinct attributes of a program: data structure, software architecture, interface
representations and procedural detail. It is documented and becomes part of the
software.
Code generation
Design must be translated into a machine readable form which is done by code
generation.

Testing
It focuses on the logical internals of the software, ensuring that all the statements have
been tested, and on the functional externals; that is conducting test to uncover errors
and ensure that defined input will produce actual results.

The Software model used is LINEAR SEQUENTIAL MODEL because of the following
reasons:-

 Project being small demands a systematic and sequential approach to software

development i.e. system engineering, software requirement analysis, design, code
generation, testing and support occur in sequence.

 All requirements for the project have been explicitly stated at the beginning.
There is very little scope of customers’ deviation from current requirements, coding
and testing after detailed analysis is much easy.

 Structure is less complex and less innovative with less need of iteration.

Support

This is a phase when software will undoubtedly undergo change after it is delivered to
the customer. Change will occur because errors have been encountered, because the
software must be adapted to accommodate changes in its external environment, or
because the customer requires functional or performance enhancements. Software
support/maintenance reapplies each of the preceding phases to an existing program
rather than a new one.
 TEAM STRUCTURE
The “best” team structure depends on:-

1. Management style of the organization.

2. The number of people who will populate the team and their skill levels, and
3. The overall problem difficulty.

The three generic team organizations are:

Democratic decentralized (DD)

This software engineering team has no permanent leader. Task coordinators are appointed for
short duration and then replaced by others who may coordinate different tasks. Communication
among team members is horizontal.

Controlled decentralized (CD)

This software engineering team has a defined leader who coordinates specific tasks and secondary
leaders that have responsibility for subtasks. Problem solving remains a group activity.
Communication among subgroups and individuals is horizontal.

Controlled centralized (CC)

Top- level problem solving and internal team coordination are managed by a team leader.
Communication between the leader and team members is vertical.

The team structure used in our project is DEMOCRATIC DECENTRALISED. The team comprises
of two members:-

• Shobhna(7840)

• Megha Jain(7837)
Decentralized teams generate better solutions and have greater probability of success
when working on different problems. DD team structure is best applies to programs with
low modularity.

Based on the difficulty of the problem to be solved relatively low modularity of the project
and high volume of the communication required a democratic decentralized team
structure is proposed. This software engineering team has no permanent leader. Rather,
“task coordinators are appointed for short duration and then replaced by others who may
coordinate different tasks.” Problem solving is a group activity. Communication among
team members is horizontal. Decentralized team generates more and better solutions
than individuals. Therefore such teams have a greater probability of success when
working on difficult problems.

A decentralized structure can be applied to both simple and difficult problems, but it is
best applied in case of difficult problems. These team structures result in high morale,
therefore good for teams that will be together for a long time. The decentralized team
structure is best applied to the problem with relatively low modularity because of the
higher volume of communication needed. These teams require more time to complete a
project and at a same time be best when high sociability is required. In these teams,
team members have trust on each other, distribution of skills must be appropriate to the
problem and they share a common goal.
 SOFTWARE PROJECT
SCHEDULING

WHAT IS IT?
Software Project Scheduling is an activity that distributes estimated effort across the
planned project by allocating the effort to a specific software engineering tasks.

When you develop a schedule, compartmentalize the work, represent the task
interdependencies, allocate effort and time to each task, define responsibilities for the
work to be done, and define outcomes and milestones.

WHY IS IT IMPORTANT?

In order to build a complex system, many software engineering tasks occur in parallel,
and result of work performed during one task may have a profound effect on work to be
conducted in another task. These interdependencies are very difficult to understand
without a schedule. It’s also a virtually impossible to progress on a moderate or large
software project without a detailed schedule.
 INTRODUCTION TO TIMELINE
CHART
When creating a software project schedule, the planner begins with a set of tasks. If
automated tools are used, the work breakdown is input as a task network or task outline.
Effort, duration and start date are then input for each task outline. In addition, tasks may
be assigned to specific individuals.

As a consequence of this input a Timeline Chart is generated. It enables you to

determine what tasks will be conducted at a given point of time.
 TIMELINE CHART

S. TASK Date of Date Of

No. Start Completion
Requirement
1 gathering &
Analysis
1.1 Library Staff 02.01.2008 04.01.2008

1.2 Members 06.01.2008 09.01.2008

(Students &
Teachers)
1.3 Search 11.01.2008 14.01.2008

1.4 Issue & Return 16.01.2008 23.01.2008

1.5 FPA Calculation 25.01.2008 31.01.2008

1.6 Data Dictionary 02.02.2008 05.02.2008

1.7 ERD 07.02.2008 11.02.2008

1.8 DFD 15.02.2008 21.02.2008

2 Design
2.1 Data Design 24.02.2008 29.02.2008

2.2 Architectural 10.03.2008 15.03.2008

Design
2.3 Interface Design 17.03.2008 23.03.2008
 RISK ANALYSIS &
MANAGEMENT

Risk analysis and management are a series of steps that help a software team to
understand and manage uncertainty. Many problems can plague a software project, a
risk is a potential problem that might happen or might not.

RISK IDENTIFICATION

This is the first step for recognizing what can go wrong.

Next, each risk is analyzed to determine the likelihood that it will occur and the damage
that it will do if it does occur. Once this information is established, risks are ranked by
their probability and impact. Finally, a plan is developed to manage those risks with high
probability and impact.

IT’S WORK PRODUCT

Risk mitigation, monitoring and management (RMMM) plan or a set of risk information
sheets is produced.
 CATEGORIES OF RISK

Project Risks

They threaten the project plan. They identify potential budgetary, schedule, personnel,
resource, custom potential and requirements problem and there impact on software
project. They might result in delay in project schedule and cost.

Technical Risks

They identify potential design, implementation, interface verification, and maintenance

problem. They threaten the quality and timeliness of software

Business Risks

They often jeopardize the project or the product & include market risk, strategic risk,
management risk and budget risk.
 Risk Mitigation Plan

All risk analysis activities presented to this point have a single goal-to assist the project
team in developing a strategy for dealing with risk.

Issues:
• Risk avoidance
• Risk monitoring
• Risk management and contingency planning

Steps taken are:

• Meet with current staff and check cause for problems
• Mitigate causes which are under control before project starts
• Presume turnover will occur develop plans
• Conduct peer reviews
 RISK STRATEGIES
Reactive

A Reactive Strategy monitors the risk project for likely risk and set aside resources to
deal with them, should they become actual problems. Software team does nothing about
risks until something goes wrong.

Proactive

A Proactive strategy begins long before technical work is initiated. Potential risks are
identified, their probability impact is assessed, and they are ranked by importance.
Complexity
Tables
INPUT SCREEN COMPLEXITY
TABLE
S. No Screen No. of fields No. of files Complexity
Name
1. Add Member 10 1 Average

2. Add Book 8 1 Average

3. Issue With 3 3 Average

Member ID
4. Issue With 3 3 Average
Acc. No.

5. Issue 4 3 Average

6 Return 2 2 Low

7. Return after 1 3 Low

Fine
S. No Screen No. of fields No. of files Complexity
Name
1. Member 11 2 Average
Search
2. Member’s 11 2 Average
Detail
3. Book Search 9 1 Average

4. Book’s Detail 8 1 Average

OUTPUT SCREEN
COMPLEXITY TABLE
QUERY SCREEN COMPLEXITY
TABLE
S. No Screen No. of fields No. of files Complexity
Name
1. Log-in 2 1 Low

2. Delete Member 1 1 Low

3. Delete Book 1 1 Low

4. Check 1 1 Low
Member’s
Record
5. Check Book’s 1 1 Low
Detail
S. No File Name No. of fields No. of Complexity
records
1. Member’s 14 1 Low
Record
2. Book’s Record 8 1 Low

3. Staff Record 10 1 Low

ILF COMPLEXITY TABLE

FPA Calculation
 UNADJUSTED FUNCTIONAL
POINT CALCULATION
Simple Average Complex Total
No. of inputs 2*3 5*4 0*6 26
No. of outputs 0*4 4*5 0*7 20
No. of files 3*7 0*10 0*15 21
No. of queries 5*3 0*4 0*6 15
UFP 82

Function Point Calculation

FP= UFP * ( 0.65 + 0.01 * ∑Fi )

= 82 * ( 0.65 + 0.01 * 42)
= 82 * 1.07
= 87.74
 Chapter – 3
Requirement
Analysis &
Management

• Introduction about Requirement

Analysis & Management.
• What is Requirement Analysis?
• Analysis Principles.
• Functional & Non-Functional
Requirements.
• Data Dictionary.
• Entity Relationship Diagram (ERD).
• Data Flow Diagrams (DFD’s).
 INTRODUCTION

This is the process of deriving system requirements through observation of existing

system, discussions with potential users, task analysis and so on. This may involve the
development of one or more different system model. These help the analyst to
understand the system to be more specific.
 REQUIREMENT ANALYSIS
Requirement analysis is a software engineering task that bridges the gap between
system level requirements engineering and software design.

System
Level
Engineerin
g
Requirement
Analysis

Software
Design

The software requirements analysis may be divided into five areas of efforts:-

Problem recognition

Recognition of basic problem elements as perceived by the users.

Evaluation and synthesis

Define all data objects, evaluate the flow and content of information, define and
elaborate all functions, understand software behaviour and establish interface
characteristics.

Modelling

Functional models represent the information that software transforms, functions enabling
the transformation, and behaviour of the system during transformation.

Specification

States the goals and objectives of the software, describing it in context of the
Computer based system.

Review

Changes to the specification may be recommended.

 Analysis Principles

1. The information domain of a problem must be represented and understood.

2. The functions to be performed by software must be defined.

3. The behaviour of the software must be represented.

4. The models that depict information function and behaviour must be partitioned in a
manner that uncovers detail in a layered fashion.

5. The analysis process should move from essential information towards implementation
detail.
 NON-FUNCTIONAL
REQUIREMENTS
(1) Server must have enough disk space so as to store large amount of data.

(2) System should provide data security. Unauthorized users should not be allowed
to access the system so that the integrity and secrecy of each client must be
maintained.

(3) A network operating system that can support the software.

FUNCTIONAL REQUIREMENTS

(1) The system must be easy to learn and easy to use so that it is readily accepted
by its prospective users. It must provide easy and convenient means of
communication between different clients.

(2) It should synchronize the access of channels to clients. No two clients should be
allowed to transmit data simultaneously.

(3) It must detect collisions and recover lost messages.

(4) Client should not be allowed to run while the server is not running.

(5) It must handle exceptional conditions appropriately and efficiently.

(6) Appropriate error messages should be generated in case some exception has
occurred.

(7) It must support client-to-client communication as well as broadcasting.

(8) System must be fault tolerant i.e. it can continue in operation even after some
system failure has occurred.
 DATA
DICTIONARY
S. No. Data Item Type Length Description

1 TEACHERS

Contains
1.1 Name String 30 Name of the
teacher
Contains
1.2 F. Name String 30 Father’s
Name of the
teacher
Contains
1.3 M. Name String 30 Mother’s
Name of the
teacher
1.4 D.O.B. Integer 10 Date of Birth

1.5 Sex String 6 Sex Of the

teacher
1.6 Add. String 50 Residential
Address
1.7 Ph. No. Integer 10 Contact
Number
Subject
1.8 Subject String 10 taught by the
teacher
1.9 Coll. I.D. Integer 10 College I.D.
No.
1.10 Yr. Of Join Integer 4 Year of
joining

2 STUDENTS

Contains
2.1 Name String 30 Name of the
student
Contains
2.2 F. Name String 30 Father’s
Name of the
student
 Contains
2.3 M. Name String 30 Mother’s
Name of the
student
2.4 D.O.B. Integer 10 Date of Birth
2.5 Sex String 6 Sex Of the
student
2.6 Add. String 50 Residential
Address
2.7 Ph. No. Integer 10 Contact
Number
Course
2.8 Course String 10 chosen by
the student
College Code
2.9 Coll. Code Integer 10 of the
student
2.10 Yr. Of Integer 4 Year of
Admission admission

3 ISSUE /
RETURN
3.1 Dt. Of Issue Integer 10 Date of issue
3.2 Dt. Of Return Integer 10 Date of
return
3.3 Actual Dt. Of Integer 10 Actual Date
Return of return

4 MEMBER’S
RECORD

4.1 Member I.D. Integer 10 Member’s

I.D. No.
Number of
4.2 No. Of Books Integer 1 books issued
Issued on member’s
account
Date of
4.3 Validity Integer 4 expiry of
membership
 Fine to be
4.4 Fine Till Date Integer 4 paid till
present date

5 BOOKS

Contains
5.1 Name String 30 Name of the
book
Contains
5.2 Author String 30 Author’s
Name of the
book
Contains
5.3 Publisher String 30 Publisher’s
Name of the
book
5.4 Edition Integer 2 Edition of the
book
No. of copies
5.5 No. Of Copies Integer 3 available of
the book
Price per
5.6 Price/Copy Integer 4 copy of the
book
5.7 Acc. No. Integer 10 Acc. Number
of the book
Subject
5.8 Subject String 20 related to the
book

6 LIBRARY
STAFF

Contains the
6.1 Name String 30 Name of the
staff member

Contains
Father’s
6.2 F. Name String 30 Name of the
staff member
 Contains
6.3 M. Name String 30 Mother’s
Name of the
staff member
6.4 D.O.B. Integer 10 Date of Birth
6.5 Sex String 6 Sex Of the
staff member
6.6 Add. String 50 Residential
Address
6.7 Ph. No. Integer 10 Contact
Number
6.8 Yr. Of Join Integer 4 Year of
joining
Login I.D. of
6.9 Login I.D. String 20 staff member
Password of
6.10 Password String 20 the staff
member
 Entity
Relationship
Diagram
(ERD)
Data Flow
Diagrams
(DFD’s)
Level ‘0’ DFD
Level ‘1’ DFD
Chapter – 4
 Design

• Introduction about Design Concepts &

Principles.
• Design Model
• Database Design.
• Pseudo Code.
• Architectural Design.
• Interface Design.
 DESIGN CONCEPTS &
PRINCIPLES

Design is a meaningful engineering representation of something that is to be built. It can

be traced to customer’s requirements and at the same time assessed for good quality
against a set of predefined criteria for a “Good Design”.

Software Design is applied regardless of the software process model that is used. Once
software requirements have been analyzed and specified, software design is the first of
three technical activities – design, code generation and test – that are required to build
and verify the software.

Design focuses on four major areas of concern: data, architecture, interfaces and
components.

COMPONENT LEVEL DESIGN

It transforms structural elements of software architecture into a procedural description of
software components.

INTERFACE DESIGN
It describes how the software communicates within itself, with systems that interoperate
with it, and with the users who use it.

ARCHITECTURAL DESIGN

It defines the relationship between major structural elements of the software.

DATA DESIGN
It transforms the information domain model created during analysis into the data
structures that will be required to implement the software.

DESIGN MODEL

D
M

COMPONENT

LEVEL

DESIGN

INTERFACE
DESIGN

ARCHITECTURAL
DESIGN

DATA
DESIGN
 DATABASE DESIGN

TEACHERS

S.No. Data Type Length Description Mandatory/ Primary

Item Optional Key
Contains
1.1 Name String 30 Name of the M -
teacher
Contains
1.2 F.Na String 30 Father’s O -
me Name of the
teacher
Contains
1.3 M.Na String 30 Mother’s O -
me Name of the
teacher
1.4 D.O.B Integer 10 Date of Birth O -
.
1.5 Sex String 6 Sex Of the M -
teacher
1.6 Add. String 50 Residential O -
Address
1.7 Ph. Integer 10 Contact O -
No. Number
Subject
1.8 Subje String 10 taught by the M -
ct teacher
1.9 Coll.I. Integer 10 College I.D. M YES
D. No.
1.10 Yr. Of Integer 4 Year of O -
Join joining
STUDENTS

S.No. Data Type Length Description Mandatory/ Primary

Item Optional Key
Contains
2.1 Name String 30 Name of the M -
student
Contains
2.2 F.Name String 30 Father’s O
Name of the -
student
Contains
2.3 M. String 30 Mother’s O -
Name Name of the
student
2.4 D.O.B. Integer 10 Date of Birth O -
2.5 Sex String 6 Sex Of the M -
student
2.6 Add. String 50 Residential O -
Address

2.7 Ph. No. Integer 10 Contact O -

Number
Course
2.8 Course String 10 chosen by M -
the student
College Code
2.9 Coll. Integer 10 of the M YES
Code student
2.10 Yr. Of Integer 4 Year of O -
Admiss admission
ion
ISSUE / RETURN

S.No. Data Type Length Description Mandatory/ Primary

Item Optional Key
3.1 Dt. Of Integer 10 Date of issue M -
Issue
3.2 Dt. Of Integer 10 Date of M -
Return return
Actual
3.3 Dt. Of Integer 10 Actual Date M -
Return of return

Member’s Record

S.No. Data Type Length Description Mandatory/ Primary

Item Optional Key
4.1 Member Integer 10 Member’s M YES
I.D. I.D. No.
Number of
No. Of books issued
4.2 Books Integer 1 on member’s M -
Issued account
Date of
4.3 Validity Integer 4 expiry of M -
membership

4.4 Fine Till Integer 4 Fine to be M -

Date paid till
present date
BOOKS

S.No. Data Type Length Description Mandatory/ Primary

Item Optional Key
Contains
5.1 Name String 30 Name of the M -
book

Contains
5.2 Author String 30 Author’s M -
Name of the
book
Contains
5.3 Publisher String 30 Publisher’s M -
Name of the
book
5.4 Edition Integer 2 Edition M -
No. Of No. of copies
5.5 Copies Integer 3 available O -
Price per
5.6 Price/Copy Integer 4 copy of the O -
book
Acc. Number
5.7 Acc. No. Integer 10 of the book M YES
Subject
5.8 Subject String 20 related to the M -
book
LIBRARY STAFF

S.No. Data Type Length Description Mandatory/ Primary

Item Optional Key
Contains
6.1 Name String 30 Name of the M -
staff member
Contains
Father’s
6.2 F.Name String 30 Name of staff O -
the member
Contains
Mother’s
6.3 M.Name String 30 Name of the O -
staff member
6.4 D.O.B. Integer 10 Date of Birth O -
Sex Of the
6.5 Sex String 6 staff member M -
6.6 Add. String 50 Residential O -
Address
6.7 Ph. No. Integer 10 Contact O -
Number
6.8 Yr. Of Integer 4 Year of M -
Join joining
Login I.D. of
6.9 Login I.D. String 20 staff member M YES
Password of
6.10 Password String 20 the staff M -
member
 Pseudo Code

Login Screen
This screen takes the unique login-id & password of the library staff member allowing
him/her to use the system at his/her level of interference.

Menu Screen
This screen asks the library staff member to input the choice of task he/she wants to
perform. Choices include- Add/Delete a member, Add/Delete a book, Search for a
member/book, Check the details of a particular member/book, Issue/Return a book etc.

Add a new member

This screen takes the details of the new member to be added from the library staff &
then accepts the new member as a part of the library unless & until some fields are not
left empty or are given invalid inputs. Details include- Name, Father’s name, Mother’s
name, Sex, Address, Phone No., College code, Year of joining/Admission, Status in the
college (whether Student or Teacher), Course etc.

Delete a member
This screen takes the member’s id of the member to be deleted as the input from the
library staff & then deletes the member from the library records unless an invalid
member id is not entered by the staff member.

Add a new book

This screen takes the details of the new book to be added from the library staff & then
makes the new book available for Issue/Return unless & until some fields are not left
empty or are given invalid inputs. Details include- Name, Author’s name, Publisher’s
name, Edition, No. of copies, Price per copy, Acc. No., Subject etc.
Delete a book
This screen takes the Acc. No. of the book to be deleted as the input from the library
staff & then deletes the book from the library records unless an invalid Acc. No. is not
entered by the staff member. The book deleted no longer remains available for
Issue/return purposes.

Search for a member

This screen takes some description about the member to be searched according to the
method of searching chosen by the library staff member. The methods of searching
include- Search by name, by course, by member id etc. The records found are displayed
on the same screen (if they really exist). This screen also allows the staff member to
select a name from the records found & then check the details of the member directly
from here.

Check member details

This screen takes the member id as the input from the library staff member & then
searches for the member among a list of members and then displays the full details of
the member searched if a valid member id is provided as the input. This screen also
allows the library staff to issue this member a book directly from this screen as the staff
member doesn’t needs to enter the member id while issuing the book. The book is
issued unless the member’s account is not full (max. of 5 books is taken as an
assumption) or an invalid Acc. No. is not added.

Search for a book

This screen takes some description about the book to be searched according to the
method of searching chosen by the library staff member. The methods of searching
include- Search by name, by subject, by author etc. The records found are displayed on
the same screen (if they really exist). This screen also allows the staff member to select
a book from the records found & then check the details of the book directly from here.

Check book details

This screen takes the Acc. No. as the input from the library staff member & then
searches for the book among a list of books and then displays the full details of the book
searched if a valid Acc. No. is provided as the input. This screen also allows the library
staff to issue this book directly to a member from this screen as the staff member doesn’t
needs to enter the Acc. No. while issuing the book. The book is issued unless the
member’s account is not full (max. of 5 books is taken as an assumption) or an invalid
member id is not added.
Issue
This screen takes member id, Acc. No., Date of issue, Date of return from the library
staff & then issues the selected book the member unless an invalid member id or Acc.
No. is not entered by the staff member or the member’s account is not full (max. of
5books is taken as an assumption) or else the book is not already issued to some other
member.

Return
This screen takes the member id, Acc. No. as the input from the library staff & then
displays the details of the book. The details include- Date of issue, Date of return. Date
of actual return is entered by the staff member & the fine is calculated if the Actual date
of return is later than the Date of return specified to the member. The book is then
deleted from the member’s account when all dues are cleared and it is again available
for issue/return purposes.
Architectural Design
Interface Design