Se Prac-4

PRACTICAL 4
Aim :- System Design using procedural approach

Structure chart
A Structure Chart is a graphical representation of a software system's structure,

emphasizing the hierarchical organization of modules or functions and their
interactions in a procedural design.
Blood Bank
Management
System
Inventory Appointment
User Module
Module Module
Blood Donation Appointment

User Login
Entry Scheduling
Blood Type Donor/Recipient

User Registration
Classification Matching
User Profile Blood Inventory Notification

Management Management System
In this Structure Chart:

1) User Module: Responsible for user authentication, authorization, and
profile management. It allows registered users to log in securely, manage
their personal information, and ensures authorized access to the system.
a) User Login:
b) User Registration:
c) User Profile Management:
2) Inventory Module: Manages the blood inventory, including functionalities
to add,update, and remove blood units. It keeps track of blood types,
quantities, and ensures the availability of required blood types. Proper
inventory management is vital for timely and accurate blood supply.
a) Blood Donation Entry:

b) Blood Type Classification:
c) Blood Inventory Management:
3) Appointment Module: Facilitates the scheduling and tracking of blood

donation appointments. Users can book appointments, specify preferences,
and receive confirmation details. The module also manages appointment
schedules, ensuring efficient blood donation activities.
a) Appointment Scheduling:
b) Donor/Recipient Matching:
c) Notification System:
 These modules collectively form the backbone of the Blood Bank

Management System, enabling secure user interactions, efficient
inventory management, and streamlined appointment processes.
Physical DFD
DFD Level 0 :-
A Level 0 Data Flow Diagram (DFD) provides an overview of the entire system,
showing how external entities interact with the system and the high-level
processes within the system. Here's a simplified representation of a Level 0 D
In this Level 0 DFD:

External Entities: Donors, Staff, and Administrator are external entities
interacting with the Blood Bank Management System.
Processes: The Blood Bank Management System is represented as a single

process in the Level 0 DFD. It encompasses all the high-level functionalities and
processes within the system.
Data Store: The Database represents the storage of data related to donors,
staff, blood inventory, appointments, and other relevant information.
Data Flows: Data flows between the external entities and the Blood Bank
Management System, indicating the flow of information between donors, staff,
administrators, and the system's database.
Please note that this is a high-level overview. For a more detailed

understanding of the system's processes and data flows, lower-level DFDs
(Level 1, Level 2, etc.) can be created to break down the processes into more
granular sub-processes and data flows.
DFD Level 1:
Processes:
Manage Donors
 Input: Donor Information
 Output: Updated Donor Records
Manage Blood Inventory

 Input: Blood Donation Information
 Output: Updated Blood Inventory Records
Manage Blood Requests

 Input: Blood Request Details
 Output: Blood Allocation Information
Generate Reports
 Input: Data for Reports
 Output: Generated Reports
Data Stores:
Donor Database
 Contains information about registered donors.
Blood Inventory
 Stores information about available blood units.
Blood Requests
 Keeps track of blood requests and allocations.
Report Data
 Stores data used for generating reports.
Data Flows:
Donor Information
 From: Donor
 To: Manage Donors
Blood Donation Information

 From: Donor
 To: Manage Blood Inventory
Blood Request Details

 From: Requester
 To: Manage Blood Requests
Blood Allocation Information

 From: Manage Blood Requests
 To: Blood Inventory
Data for Reports

 From: Various Processes
 To: Generate Reports
External Entities:
Donor
 Interacts with the system to provide donor information.
Requester
 Places blood requests and receives allocated blood units.
This level 1 DFD provides a more detailed view of the Blood Bank Management
System, breaking down the major processes into sub-processes and showing
the data flows between them. Note that the actual system might have more
processes and details depending on the specific requirements of the Blood
Bank Management System you are designing
User interface (I/O) designing
For user login:

 Username and Password: Users should provide a unique
username/email and a strong password for authentication.
 Password Security: Enforce password complexity rules and store

passwords securely using encryption techniques.
 Password Recovery: Provide a secure password recovery process, such

as email verification, to help users reset their passwords if forgotten.
Blood request:
 Full name
 Phone number
 Email
 Gender
 Location
 Blood group
 City
Creating User Personas:

