0% found this document useful (0 votes)
55 views21 pages

Blood Bank Management System SRS

The document outlines a practical lab file for a Bachelor of Computer Application course focused on developing a Blood Bank Management System. It includes problem statements, software requirements specifications, user interface designs, and various diagrams such as Data Flow Diagrams and Use-case Diagrams. The system aims to streamline blood donation and inventory management processes, enhancing efficiency and transparency in blood bank operations.

Uploaded by

chanchal92681
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
55 views21 pages

Blood Bank Management System SRS

The document outlines a practical lab file for a Bachelor of Computer Application course focused on developing a Blood Bank Management System. It includes problem statements, software requirements specifications, user interface designs, and various diagrams such as Data Flow Diagrams and Use-case Diagrams. The system aims to streamline blood donation and inventory management processes, enhancing efficiency and transparency in blood bank operations.

Uploaded by

chanchal92681
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

VIVEKANANDA INSTITUTE OF PROFESSIONAL STUDIES

VIVEKANANDA SCHOOL OF INFORMATION TECHNOLOGY

BACHELOR OF COMPUTER APPLICATION


Practical-IX Software Engineering Lab File
BCA-274

Guru Gobind Singh Indraprastha University


Sector - 16C Dwarka, Delhi – 110078

SUBMITTED TO: SUBMITTED BY:


Ms. Mitanshi Rustagi Priyanshi Gupta
Assistant Professor 04129802021
VSIT BCA 4EA

1
Index

[Link] Programs Page Sign.


No.
1. Select and write down the problem statement for a real time 3
system of relevance.

2. Analyze requirements for a system and develop software 4-9


requirements specification sheet (SRS) for suggested system.

3. To create the function-oriented diagram: Data Flow Diagram 10-12


(DFD)

4. To perform the user’s view analysis for the suggested system: 13


Use-case Diagram

5. To draw the structural view diagram for the system: Class 14


Diagram

6. To draw the behavioral view diagram: State-char Diagram or 15-16


Activity Diagram

7. To draw the behavior view diagram for the suggested system: 17-18
Sequence Diagram

8. Draw the component Diagram. 19

9. Draw the Deployment Diagram. 20

10. Perform Measurement of complexity with Halstead Metrics 21


for chosen system.

2
1) Select and write down the problem statement for a real time system of relevance.

PROBLEM STATEMENT

The process first starts with an offline Blood Donation Camp. The Blood Bank Testing Unit
analyses all donated blood for blood type and potentially infectious agents the day after the
donation. They communicate the Blood Inventory with the test results. Each blood unit that is
analyzed is destroyed if the results show that the blood could be contaminated with a viral
agent.

The exam form makes a note of this. Blood units only last so long before becoming bad. Every
day, a list of the units that have reached the end of their shelf life is sent to the blood bank.
They are eliminated, and the blood units list is revised.

Moreover, the Blood Bank provides blood to different hospitals that need it. Often, requests
for blood types come in. When a hospital places an order, the Blood Bank makes chilled
containers of these units and delivers them to the hospital. The Blood Inventory sends a list of
all hospitals together with the precise blood units that must be supplied to each hospital to the
blood bank.

The Blood Bank Manager signs the order and sends a copy back to the Blood Inventory once
the order has been filled. The blood is delivered to the asking hospital with a duplicate of it.
The final copy is stored in the Blood Bank archives but deleted after one year.

3
2) Analyze requirements for a system and develop software requirements
specification sheet (SRS) for suggested system.

PURPOSE

This project, the Blood Bank Management system, is a great goal of this project is to complete
the project on the management system of blood banks.

The primary goal of the structure is to offer blood donation services to the city in the recent
past. A web-based application called Blood Bank Management System is created to store,
process, retrieve, and analyze data related to administrative and inventory management within
a blood bank.

This project intends to store all the data regarding blood donors, and the various blood types
available in each Blood Bank, and to aid in their management.

The project’s goals are to increase openness in the industry, making it easy and free of
corruption to get blood from a blood bank and improve the efficiency of the blood bank
management system.

SCOPE

The specification expands on the knowledge now available in IT technology for blood
transfusion and guides both Connecting for Health and private companies making hardware
and software.

