_____________________________________

Software Design Document

For
Blood Bank Management System
Prepared by:
Fatima Batool
Hamna Shafique
Sobia Sajid
Tooba Kanwal
Sadia Ahmed

_____________________________________
 1. Introduction
1.1 Purpose
The purpose of this study was to develop a blood bank management information system to
assist in the management of blood donor records and ease/or control the distribution of blood
in various parts of the country/city. Without quick and timely access to donor records, creating
market strategies for blood donation, lobbying and sensitization of blood donors becomes very
difficult.

1.2 Scope
The blood management information system offers functionalities to quick access to donor
records collected from various parts of the country. It enables monitoring of the results and
performance of the blood donation activity such that relevant and measurable objectives of the
organization can be checked.
This is not a blood bank, this system stores only the data of the donors. It stores data by donors
name, distance from the city, contact number, blood group etc. So when blood needed the
system search for the perfect donor. This System reduces complexity for find a donor from a
huge database.
1.3 Intended Audience
This document is intended for the following group of people:
 Developers for the purpose of maintenance and new releases of the software.
 Management of the blood bank.
 Documentation writers.
 Testers.
1.4 References
 www.google.co.in
 robotics.ee.uwa.edu
 https://www.researchgate.net
 Chevy Chase Bank, UMBC Branch
Online
http://robotics.ee.uwa.edu.au/courses/design/examples/example_design.pdf
1.5 Summary
The purpose of this study was to develop a blood management information system to assist
in the management of blood donor records and ease/or control the distribution of blood in
various parts of the country basing on the hospital demands. Without quick and timely
access to donor records, creating market strategies for blood donation, lobbying and
sensitization of blood donors becomes very difficult. It enables monitoring of the results
and performance of the blood donation activity such that relevant and measurable
objectives of the organization can be checked. It provides to management timely,
confidential and secure medical reports that facilitates planning and decision making and
hence improved medical service delivery. The reports generated by the system give
answers to most of the challenges management faces as far as blood donor records are
concerned.
2. System Overview
2.1 Product Perspective
The main objective of the study was to create electronic blood donor management
information system in order to assist in the management of blood donor records, planning
and share information in a more confidential, convenient and secure way using modern
database and information. The Organization will be more dynamic to their activities of
store and contacting with the users and donors.
3. Design Considerations

3.1 Product Functions

 Interface
 User Interface
 Admin Panel
 Communication Interface
 Functional requirements
 Login of admin.

3.2 Assumptions and Dependencies

 Hardware never fail
 Highly Trained Dataset
  System Security
 Alert System
3.3 Goals and Guidelines
 User friendly interface.
 User can easily find and choose a donor accordingly by the blood group.
 Find with location or address.
 Donors details Information
3.4 DESIGN VIEW POINTS
Design Viewpoints with respect to stake holders are given below:

3.4.1 Context View Point

Context View Points show the functionality provides by the design. The actors of the system such
as users and other stakeholders are used as reference to describe the context and these actors
interact with the design objects. Black box view of the design is demonstrated by this view point.
Services are related with actors which are using information flows.
3.4.1.1 Design Concerns
The one major service category to which our system is concerned is user. Users are those who will
use the system. The main objective of context view point is to describe scope of use and
functionality of design subjects. It also categorizes actors and services of system and also draws
system boundaries. So major design concern is to identify all services of system and flow of data
between design subject and its environment.
3.4.1.2 Design Elements
External Entities: End Users (donor), Developers, Admin, Verification System, Patient, Blood
Bank.
Services: Signup, Login, View information, Update information, delete information, Search
blood, Donate blood, Receive blood, Store blood, Transact blood.

3.4.1.3 Use case Diagram

Use case diagram represent the connection between different actors and elements of the System.
It describes and simplifies the requirements of the system. All the actors within the system have
different designated roles.
Admin

Figure 1 Use Case Diagram Admin

