CONTENTS

OVERVIEW OF ORGANIZATION

1. PREFACE
2. INTRODUCTION
3. NEED OF ONLINE SHOPPING SYSTEM
4. PROFILE OF THE PROBLEM
5. STRUCTURE OF THE PROJECT
6. SOFTWARE DEVELOPMENT LIFE CYCLE
7. PROBLEM ANALYSIS
8. PROJECT PLAN
9. AVTIVITIES DURING SOFTWARE PROJECT PLANNING
10. HARDWARE AND SOFTWARE REQUIREMENT
11. FRONT-END DETAILS
12. BACK-END DETAILS
13. SYSTEM DESIGN
14. DESIGN NOTATIONS
15. PRODUCT FUNCTION
16. DETAILED DESIGN
17. E-R DIAGRAMS
18. DATA FLOW DIAGRAMS
19. TESTING
20. METHODOLOGY USED FOR TESTING
21. IMPLEMENTATION
22. USER MANUAL
23. ABBREVIATIONS/ ACRONYMS
24. SCREEN-SHORTS OF THE PROJECT
Blood bank donor management system Page |1
ABSTRACT:

The Blood Bank Donor Management System (BBDMS) is a web-based application designed to
automate and streamline the operations of blood donation, donor management, and blood request
handling. The increasing demand for blood in medical emergencies, surgeries, and treatments has
highlighted the need for an efficient system that can facilitate real-time access to blood availability
and donor information. Traditional manual systems are time-consuming, error-prone, and often fail
to deliver the required data during emergencies. This project aims to solve these challenges through
a digital platform developed using PHP, MySQL, HTML, CSS, and JavaScript.

The system provides a centralized database where information about donors, blood groups, available
stock, and donation history is stored securely. Donors can register themselves, update their profiles,
and be notified when there is a need for their specific blood type. Users or recipients can search for
available blood types, view donor details based on location and compatibility, and make requests
through a user-friendly interface.

Key features of BBDMS include donor registration and login, blood group search functionality,
blood request handling, real-time blood inventory management, and an optional notification
system to alert registered donors about urgent needs. The use of PHP and MySQL ensures fast,
secure, and reliable performance, while the user interface is designed to be intuitive and accessible
to users with varying technical backgrounds.

By digitalizing the blood donation and distribution process, BBDMS contributes to saving lives
through quicker access to blood, improved donor management, and accurate tracking of blood units.
This system not only enhances operational efficiency for blood banks but also promotes voluntary
blood donation by providing transparency and recognition to the donors.

Security and privacy are considered in the design by implementing user authentication, access
control, and safe handling of sensitive data. BBDMS also integrates optional features like email or
SMS alerts, real-time stock level dashboards, and printable donor cards, making it highly scalable and
adaptable to future enhancements.

Blood bank donor management system Page |2

Introduction:

Blood is one of the most essential components of human life. Every day, thousands of patients
around the world require blood transfusions for surgeries, accidents, medical conditions such as
anemia or cancer, and childbirth complications. However, in many cases, delays or the unavailability
of blood at the right time can lead to fatal outcomes. The problem is not always a lack of donors but
a lack of proper systems to connect donors and recipients efficiently. In many regions, blood banks
still rely on outdated methods such as handwritten logs, spreadsheets, and telephonic coordination,
which are time-consuming, error-prone, and inefficient during emergencies. These challenges
highlight the urgent need for an intelligent, real-time, and easily accessible platform that can manage
blood donations and requests in a systematic manner.

The Blood Bank Donor Management System (BBDMS) is designed to bridge this gap by introducing
automation and centralization into the process of blood donation and management. Developed using
PHP and MySQL, this system provides an end-to-end solution that allows blood banks to maintain
donor records, manage blood inventories, and respond to blood requests effectively. The application
also empowers donors to actively participate in the donation process by registering, receiving
notifications, and viewing their donation history. On the other hand, recipients or patients’ families
can quickly find available donors or blood stock based on blood group and location, and place a
request with just a few clicks.

The BBDMS platform comprises three primary user roles—Admin, Donor, and Recipient/User.
Admins are responsible for managing the backend operations, including maintaining blood stock,
approving new donors, handling donation requests, and generating statistical reports. Donors have
the ability to manage their personal profiles, monitor their eligibility based on donation intervals,
and respond to urgent donation requests. Recipients can search for matching blood types, send out
requests, and get contact details or assistance from blood banks. All of this is supported by a user-
friendly interface, making the system accessible even to users with minimal technical skills.

One of the key advantages of BBDMS is its scalability and adaptability. It can be deployed at a local
blood bank level, within hospital networks, or expanded into a national-level blood management
portal. It supports real-time blood availability tracking, which reduces panic during critical times and
ensures quicker response to emergencies. Additionally, optional features such as SMS/email alerts to
donors, live chat assistance, and integration with GPS for location-based donor matching can be
added for further efficiency.

Blood bank donor management system Page |3

In conclusion, the Blood Bank Donor Management System is not just a digital tool—it is a life-saving
platform. By combining technology with healthcare needs, BBDMS contributes to a more organized,
reliable, and effective blood donation ecosystem. Its implementation can drastically reduce the time
taken to locate donors, prevent the wastage of blood due to expiry, and ultimately, save countless
lives. As societies grow increasingly digital, systems like BBDMS are not just helpful—they are
essential.