The specification’s primary goal is to facilitate automated tracking of blood units from the time
they are first collected until they are finally ordered and purchased by hospitals.

OVERVIEW

This Blood Bank Management System helps connect various hospitals to the Blood Bank. The
Hospitals can place orders for a particular blood group and the order is further processed by
the Blood Bank. The Blood sample is dispatched from the Blood Inventory and delivered to
the hospital. This process can be made simpler and easier by using the Online Bank
Management System.

4
PRODUCT PERSPECTIVE

This system is based on online components. Blood is tested in the Blood Testing Units.

Once the blood has been drawn, it is stored in a secure location. Moreover, a digital blood
inventory database is kept for the blood units gathered. A small sample of the blood units is
then delivered from here to the testing unit. Here the blood samples are examined to establish
if they are fit to be utilized or not. The lab technician compiles a report, which is then forwarded
to the Blood Bank.

The Blood Bank Inventory is updated based on the reports received; some blood samples may
need to be removed since they are unfit for usage.

The Blood Bank accepts orders from hospitals. Both sides keep a record of the order and the
payment. The Blood Bank Manager will provide the receipt as soon as the order is placed. Staff
from the Blood Bank deliver the order when the hospital pays.

The Blood Bank staff is fully listed in a database that is kept up to date.

USER INTERFACES

1. A login screen for entering the username, password and role (Hospital, Blood Bank,
Blood Inventory) will be provided. Access to different screen will be based upon the
role of the user.
2. There will be a screen for capturing and displaying information regarding what all blood
groups are available and the quantity of each of the blood groups.
3. There will also be an order window for placing orders of blood groups.
4. A confirmation window to show that the order has been placed and is being processed.
5. An order list window to show all the orders received and for which blood groups the
order has been placed and by whom the order has been placed.
6. A window to update the details of the blood groups and their quantity.
7. There will be a screen for capturing and displaying information regarding which all
user accounts exist in the system, thus showing all can access the system.
8. An order list will be generated.

PRODUCT FUNCTIONS

This product states that before donating blood, donors can register at the blood camp or create
an account at home. The hospital manager must register the hospital since it serves as an
acceptor in this situation. The Inventory Manager frequently updates and maintains the data of
the blood inventory, such as the availability of a specific type of blood. Because it is a
confidential piece of information, only the administrators have access. A hospital that has

5
registered may make an online purchase. The Inventory Manager, who has access to the blood
unit’s database, processes the order. It tells the appropriate hospitals if the necessary blood type
and quantity are available.

Details are provided after the Hospital Management approves the Order.

USER CHARACTERISTICS

This system primarily has three users interacting with one another: a hospital manager, an
inventory manager, and a delivery boy.

The remainder of the blood units is transferred to the blood inventory, while the samples are
sent to the lab technician for testing. Each blood sample is tested by a lab technician. He
delivers the inventory manager to the blood report.

The inventory manager reads the report thoroughly. By this, he/she discards the unhealthy
blood and stores suitable amounts of healthy blood. Then, he or she updates the necessary
adjustments in the database for the blood inventory. He or she maintains note of when the blood
was first added to the inventory and when it would expire.

If needed by the hospital, the hospital manager places an order for the blood units. The order
is reviewed by the inventory manager. Following confirmation, he asks the hospital
administrator to handle the payment. The Delivery Boy carefully delivers the blood units to the
hospital after the order is confirmed and the payment is made.

The hospital manager verifies and updates the information.

REQUIREMENTS

FUNCTIONAL REQUIREMENTS

1. Access Website:
The user (hospitals) should be able to access web applications on a PC or mobile device
using an application browser or comparable service. There should be no restrictions on
using online applications.
2. Hospital Registration:
The user (hospitals) should be allowed to register through the online application as they
have already accessed it.
3. New Releases
When a new or updated version of a web application is made available, the user will
immediately notice the change in appearance.
4. Hospital log-in:

6
The user (hospital) should be able to log in to the online application once they have
registered. The database will store the login details for further use.
5. Request Blood:
When requesting blood in an emergency, the user (Hospital) must specify the blood
type, the location, the deadline, and the contact information. The blood bank will
receive the order and check its availability before sending it to the inventory. The
desired donor will receive the requested blood if it is available (Hospital).
6. View Request:
The Blood Bank ought to be able to view incoming requests, reply to them as necessary,
and search requests by choosing from two options: blood group and provision.
7. Search Blood Bank Stock:
The bloodstock in the Blood Bank Inventory will be searched to match the required
order after receiving the order from the hospital. Therefore, the hospital will receive
blood units that have been matched.
8. View Order Details:
The OrderId, the time the order was placed, the name of the hospital, its location, and
its address should all be viewable by the hospital's blood bank. Also, there is a tracking
tool that allows you to see the delivery person's location and the checkpoints they have
crossed.
9. View Delivery Status:
The hospital's blood bank ought to be able to see the delivery time's status. The hospital
manager must be able to phone the delivery person to get an update if the delivery
appears to be taking longer than expected.

NON-FUNCTIONAL REQUIREMENTS
1. Availability:
The system should be accessible round-the-clock including online components.
2. Reliability:
The recovery method restores a previous copy of the database that was backed up
to archival storage (typically tape) and reconstructs a more current state by
reapplying or redoing the operations of committed transactions from the backed-up
log, up to the time of failure if there is extensive damage to a wide portion of the
database as a result of catastrophic failures, such as a disc crash.
3. Security:Data storage is required by security systems, just like it is by many other
applications. Vendors must carefully select their database partner due to the unique
requirements of the security sector.

7
4. Correctness:
The Blood Unit delivered by the Blood Bank should match the Blood Unit requested
by the Hospital, and both should arrive at their intended location (Requested
Hospital).
5. Maintainability:
The manager of the blood inventory should keep accurate records of the blood
inventory stock.
6. Usability:
The price of the blood units is uniform.
7. Extensibility:
needs for website extensibility in case additional functional requirements need to
be added.

LOGICAL DATABASE DESIGN

1. Staff Database:
This database will include all the staff members' contact information for each database
unit. Staff members whose information needs to be retained include physicians,
registered nurses, lab technicians, website administrators, etc.
2. Blood Inventory Database:
All the blood units that have been collected are listed in this database. It may be
necessary to update this database when a blood unit needs to be deleted or added.
3. Order Database:
This database is accessible to the blood bank manager, who can view all the placed
orders there. All orders placed by hospitals in the past and present are listed in this
database.

USER ACCOUNTS INFORMATION MAINTENANCE

1. Only user with the role Blood blank will be authorized to access the User Accounts
Information Maintenance module.
2. Username cannot be blank.
3. User ID cannot be blank.
4. User ID should be unique for every user.
5. Password cannot be blank.
6. Role cannot be blank.

8
SOFTWARE SYSTEM ATTRIBUTES

SECURITY

The application will be password protected. Users will have entered correct username,
password and role in order to access the application.

MAINTAINABILITY

The application will be designed in a maintainable manner. It will be easy to incorporate new
requirements in the individual modules (i.e., Blood info, Hospital info, Order info, Order list
generation)

PORTABILITY

The application will be easily portable on any windows-based system that has MySQL
installed.

9
3) To create the function-oriented diagram: Data Flow Diagram (DFD)

ZERO-LEVEL DFD

10
FIRST LEVEL DFD:-

Retrieve

Retrieve

Blood Inventory DB
Order Info DB
Retrieve

Retrieve

Retrieve
Store
Store

Retrieve
Testing Info DB
Retrieve

Order
Blood
Info.
Inventory
Retrieve

Mgt. Blood Info DB


Store

Mgt

Store

Retrieve
Retrieve

Testing
Hospital Blood
Info. Blood Inventory Info.
Mgt.
Mgt.

Blood Bank
Blood Testing Unit
Login
Verification

OK

View Report
View Report

Login DB

Report
Generation

11
SECOND LEVEL DFD:-

Login DB

Blood Testing Unit Login Hospital

Blood Bank

Report
Generation

Testing
Add Info. Update
Blood Testing Unit Testing Info DB
Mgt.
Delete

Add
Order
Update
Info. Order Info DB
Blood Bank
Delete Mgt.

Add
Blood
Update
Info. Blood Info DB
Blood Bank
Delete Mgt.