Blood Bank

Figure 2 Use Case Diagram Blood Bank

Donor

Figure 3 Use Case Diagram Donor

 Patient

Figure 4 Use Case Diagram Patient

Actors:
Primary Actors: Donor, Patient
Secondary Actors: Admin, Blood Bank.
Use Cases:
 Register
 Manage Blood Bank
 Manage Donor
 Manage Patient request
 Add new Blood Bank
 Manage stock
 Donate Blood
 Request Blood
3.4.2 Interaction Viewpoint
This view point describes the collaboration procedure between the system objects, it describes the
level and how activities arise at a particular level.
3.4.2.1 Design Concerns
Evaluate the responsibilities to be allocated in the collaboration procedure. Detect the connections
to be made for the necessary activities in the form of messages between the existing entities of the
system. It identifies the logic for different state transitions, communication within the system.
3.4.2.2 Design Elements
 Objects: User, System, Database.

3.4.2.3 System Sequence Diagram

System Sequence diagram is used to show the interaction between the entities of the system
under particular circumstances and at a particular time.

Figure 5 Admin Sequence Diagram

Figure 6 Blood Bank Sequence Diagram

Figure 7 Donor Sequence Diagram

 Figure 8 Patient Sequence Diagram

3.4.3 Structure Viewpoint

The structure viewpoint is used to document the internal division and organization of the design
subject in terms of like element (recursively).

3.4.3.1 Design Concerns

Compositional structure of coarse-grained components and reuse of fine-grained components.

3.4.3.2 Design Elements

Design entities:

User, Admin, Blood Bank, State, City, Location, Donor Request, Patient request.

Design attributes:

 User: CNIC, Fist Name, Last Name, Gender, Contact, Date of Birth, Email, Password
 Admin: ID, Email, Password
 Blood Bank: ID, Name
 City: ID, Name, State ID, State Name.
 Location: ID, Name, City ID.
 Donor Request: Donor ID, Blood ID, Donor Name, Location ID.
 Patient Request: ID, Blood ID, Location ID.
Design constraint:

 User: Login, Sign Up, Make Request, View Service, Feedback.

 Admin: Login, Manage Donor, Manage Patient, Manage Blood Bank.
 Blood Bank: Login, Manage Request, Manage Donor.
 New Donor Request: Check Donor, Add new donor.
 Patient request Location: Check service, Request service.
 State: Provide state, Provide state wise city, provide city wise location.

Figure 9 Blood Bank Management System Class Diagram

3.4.4 Logical Viewpoint

The goal of the logical viewpoint is to intricate prevailing and intended types and the static
association with classes and interfaces of their application.

3.4.3.3 Design Concerns

Design Concerns includes static structure represented by classes, interfaces, and their
relationships, reuse of types and its implementations (classes, data types).

3.4.3.4 Design Elements

Design entities:

Donor, Hospital, Patient, Admin, Database, Donate Blood, Request Blood.

Design attributes:

 Donor: ID, Name, Location

 Hospital: ID, Name, Address
 Admin: ID, Name
 Donate Blood: ID, Type.
 Request Blood: Blood Type.
 Database: DB Name.

Objects:

 Donor
 Patient
 Hospital
 Admin
 Database
 Donate blood
 Request blood

3.4.3.5 UML Object Diagram

An object diagram shows a whole or factional view of the structure of a modeled system at a
particular period of time. Object diagrams are a derivative of class diagrams therefore are
dependent on them. Object diagrams basically demonstrate an instance of a class diagram. The
object diagram also depicts the static view of system but this view is a snapshot of the system at a
specific instant.
Figure 10 Blood Bank Management System Object Diagram
State Transition Diagram:

Figure 11 State Transition Diagram of Blood Bank Management System

Activity Diagram:

Figure 12 Activity Diagram for Admin

Figure 13 Activity Diagram for Blood bank

Figure 14 Activity Diagram For Donor