Objectives:
The Blood Bank Donor Management System (BBDMS) is developed with the aim of
improving the efficiency and effectiveness of blood donation, tracking, and management
processes. The system seeks to address the critical challenges faced by blood banks,
hospitals, and medical centers in managing blood donations, donor data, and the timely
delivery of blood to those in need. The key objectives of this project are outlined as follows:

1. Efficient Donor Management

2. Real-Time Blood Availability Tracking
3. Easy Search and Blood Request System
4. Automated Notifications for Donors
5. Administrator Control and Reporting
6. Enhanced Communication Between Donors and Recipients
7. Security and Privacy
8. Integration with Third-Party Services
9. Scalability and Flexibility
10. Promoting Blood Donation Awareness

Need of Blood Bank Management System:

The need for an efficient and reliable Blood Bank Management System has become
increasingly critical due to the growing demand for blood in medical emergencies, surgeries,
and various medical treatments. Blood donation is a vital act of humanity, and its proper
management is essential to save lives. The traditional methods of managing blood
donations, stocks, and requests have numerous limitations, making it difficult to provide
timely and adequate blood to those in need. Below are the key reasons why the
implementation of a Blood Bank Management System (BBDMS)

Increasing Demand for Blood

The demand for blood has been steadily increasing due to several factors:

 Medical Procedures: Hospitals and clinics routinely perform surgeries, cancer

treatments, organ transplants, and emergency procedures that require blood
Accidents and Disasters: Traffic accidents, natural disasters, and accidents in

Blood bank donor management system Page |4

 workplaces often lead to large numbers of people needing immediate blood
transfusions.

PROFILE OF THE PROBLEM:

The efficient management of blood donations and distribution is one of the most critical
aspects of modern healthcare. Blood is an irreplaceable resource that plays a vital role in
saving lives, particularly in emergency situations such as accidents, surgeries, childbirth
complications, and treatment of various chronic illnesses. However, despite its critical
importance, the management of blood donations, inventory, and blood requests is often
plagued with challenges that affect the timely and efficient delivery of blood to patients in
need.

 Delay in providing blood to patients during emergencies.

 Wastage of valuable blood due to improper tracking of blood expiration.

 Lower donor participation due to lack of engagement and awareness.

 Health risks from errors in blood matching or inventory management.

 Operational inefficiencies that increase costs and reduce the overall effectiveness of
blood banks.

STRUCTURE OF THE PROJECT

1. Presentation Layer (Front-end)

This is the user interface of the system through which users interact. It includes:

 User Interface Design: Designed using HTML, CSS, and JavaScript.

 Pages/Modules:

o Home Page

o Donor Registration Page

o Login Pages (Admin/User)

o Blood Search Page

o Request Blood Page

o Admin Dashboard

o Contact Us / About Us

This layer captures input from the users and presents the output data fetched from the
backend.

Blood bank donor management system Page |5

2. Business Logic Layer (Middle Layer)

This layer contains the core functionality of the system — processing user requests, applying
business rules, and interacting with the database.

 Technology Used: PHP

 Modules:

o Authentication Module (Login/Logout)

o Donor Management (Add, Update, View, Delete)

o Blood Request Management

o Search Module (Search by blood group, location)

o Notifications and Alerts (for admins and donors)

o Admin Controls (manage users, donors, and requests)

This layer acts as a bridge between the front-end and the database.

3. Data Layer (Back-end)

This layer deals with data storage and retrieval operations.

 Technology Used: MySQL

 Key Tables in Database:

o users: stores user login credentials

o donors: stores donor details

o blood_requests: stores blood request records

o blood_inventory: maintains available blood stock

o admins: stores administrator login data

o notifications: stores system messages or alerts

This layer handles all CRUD operations (Create, Read, Update, Delete) on the database.

4. Role-Based Structure

The system is divided based on user roles:

a. Admin Role

 Can manage donors and requests

 Approve/reject blood requests

Blood bank donor management system Page |6

  View blood inventory

 Add or remove blood stock

 Generate reports

b. Donor/User Role

 Can register as donor

 Update profile

 View blood request notifications

 Search for blood requests near them

SOFTWARE DEVELOPMENT LIFE CYCLE

1.Requirement Gathering and Analysis

 Objective: Understand and document what the system needs to do.

 Activities:

o Collected requirements from blood banks, hospital staff, and potential

donors.

o Identified system users: Admins, Donors, and Public users.

o Defined major functions like registration, blood search, request handling,

inventory management.

 Deliverables: Requirement Specification Document (SRS)

2. System Design

 Objective: Define system architecture, database schema, and user interface flow.

 Activities:

o Created ER Diagrams and Data Flow Diagrams (DFD)

o Designed the database schema in MySQL

o UI wireframes for major modules (login, registration, dashboard, etc.)

 Deliverables:

o Design Documents (ERD, DFD)

o Database Design

Blood bank donor management system Page |7

 o UI Prototypes

3. Implementation (Coding)

 Objective: Develop the actual system as per design.

 Activities:

o Developed front-end using HTML, CSS, and JavaScript

o Back-end logic implemented in PHP

o Database built using MySQL

o Modules created: login system, donor registration, blood request system,

admin panel

 Tools Used:

o VS Code (IDE), XAMPP (Local server), PHP, MySQL

 Deliverables:

o Source Code

o Functional Modules

4. Testing
 Objective: Ensure the system works as intended and is free of bugs.

 Activities:

