System Design Document: Blood Bank Management System
System Design Document: Blood Bank Management System
for
Prepared by Group
Number : 34
2.1 ASSUMPTIONS............................................................................................................................................................................................................... 3
2.2 CONSTRAINTS................................................................................................................................................................................................................3
3 DATABASE FUNCTIONS................................................................................................................................. 4
3.1 CONTROL-FLOW……………………………………………………………………………………………………………………………...………4
2. Blood Bank Administrators: Blood bank managers, executives, and personnel involved in
decision-making processes within the blood bank. The document helps them understand the
technical aspects of the system and how it supports their operational needs.
3. Quality Assurance and Testing Teams: Teams responsible for testing the BBMS to ensure
it functions correctly and adheres to performance and security standards. The document
provides a basis for crafting test cases and evaluating system performance.
4. Blood Bank Staff: Staff working directly with the Blood Bank Management System on a
daily basis, including blood bank technicians, administrators, and operational roles that rely
on the system for their day-to-day tasks. This document gives them a deeper understanding
of the system's inner workings.
1.3 Definitions, Acronyms and Abbreviations
● https://dbdiagram.io/
● https://erdplus.com/
● https://mermaid.live/
2.1 Assumptions
The following are assumptions made while developing the project:
Data Migration: Assuming that the BBMS has access to existing data related to blood inventory, donor
and patient information, and other relevant data, which will be migrated into the new database system
without significant data quality issues.
Hardware and Software Availability: Assuming that the necessary hardware, servers, database
management software, and development tools required for the BBMS project are available and meet the
project's technical requirements.
Data Cleansing and Transformation: Assuming that any data cleansing or transformation required
during the migration process is within the project scope and manageable, ensuring that the data in the new
system is reasonably accurate.
Data Security Measures: Assuming that appropriate data security measures, including access controls and
encryption, are in place to protect the BBMS database from unauthorized access and potential security
breaches.
Scalability: Assuming that the BBMS is designed to be scalable, capable of accommodating potential
future growth in terms of blood donation records, patient information, user accounts, and additional
features to meet the evolving needs of the blood bank.
User Acceptance: Assuming that the BBMS will be accepted and utilized effectively by blood bank
employees and staff, with adequate training and user-friendly interfaces to support their daily operations.
Maintenance and Updates: Assuming that the project team will provide regular maintenance, updates,
and enhancements to the BBMS to ensure it continues to function optimally, remains secure, and meets
changing requirements in the field of blood banking.
2.2 Constraints
The design contain the following constraints:
Admin Access Constraints:Admin access to the system is protected with unique and secure
credentials, ensuring the security and integrity of admin-related functions.
User Role-Based Dashboard Constraints: Each employee or user has different credentials
and is provided with a personalized dashboard that aligns with their specific role and
responsibilities within the system.
3.1 Control Flow
● 1NF - The tables are in 1NF, as there are no multivalued or composite attributes.
Each table cell contains atomic values, and each record is unique. Hence the database
is 1NF normalized.
● 2NF - The tables are already in 1NF as proved above. There are no partial
dependencies, that is, there are no non-prime keys solely dependent on only one part
of a primary key in any of the tables. Hence the database is 2NF normalized.
● 3NF - The tables are already in 2NF as proved above. There are no transitive
functional dependencies in the schema. There are no non-prime keys that are
dependent on another non-prime key in any specific table. Hence the database is
3NF normalized.
3.5 Schema Description