Importance: User personas represent typical users and help in empathizing
with their goals and challenges.
Application: Develop personas such as "Donor," "Hospital Staff," and
"Administrator," detailing their demographics, goals, and pain points to guide
UI design decisions.
Designing Information Architecture:
Importance: Logical organization of information ensures users can navigate the
system effortlessly, finding necessary features and data.
Application: Create a clear menu hierarchy and intuitive navigation paths. Use
wireframes to plan the layout and structure of the user interface.
Visual Design and Accessibility:

Importance: Visual design impacts user perception, while accessibility ensures
inclusivity for all users, including those with disabilities.
Application: Choose a calming color scheme, readable fonts, and appropriate
imagery. Follow accessibility guidelines (such as WCAG) to make the interface
usable for everyone, including those using screen readers or other assistive
technologies.
Iterative User Testing:
Importance: User testing helps in identifying usability issues and allows for
continuous improvement of the interface.
Application: Conduct usability tests with real users, observe their interactions,
collect feedback, and iterate on the design based on user experience to
enhance usability and user satisfaction.
By incorporating these principles, designers can create a user interface that is
user-friendly, visually appealing, logically organized, accessible to all, and
continuously improved based on user feedback.
Component-level design
Designing a component-level architecture for a Blood Bank Management

System involves breaking down the system into smaller, manageable
components, each responsible for specific functionalities. Here's an example of
how you can design the component-level architecture for the Blood Bank
Management System:
Components:
User Interface Components:
 Donor Registration Form: Allows donors to register their information.
 Blood Request Form: Enables users to request blood units.
 Inventory Management Interface: Provides tools for managing blood
inventory.
 Reports Dashboard: Displays various reports and analytics.
Authentication and Authorization:

 User Authentication Component: Manages user logins and
authentication.
 Access Control Component: Handles user roles and permissions.
Donor Management:
 Donor Information Component: Manages donor details, including
personal information and donation history.
 Donor Verification Component: Validates donor identity and eligibility
for blood donation.
Inventory Management:
 Blood Unit Tracking Component: Tracks individual blood units, including
blood type, expiration date, and storage location.
 Inventory Optimization Component: Monitors inventory levels and
suggests optimal restocking quantities.
 Storage and Handling Component: Ensures proper storage conditions
and handling protocols for blood units.
Blood Request and Allocation:

 Request Validation Component: Validates incoming blood requests for
completeness and urgency.
 Blood Type Matching Component: Matches requested blood type with
available blood units.
 Allocation and Dispatch Component: Allocates blood units to requests
and handles the dispatch process.
Reporting and Analytics:

 Data Collection Component: Gathers relevant data from various system
components.
 Report Generation Component: Generates standard reports (e.g., donor
statistics, inventory levels) and allows ad-hoc querying for custom
reports.
 Analytics Engine: Performs data analysis to identify trends, patterns, and
insights.
External System Interfaces:

 Hospital Information Systems (HIS) Integration: Integrates with hospital
systems to receive blood requests and update inventory levels.
 Donor Database Integration: Connects with external databases for
donor verification and validation.

Se Prac-4

Uploaded by

Copyright:

Available Formats

Se Prac-4

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Se Prac-4

Uploaded by

Copyright:

Available Formats

PRACTICAL 4

Aim :- System Design using procedural approach

A Structure Chart is a graphical representation of a software system's structure,

Blood Donation Appointment

Blood Type Donor/Recipient

User Profile Blood Inventory Notification

In this Structure Chart:

a) Blood Donation Entry:

3) Appointment Module: Facilitates the scheduling and tracking of blood

 These modules collectively form the backbone of the Blood Bank

In this Level 0 DFD:

Processes: The Blood Bank Management System is represented as a single

Please note that this is a high-level overview. For a more detailed

Manage Blood Inventory

Manage Blood Requests

Blood Donation Information

Blood Request Details

Blood Allocation Information

Data for Reports

For user login:

 Password Security: Enforce password complexity rules and store

 Password Recovery: Provide a secure password recovery process, such

Creating User Personas:

Visual Design and Accessibility:

Designing a component-level architecture for a Blood Bank Management

Authentication and Authorization:

Blood Request and Allocation:

Reporting and Analytics:

External System Interfaces:

You might also like