o Performed Unit Testing on individual modules

o Integration Testing to ensure modules work together

o User Acceptance Testing (UAT) with sample data

o Bugs and issues were logged and resolved

 Types of Testing:

o Functional Testing

o Validation Testing (e.g., form fields, logins)

o Performance Testing (response time, data retrieval)

 Deliverables:

o Test Plan and Test Cases

o Bug Reports
Blood bank donor management system Page |8
5. Deployment
 Objective: Make the system available for actual use.

 Activities:

o Installed system on a live or local server using XAMPP

o Uploaded all files to the appropriate directories

o Set up database via phpMyAdmin

o Configured system settings and credentials

 Deliverables:

o Live/Local Running Application

o Deployment Document

6. Maintenance
 Objective: Keep the system running efficiently after deployment.

 Activities:

o Regular updates to improve features or security

o Fixing bugs reported by users

o Adding new modules (e.g., SMS notifications or donor eligibility checks)

 Deliverables:

o Maintenance Logs

o Updated Codebase

PROBLEM ANALYSIS
Problems in the Existing System:

1. Lack of Centralized Donor Data

o Donor records are often stored in paper files or spreadsheets.

o No easy way to retrieve or search for donors based on blood group or

location.

2. Delayed Response to Urgent Blood Requests

o In emergencies, there’s no quick way to identify and contact available donors.

Blood bank donor management system Page |9
 o Hospitals spend valuable time calling or searching through records manually.

3. Poor Inventory Management

o Manual tracking of available blood units leads to inaccurate stock data.

o Chances of expiry or misuse of blood units are high due to lack of tracking.

4. No Role-Based Access Control

o Anyone handling records can view or modify sensitive donor information.

o Lack of login/authentication leads to poor data privacy and security.

5. Limited Accessibility

o Manual systems require physical presence or phone calls to access data.

o No online access for users or admins to manage or request blood.

6. High Risk of Errors

o Manual data entry increases the chances of spelling, calculation, and

duplication errors.

o Errors can result in wrong blood group supply or miscommunication.

PROJECT PLAN
A. Project Objectives

 To develop a web-based system for managing blood donors and inventory.

 To ensure quick response to blood requests.

 To provide a secure and user-friendly interface for both donors and administrators.

 To reduce manual errors and paperwork through automation.

B. Project Scope

 Donor registration and login module

 Admin dashboard for blood request management

 Real-time blood inventory tracking

 Blood request submission and approval

 Search and filter by blood group and location

 Notification and alert system

Team Roles and Responsibilities

Blood bank donor management system P a g e | 10
 Role Responsibilities
Project Manager Supervise planning, track progress, and coordinate tasks
Developer Code front-end and back-end, integrate modules
Database Admin Design and manage the database schema in MySQL
Tester Perform testing and report bugs
Document Writer Prepare project report, user guide, and SDLC documentation

Resources Required

 Software Tools:

o VS Code (IDE)

o XAMPP Server (PHP + MySQL)

o Web browser (Chrome/Firefox)

 Languages & Technologies:

o HTML, CSS, JavaScript (Frontend)

o PHP (Backend)

o MySQL (Database)

 Hardware:

o Laptop/PC with at least 4GB RAM

o Internet connection (for testing and deployment)

 Risk Management

Potential Risk Mitigation Strategy

Delay in development Set buffer time in timeline
Data loss Regular backup of code and database
Bugs during integration Conduct thorough module testing before integration
Internet/server unavailability Use local XAMPP server as fallback

AVTIVITIES DURING SOFTWARE PROJECT PLANNING

Blood bank donor management system P a g e | 11
 SIZE

COST DEVELOPMENT

ESTIMATION TIME

RESOURCES

REQUIREMENT

PROJECT

SCHEDULING

SIZE ESTIMATION

The estimation of size is very critical and difficult area of the project planning. It has been
recognized as a crucial step from the very beginning. The difficulties in establishing units for
measuring size lie in the fact that the software is essentially abstract; it is difficult to identify
the size of the system. Many attempts have been made at establishing a unit for measure
size.
They are given as-:

• Lines Of Code

Blood bank donor management system P a g e | 12

 A line of code is any line of program that is not a comment or blank line,
regardless of the number of statements or fragments of statements on the line. This
specifically includes all lines containing program header, declarations and executable
and non executable statements.

• Function Count

It measures functionally from user point of view that is on the basis of what the user
requests and receives in return. Therefore it deals with the functionality being
delivered, and not with lines of code, source modules etc. Measuring size in this way
has the advantage that size measure is independent of the technology used to
deliver the functions.

COST ESTIMATION

For any software project, it is necessary to know how much it will cost to develop and how
ainitiated. In many cases estimates are made using past experience as the only guide. A
number of techniques have been developed and are having following attributes in common:

• Project scope must be established in advance.

• Software metrics are used as a basis from which estimates are made.

• The project is broken into small pieces which are estimated individually.

HARDWARE & SOFTWARE REQUIRMENTS

1. Hardware Requirements

Component Minimum Requirement

Processor Intel Core i3 or equivalent

RAM 4 GB (8 GB recommended for better performance)

Blood bank donor management system P a g e | 13

Component Minimum Requirement

Hard Disk Minimum 10 GB free space

Monitor 15” Color Monitor or higher

Keyboard & Mouse Standard input devices