Add
Blood
Update
Inventory Blood Inventory DB
Blood Inventory
Mgt

12
4) To perform the user’s view analysis for the suggested system: Use-case Diagram

Use-Case Diagram:-

Blood Bank Management System

Login

Blood Bank

Manage Blood
Info.

Blood Inventory

Blood Test
Result

Hospital
Blood Testing Unit
Order Blood

Order Info.

13
5) To draw the structural view diagram for the system: Class Diagram

CLASS DIAGRAM:-

Blood Bank

Bank_id

pwd

Blood_desc

add() Hospital
update()
hosp_id
delete()
pwd

Blood_group

add()
update()

delete()

Blood Testing Unit

Unit_id

pwd

report

add()
update()
Blood Inventory
delete()
Invent_id

pwd

Blood_group

add()
update()

delete()

14
6) To draw the behavioral view diagram: State-char Diagram or Activity Diagram

ACTIVITY DIAGRAM:-

Login to the Blood Bank


Management System
Start

Check User Level &


Permissions

Check Check Check Check


Permission Permission Permission Permission

Manage Blood Manage Testing


Manage Blood Manage Orders
Inventory Units

Logout From the System End

15
Blood Samples

Start

Hospital Orders
Blood Units

Sent to Blood
Testing Unit Blood Bank
Manages Blood Info

Yes If Requested No
Unit is
Available
Receives Orders
Yes If Blood
No
Unit Report
Accept
Reject are ok

Accept Reject

Yes If Requested No
Unit is
Available

Accept Reject
Order Acceptance

Sends Blood Units to


Blood Inventory

Receives Requested
Processes Orders
Blood Units

Updates Inventory

16
End
7) To draw the behavior view diagram for the suggested system: Sequence Diagram

SEQUENCE DIAGRAM:-

: Blood Bank : Blood Info Detail : Blood Data Controller : Blood Data
----

----

-------

--------
Enter Blood Details Add/Update
Submit Details

Blood Details Added

Enter Blood Details

Submit Details

Delete/Update

Blood Details Deleted

------
------
-----
------

: Blood Inventory : Blood Sample Detail : Blood Sample Data Controller : Blood Sample Data
----

----

-------

--------

Enter Blood Sample Details Add/Update


Submit Details

Blood Sample Details


Added

Enter Blood Sample Details

Submit Details

Delete/Update

Blood Sample Details


Deleted
------

-----

------

-------

17
: Blood Testing Unit : Blood Unit Detail : Blood Unit Data Controller : Blood Unit Data
----

----

-------

--------
Enter Blood Unit Details Add/Update
Submit Details

Blood Unit Added

Enter Blood Unit Details

Submit Details

Delete/Update

Blood Unit Deleted

------
------
-----
------

: Hospital : Order Info Detail : Order Data Controller : Order Data


----

----

-------

--------

Enter Order Details Add/Update


Submit Details

Order Details Added

Enter Order Details

Submit Details

Delete/Update

Order Details Deleted


------

-----

------

-------

18
8) Draw the component Diagram.

Blood

Data Access

Encryption
( Security
(
Access control

Blood Bank
Management Blood Group
System
Data Access

Encryption
( Persistence
(
System Admin Of
Access control
Blood Bank
Management System

Database Connector
(
Database
Blood Cells

Data Access

19
9) Draw the Deployment Diagram.

Login

Computer
Blood Info

Order Info

Blood Testing
Info Printer

Blood Inventory
Info

20
10) Perform Measurement of complexity with Halstead Metrics for chosen system.

Token count

n= number of program vocabulary


n1(no. of operands) =270
n2(no. of operators) =180
N1(Total occurrence of operators) = 540
N2(Total occurrence of operands) = 810
n2*(number of potential operands) =85

a) Program Length(N):
N=N1+N2
N=540+810
N=1350
b) Program Vocabulary:
n=n1+n2
n=270+180
n=450
c) Program Volume:
V=N*log2n
V=1350*log2450
V=11898.60
d) Potential Volume:
V*=(2+n2*) *log2(2+ log2n2*)
V*=267.12
e) Program Level:
L=V*/V
L=267.12/11898.60
L=0.0224

21

You might also like