Internet Connection Required for external deployments (optional)

System Type 32-bit or 64-bit OS supported

2. Software Requirements

Software Details

Operating System Windows 10 / 11, Linux, or macOS

Web Server XAMPP (includes Apache, MySQL, PHP)

Programming Language PHP (server-side), HTML/CSS, JavaScript (client-side)

Database MySQL (included with XAMPP)

Code Editor/IDE Visual Studio Code or any preferred code editor

Browser Google Chrome / Mozilla Firefox

PDF Reader (for reports) Adobe Acrobat Reader or equivalent

Additional Tools (Optional) phpMyAdmin (DB GUI), Git (for version control)

FRONT END DETAILS

Front End tool is used for give a Graphical user interface to system. By this we can
make a system user friendly and more capable. I have chosen PHP as front end tool.
Because it is an Open Source Technology, freely available and more familiar with any type
of database.

ABOUT PHP:

Blood bank donor management system P a g e | 14

 PHP: Hypertext Preprocessor is a widely used, general-purpose scripting language
that was originally designed for web development to produce dynamic web pages. For this
purpose, PHP code is embedded into the HTML source document and interpreted by a web
server with a PHP processor module, which generates the web page document. As a
general-purpose programming language, PHP code is processed by an interpreter
application in command-line mode performing desired operating system operations and
producing program output on its standard output channel. It may also function as a
graphical application. PHP is available as a processor for most modern web servers and as
standalone interpreter on most operating systems and computing platforms.

PHP stores whole numbers in a platform-dependent range. This range is typically

that of 32-bit signed integers. Unsigned integers are converted to signed values in certain
situations; this behavior is different from other programming languages. Integer variables
can be assigned using decimal (positive and negative), octal, and hexadecimal notations.
Point numbers are also stored in a platform-specific range. They can be specified using
floating point notation, or two forms of scientific notation. PHP has a native Boolean type
that is similar to the native Boolean types in Java and C++. Using the Boolean type
conversion rules, non-zero values are interpreted as true and zero as false, as in Perl and C+
+. The null data type represents a variable that has no value. The only value in the null data
type is NULL. Variables of the "resource" type represent references to resources from
external sources. These are typically created by functions from a particular extension, and
can only be processed by functions from the same extension; examples include file, image,
and database resources. Arrays can contain elements of any type that PHP can handle,
including resources, objects, and even other arrays. Order is preserved in lists of values and
in hashes with both keys and values, and the two can be intermingled. PHP also supports
strings, which can be used with single quotes, double quotes, or heredoc syntax.

Why PHP?

PHP is one of the most popular server side scripting languages running today. It is used for
creating dynamic WebPages that interact with the user offering customized information. PHP
offers many advantages; it is fast, stable, secure, easy to use and open source (free).

• User friendly
• GUI
Blood bank donor management system P a g e | 15
 • Separation of work (designing & coding)
• Written once run anywhere
• PHP API

BACK END DETAILS

Back end part of a system is more important because it controls all the internal process of
a system. I have choose oracle database as back end. Because it is word’s Most Capable
relational database and provide more security than others.

Why MySQL?

MySQL is the world's most popular open source database software, with over 100 million
copies of its software downloaded or distributed throughout its history. With its superior
speed, reliability, and ease of use, MySQL has become the preferred choice for Web, Web
2.0, SaaS, ISV, Telecom companies and forward-thinking corporate IT Managers because it
eliminates the major problems associated with downtime, maintenance and
administration for modern, online applications.

Many of the world's largest and fastest-growing organizations use MySQL to save time and
money powering their high-volume Web sites, critical business systems, and packaged
Blood bank donor management system P a g e | 16
 software — including industry leaders such as Yahoo!, Alcatel-Lucent, Google, Nokia,
YouTube, Wikipedia, and Booking.com.

The flagship MySQL offering is MySQL Enterprise, a comprehensive set of

productiontested software, proactive monitoring tools, and premium support services
available in an affordable annual subscription.

MySQL is a key part of WAMP (Window, Apache, MySQL, PHP), the fast-growing open source
enterprise software stack. More and more companies are using WAMP as an alternative to
expensive proprietary software stacks because of its lower cost and freedom from platform lock-in.

REQUIREMENT ANALYSIS STEPS

Draw context

Diagram

Draw
Prototypes

Model The
Requirement

Finalize The
Requirement

Draw Context Diagrams – The context diagram is a simple model that defines the
boundaries and interfaces of the proposed system with the external world. It identifies the
entities outside the proposed system that interact with the system

Development Of Prototype – One effective way to find out what the customer
really wants is to construct a prototype, something that looks and preferably acts like a
part of the system they want.
Blood bank donor management system P a g e | 17
 Model The Requirement – This process really consist of various graphical
representations of functions, data entities, external entities and the relationship between
them. The graphical view may help to find incorrect, inconsistent, missing and superfluous
requirement.

Finalize The Requirements – After modeling the requirements we will have better
understanding of the system behavior. The inconsistencies and ambiguities have been
identified and corrected.

FUNCTIONAL REQUIREMENTS
Functional requirements define the fundamental actions that must take place in the
software in accepting the inputs and in processing and generating the outputs. These are
listed as “shall” statements starting with “The system shall….

Login Module – This module is provided for administrator and users such as Product
buyer and seller who have registered themselves in the system. These login are provided
according to the need of the systems.

▪ Input – User id and password

▪ Process – After entering user id and password by user process of

validation occur to identify whether user id and password is
available in database or not.

▪ Output – Registered user can access website and can use the
services.

Administrator Module – The administrator is provided with password and login-

id with which he/she can access the system. Administrator is provided right of maintaining
the database, verifies registered users.

▪ Input – Login id and password.

▪ Process – Process of validation will occur.

▪ Output – Administrator will maintain the database and will

perform

Blood bank donor management system P a g e | 18

 Product seller process.

Search Module – In this module we are going to provide facility for Product buyer to
search for Products according to their specified categories so that users can search for
Products easily.

▪ Input- Initial letter of Product, with the help of keywords and

with the help of Brand name.

▪ Output- Information about Products.

▪
User Module – As users are the main visitor of site, the following facilities are

available through this module.

Can search the Products according to their need

Can order online books and pay via credit or atm card or PayPal.

Can get information about Products.

▪ Input – User Id and password

▪ Process – Process of validation will occur.

▪ Output – Only genuine user can access services provided by

website.

NON FUNCTIONAL REQUIREMENT

Performance Requirement
The performance of the product mainly depends on the speed of Internet connection. If
the user wants hard real time response, then this is definitely not the product to go for.

Safety Requirements
The electrical connection to the devices is critical and should be done according to the
standards to avoid any short circuits.

Blood bank donor management system P a g e | 19

 Security Requirements
We aim to provide high security features like encryption to the user accounts to provide
security from illegal hacking and gaining access to the system.

SYSTEM DESIGN
The most creative and challenging phase of System Development Life Cycle (SDLC) is
Software Design. SDS is systematic documentation of design. A design process involves
“conceiving and planning out in the mind” and “making drawing pattern or sketch”. The
term “design” describes a final system and the process by which it is developed. It assist in
catching potential errors before the implementation phase itself which had been very
costly to remove otherwise.

System Design is a solution how to translate the system requirement into a blue print for
constructing the software. The goal of SDS is not only to produce a correct design but the
best possible one within the limitation imposed by the requirements and the physical and
social environment in which the system will operate.

The system architecture description found in this document provides the reader a clear

sense of how the system will be organized, how the components will interact and how the
users will interface with the running software.

DESIGN NOTATIONS

1. Data Flow Diagram (DFD) Notations

DFDs help represent the flow of data through the system. The symbols used in DFDs include:

Symbol Name Purpose

🔵 Process Represents a function or action performed in the system

Blood bank donor management system P a g e | 20
Symbol Name Purpose

🟩 Data Store Represents data stored for later use

External Represents people, systems, or organizations interacting with the

🟦
Entity system

➡️ Data Flow Represents the movement of data between components

Example:

 Donor → [Register Process] → Donor Data Store

✅ 2. Entity-Relationship Diagram (ERD) Notations

ERDs are used to model the database structure.

Symbol Name Purpose

▭ (Rectangle) Entity Represents a real-world object (e.g., Donor)

◯ (Ellipse) Attribute Represents a property of an entity (e.g., Name, Age)

🔗 (Diamond) Relationship Represents a link between entities

Underlined Text Primary Key Identifies the unique attribute of an entity

Example:

 Donor — (donates) —> Blood_Stock

✅ 3. Flowchart Notations

Flowcharts are used to represent logic or decision-making processes in the system.

Symbol Name Purpose

🔷 (Diamond) Decision Represents a decision point (Yes/No)

🟪 (Rectangle) Process Represents an action or operation

Blood bank donor management system P a g e | 21

Symbol Name Purpose

🟦 (Parallelogram) Input/Output Represents input to or output from the system

🔺 (Arrow) Flowline Shows the direction of the process flow

🟫 (Terminator) Start/End Represents the beginning or end of the process

Example:

 Start → Enter Login → [Check Credentials] → Valid? → Yes → Dashboard

✅ 4. UML Use Case Diagram Notations (Optional)

If you use UML to design system behavior, these notations apply:

Symbol Name Purpose

👤 (Stick Figure) Actor External user/system interacting with the application

🟦 (Oval) Use Case A task or functionality performed (e.g., Register Donor)

➖ (Line) Association Connects actor to use case

⬅️(Arrowed Line) Include/Extend Shows relation between use cases

PRODUCT FUNCTIONS

Product functions describe the core capabilities and features that the system is expected to
perform. These functions align with the user requirements and help achieve the goals of the
blood bank system.

1. Donor Registration

 Allows users (donors) to register by providing personal details like:

o Name, age, gender, contact number, blood group, and email.

 Stores donor data in the database for future reference and eligibility checks.

2. Blood Inventory Management

Blood bank donor management system P a g e | 22

  Admin can:

o View current blood stock.

o Add new blood units after donation.

o Update or delete entries as required.

 The system tracks available units by blood group.

3. Blood Donation Management

 Tracks each donation entry by registered donors.

 Updates inventory upon successful donation.

 Maintains donation history for each donor.

4. Blood Request Processing

 Hospitals or users can request blood by submitting:

o Name, required blood group, number of units.

 Admin receives and reviews the request.

 Status is updated as Approved / Pending / Rejected.

5. Admin Panel

 Secure login for administrators.

 Dashboard includes:

o Donor list management.

o View blood stock levels.

o Process blood requests.

o Generate reports.

Blood bank donor management system P a g e | 23

6. Search Blood Availability

 Public users can search for available blood types.

 Displays matching donors or stock availability based on blood group.

7. Report Generation

 Generates reports for:

o Total blood units available.

o Donor activity and history.

o Request and approval logs.

 Export options in printable or viewable formats.

8. Secure Login System

 Login feature for admin with secure password encryption.

 Prevents unauthorized access to system features.

9. Data Validation and Error Handling

 Validates form inputs (e.g., age must be numeric, email must be valid).

 Displays appropriate error messages for invalid data or missing fields.

10. Notifications (Optional / Future Enhancement)

 Alert admins when blood stock is low.

 Notify donors about next eligible donation date.

USER CHARACTERISTICS
Donors:

Description: Donors are individuals who volunteer to donate blood. They are crucial to the
functioning of the blood bank.

Characteristics:

Blood bank donor management system P a g e | 24

  Technical Skill: Donors typically have basic computer or mobile device skills. They
interact with the system via a web interface or mobile app.

Admin (Blood Bank Staff)

Description: Admin users are staff members who are responsible for managing the
operations of the blood bank. They oversee donor registration, blood inventory, request
processing, and the overall management of the system.

Characteristics:

 Technical Skill: Admins possess intermediate to advanced technical skills, as they

need to operate a web-based system and may interact with database

Requesters (Patients / Hospitals)

Description: Requesters are people or institutions, such as hospitals or healthcare facilities,

that need blood donations for medical procedures or emergencies.

Characteristics:

 Technical Skill: Requesters usually have basic skills to use web forms or mobile apps
to submit blood requests.

Developers / Maintenance Team

Description: Developers and the maintenance team are responsible for building,
maintaining, and updating the BBDMS system. They ensure the system is running smoothly
and free of bugs.

Characteristics:

 Technical Skill: Developers have advanced knowledge of web development

technologies (such as PHP, MySQL, JavaScript) and are skilled in backend operations,
debugging, and system deployment.

DETAIL DESIGN

Blood bank donor management system P a g e | 25

Donor Registration and Management

 Input: Name, Age, Gender, Blood Group, Contact Details (phone number, email).

 Process: When a donor registers, the system verifies the entered data (e.g., ensuring
age is within the acceptable range and blood group is valid). Donor details are saved
in the database.

 Output: Confirmation message (e.g., "Registration Successful") or error message

(e.g., "Please enter a valid email").

 User Interface: A simple form that the donor can fill out. The form is accessible via
the homepage.

 Database: Data is stored in the donor table.

2.2 Blood Donation Management

 Input: Donor ID, Blood Group, Quantity of Blood Donated, Donation Date.

 Process: When a donor donates blood, the system records the donation in the
database. It also updates the blood stock levels based on the blood group and
quantity.

 Output: Donation status (e.g., "Donation Successful") and updated blood stock.

 User Interface: Admin dashboard for adding new donations; donors can view their
past donations.

 Database: Donor donations are recorded in the blood_donations table, and stock is
updated in the blood_stock table.

2.3 Blood Request Handling

 Input: Requester name, blood group, required quantity, location (hospital or

requester details).

Blood bank donor management system P a g e | 26

  Process: A requester (hospital or patient) submits a blood request. The system
checks the available blood stock and either approves or rejects the request based on
the stock.

 Output: Request status (e.g., "Approved", "Pending", "Rejected").

 User Interface: A form for requesters to fill out, showing the available blood types
and quantities.

 Database: Blood request details are stored in the requests table.

2.4 Admin Panel

 Input: Admin username, password (for login). Admins can also update blood stock,
approve or reject requests, and generate reports.

 Process: Admins can access a dashboard to view and manage donor data, blood
inventory, and blood requests. The admin also has the ability to generate reports on
blood donation trends and request history.

 Output: Admin dashboard showing statistics, donor details, request status, and
inventory levels.

 User Interface: A secure login page, followed by a dashboard that includes links to
different management sections (donors, blood stock, requests).

 Database: Admin data is stored in the admin table, and actions (add/update/delete)
on the donor or request tables are tracked.

ENTITY RELATIONSHIP DIAGRAM

Entity relationship diagrams are a way to represent the structure and layout of a database.
It is used frequently to describe the database schema. ER diagrams are very useful as they
provide a good conceptual view of any database, regardless of the underlying hardware
and software. An ERD is a model that identifies the concepts or entities that exist in a
system and the relationships between those entities. An ERD is often used as a way to
visualize a relational database: each entity represents a database table, and the

Blood bank donor management system P a g e | 27

 relationship lines represent the keys in one table that point to specific records in related
tables.

ERDs may also be more abstract, not necessarily capturing every table needed within a
database, but serving to diagram the major concepts and relationships. This ERD is of the
latter type, intended to present an abstract, theoretical view of the major entities and
relationships needed for management of electronic resources. It may assist the database
design process for an e-resource management system, but does not identify every table
that would be necessary for an electronic resource management database.

Objects

There are three main objects on an ER Diagram:

1. Entities
2. Relations
3. Attributes.

Entities
An entity is a concept or object in the database. Entities are concepts within the data
model. Each entity is represented by a box within the ERD. Entities are abstract concepts,
each representing one or more instances of the concept in question. An entity might be
considered a container that holds all of the instances of a particular thing in a system.
Entities are equivalent to database tables in a relational database, with each row of the
table representing an instance of that entity.

Attributes

The Supplier Name, Supplier Address, Telephone Number etc. A given attribute belonging
to a given entity occurrence can only have one value. Therefore, if a supplier could have
more than one address or telephone number then this should be determined before
defining the attributes of that entity type. In this example the defined entity may require
two or three address and/or telephone number attributes. It is the maximum practical
instances of a given attribute that should be catered for in the entity type definition.

Blood bank donor management system P a g e | 28

 Relationships

Relations are the connections between two or more entities. Relationship lines indicate
that each instance of an entity may have a relationship with instances of the connected
entity, and vice versa. Each entity type can always be described in terms of attributes, and
these attributes will apply to all occurrences of that given entity type

Blood bank donor management system P a g e | 29

Blood bank donor management system P a g e | 30
TESTING

Testing is the process of executing a program with the intent of finding errors. Although software
testing is itself an expensive activity, yet launching of software without may lead to cost potentially
much higher than that of testing, especially in systems where human safety is involved. Effective
software testing will contribute to the delivery of higher quality software products, more satisfied
users, and lower maintenance costs, more accurate and reliable results. Software testing is
necessary and important activity of software development process.

STRUCTURAL TESTING
Structural Testing takes into account the internal mechanism of a system or component.
Fatigue Testing is carried out with the objective of determining the relationship between the
stress range and the number of times it can be applied before causing failure. So when your
product’s structural durability needs to be predicted, verified and validated, turn to DTB's
Structural Testing and Fatigue Testing experts. We provide you with the necessary structural
testing and fatigue testing equipment and personnel to test the design and manufacturing
integrity of your product. Call upon our vast experience in commercial and military
applications.

Software Structural Testing is a 2-day course designed to provide an excellent knowledge

base and practical skills for anyone interested in improving Software Structural Testing
techniques and practices in their organization. This course starts with an overview of
software testing basics, including discussions of the importance of software testing, the
different levels of testing and basic testing principles. Basic testing terminology is defined.
Techniques for ensure test coverage of requirements, different types of testing

documentation and various test activities are discussed.

Course attendees will learn how to utilize various techniques for performing systematic
structural testing, including decision/condition coverage, loop testing and basis path testing.
Strategies for performing software and system integration testing are also covered.

Blood bank donor management system P a g e | 31

 FUNCTIONAL TESTING

It is very useful and convenient in support of functional testing. Although JMeter is known
more as a performance testing tool, functional testing elements can be integrated within the
Test Plan, which was originally designed to support load testing. Many other load-testing
tools provide little or none of this feature, restricting themselves to performance-testing
purposes. Besides integrating functional-testing elements along with load-testing elements
in the Test Plan, you can also create a Test Plan that runs these exclusively. In other words,
aside from creating a Load Test Plan, it also allows you to create a Functional Test Plan. This
flexibility is certainly resource-efficient for the testing project.

This will give a walkthrough on how to create a Test Plan as we incorporate and/or configure
its elements to support functional testing. This created a Test Plan for a specific target web
server. We will begin the chapter with a quick overview to prepare you with a few
expectations; we will create a new Test Plan, only smaller. The Test Plan we will create and
run at the end of this chapter will incorporate elements that support functional testing,
exclusively.

Blood bank donor management system P a g e | 32

METHODOLOGY USED FOR TESTING

ACCEPTANCE TEST GENERATION

The objective of this step is to produce a set of test data that may be used to test the
system. Whenever a new system is developed it need to be tested to confirm its validity
and to determine whether it meets the user requirements. The system was also tested
with some sample records. The records were entered into the system and various reports
were generated to check the system.

System testing is a critical phase of implementation. Testing of the system involves

hardware devices and debugging of computer programs and testing information processing
procedures. Testing can be done with test data, which attempt to simulate all possible
condition that may rise during processing. The testing methods adopted during the testing
of system are unit testing and integration testing.

UNIT TESTING
Unit testing focuses on the modules independently locate the errors. This enables the
tester to detect errors in coding. It is the process of taking a module and running it in
isolation from rest of the software product by using prepared test cases and comparing the
actual result with the result redirected with the specifications and design of the module.
One purpose of testing is to find and remove as many errors in the software as practical.
There are number of reason in support of unit testing-:

• The size of module single module is small that we can locate an error fairly easily.
• The module is small enough that we can attempt to test it in some demonstrably
exhaustive fashion.
• Confusing interactions of multiple errors in widely different parts of software are
eliminated.
There are problem associated with testing a module in isolation. How do we run a module
without anything to call it, to be called by it, possibly to output intermediate values
obtained during execution? One approach is to construct an appropriate driver routine to
call it, and simply stubs to be called by it, and to insert output statements in it. Stubs serve
to replace modules that are subordinate to the module to be tested. A stub or dummy

Blood bank donor management system P a g e | 33

 subprogram uses the subordinate module’s interface, may do minimal data manipulation,
prints verification of entry and returns.

INTEGRATION TESTING
This is a systematic technique for constructing the program structure while at the same
time to uncover the errors associated with the interface. The objective is to take unit
tested module and build a program structure that has been detected by designing. The
main purpose of integration testing is to determine that the interfaces between modules
are correct or not. One specific target of integration testing is the interface: whether
parameter matches on both sides as to type, permissible ranges, meaning & utilization.
There are 3 types of integration testing-

• Top Down Approach- Top Down integration proceeds down the invocation
hierarchy, adding one module at a time until an entire tree level is generated.
• Bottom Up Approach – The Bottom up strategy works similarly from the bottom
to up.
• Sandwich Strategy – A sandwich strategy runs from top and bottom
simultaneously.

TEST DATA USED

The proper selection of the data is very important. If the test data is not appropriate or

representative of the data to be provided by the user, the reliability of the output is

susceptible. Two different sources were during testing of the system-:

• Using Live Test Data – Live test are those that are actually extracted from the
organization files. Use of the live data make testing easier by obtaining most
expected outputs and if it is found that the program can handle the entries
processing of the system accurately.
• Using Artificial Test Data - Live data is difficult to obtain insufficient amount to
conduct extensive testing. It does not test all the combination or formats that can
be done by entering to the system. Therefore artificial test data were used at the
time of unit testing. Artificial test data was created solely for test purposes which
provide extreme values for testing the limit of candidate system.

Blood bank donor management system P a g e | 34

 TEST CASES
• System is properly linked or not - Whether they are redirected to desired page or
not.
• Information passed – If a page passes some parameter to another page then it
should be checked that the page get the correct information, whatever is passed
by the previous page.
• Output should be correct – Every functionality of the system should be checked
properly whether it gives the right result or not generally test is performed with
known results. If the output of the system is matched with that result the system is
working fine.

IMPLEMENTATION
The implementation phase is the most crucial stage in the Software Development Life Cycle
(SDLC). In this phase, the actual development and deployment of the software system take
place. It involves converting the design and plan into executable code, testing it, and making
it operational for end-users.

Purpose of Implementation

The main objective of the implementation phase is to:

 Translate the design into a working system.

 Integrate various modules and components.

 Deploy the system in a real-time environment.

 Ensure that the software performs according to the user requirements.

Blood bank donor management system P a g e | 35

1. Environment Setup

Before beginning development, the required software and hardware environments are set up.
For BBDMS, the tools and platforms used include:

 XAMPP (Apache, MySQL, PHP, and phpMyAdmin)

 VS Code (Code Editor)

 MySQL (Database)

This setup allows local development and testing before final deployment.

2. Database Implementation

A structured relational database is created using MySQL to store and manage data such as:

 Donor information

 Blood group and quantity

 Blood requests

 Admin login details

Tables are designed using SQL, with appropriate primary and foreign keys to ensure
referential integrity.

3. Coding the Modules

The system is divided into functional modules such as:

 Donor Registration

 Blood Donation Management

Blood bank donor management system P a g e | 36

  Blood Stock Management

 Blood Request Handling

 Admin Panel

Each module is implemented using PHP for the server-side scripting and HTML/CSS for the
user interface.

4. Interface Development

The user interface (UI) is designed to be simple, user-friendly, and responsive. It allows
different users (donors, admin, hospitals) to interact with the system easily through forms and
dashboards.

5. Integration and Linking

All modules are integrated to ensure data flows correctly between components. For example:

 When a donor donates blood, the donation details update the blood stock table.

 When a blood request is made, it checks the blood stock and updates the request status
accordingly.

6. Testing and Debugging

After coding and integration, the system undergoes several levels of testing:

 Unit Testing: Each module is tested independently.

 Integration Testing: Modules are tested together to check data consistency and flow.

 System Testing: The whole system is tested for real-life use cases.

Errors and bugs are identified and resolved to ensure the system's smooth functioning.

Blood bank donor management system P a g e | 37

7. Deployment

After successful testing, the system is deployed either locally or on a web server for actual
use. The database is exported, and all files are uploaded to the live environment.

8. User Training and Documentation

Basic training is provided to system users (admin or staff) on how to use the application. User
manuals and technical documentation are prepared to assist users in operating the system.

Benefits of Proper Implementation

 Ensures that the system functions as expected.

 Enhances reliability and user satisfaction.

 Makes it easier to detect and fix bugs at an early stage.

USER MANUAL

DEFINITION, ACRONYMS, ABBREVIATIONS

• Browser: A software application used to locate and display web pages.

• Database: A database that stores data. It is a collection of interrelated data that

contains information relevant to enterprise.

• MYSQL: Most widely used query language for creating database.

• Internet: Worldwide networks of computers from where anyone can take

information.

• Homepage: The first page when you go to a worldwide website on internet.

Blood bank donor management system P a g e | 38

 • HTML: It is a computer language specifying the content & formats of web
document .It allows additional text to include codes that define fonts, layouts,
graphics & hypertext.

• PHP: It is called Hypertext Pre-Processor.

• Webpage: pages of information placed on network that may contain text, graphics,
images, moving pictures, sound files & other type of electronic information.

• Website: Collection of files called webpage, which can contain text & images.

• DBMS: A collection of computer program that allow storage, modification,

extraction of information from database.

• SQL: It is a standard interactive & programming language for getting information &
updating database..

ABBREVIATIONS/ ACRONYMS

• SQL: Structured Query Language

• SRS: System Requirement Specification

• OS: Operating System

• DBMS: Database Management System

• URL: Uniform Resource Locator

• IIS: Internet Information Server

• XML: Extensible Markup Language

• PHP: Hypertext Pre-Processor

Blood bank donor management system P a g e | 39

 SCREEN SHORTS
OF PROJECT

DATABASE AND
TABLES OF
PROJECT

Blood bank donor management system P a g e | 40