Scribd
Upload
2 views

SRS Example

The document outlines a Blood Donation System designed for managing blood donations, supporting roles for Donors, Recipients, and Administrators. Key features include donor registration, blood donation scheduling, blood request submission, and inventory management, all accessible via a web-based application. The system must comply with medical data security regulations and handle up to 1000 concurrent users.

Uploaded by

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

SRS Example

The document outlines a Blood Donation System designed for managing blood donations, supporting roles for Donors, Recipients, and Administrators. Key features include donor registration, blood donation scheduling, blood request submission, and inventory management, all accessible via a web-based application. The system must comply with medical data security regulations and handle up to 1000 concurrent users.

Uploaded by

joel
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 5

1.

Introduction
1.1 Purpose
This document describes the Blood Donation System which enables the management of blood
donations. It supports three main user roles:
 Donor: A person who donates blood.
 Recipient: A person who receives blood from the blood bank.
 Administrator: The system admin responsible for managing blood bank records, donor data,
and overall system operations.
1.2 Scope
The system will:
 Allow Donors to register, schedule donations, and track their donation history.
 Allow Recipients to request blood, track their requests, and view blood availability.
 Allow Administrators to manage donors, recipients, and blood bank inventory.
1.3 Definitions and Acronyms
 Donor: A person who donates blood to the blood bank.
 Recipient: A person who requires blood, typically due to surgery, medical conditions, etc.
 Admin: An administrator or healthcare staff member responsible for managing the system.

2. Overall Description
2.1 Product Perspective
The system will be a web-based application accessible via browsers. Users will interact with the
system based on their roles (Donor, Recipient, Admin).
2.2 Product Features
 Donor Features: Registration, blood donation scheduling (date and time), donation history.
 Recipient Features: Blood request submission, tracking of blood availability.
 Admin Features: Management of donor and recipient records, blood inventory management,
report generation.
2.3 User Classes and Characteristics
 Donor: Needs to register and schedule blood donations (date and time). Can view past
donation history.
 Recipient: Needs to request blood, view blood availability.
 Admin: Manages the database, approves donors, and manages blood inventory.
2.4 Operating Environment
 The system will run on Apache server and be accessible via any modern web browser
(Chrome, Firefox, Safari).
2.5 Constraints
 The system must comply with relevant medical data security regulations.
 The system must handle up to 1000 active users concurrently.

3. System Features
3.1 Feature 1: Donor Registration
 Description: Donors can register by entering personal details and medical history. The admin
must approve the registration.
 Functional Requirements:
o Donor enters name, contact details, blood type, and medical history.

o The system validates eligibility based on predefined criteria (age, weight, etc.).

o Donor receives an email verification link.

o Admin verifies and approves donor registration.

 Use Case:
o Actor: Donor

o Precondition: User is not yet registered.

o Main Flow:

1. Donor navigates to the registration page.


2. Donor enters personal information, medical history, and blood type.
3. Donor submits registration.
4. System sends email verification.
5. Admin reviews and approves donor details.
6. Donor receives confirmation.
3.2 Feature 2: Blood Donation Scheduling (Donor)
 Description: Donors can schedule a blood donation appointment (date and time).
 Functional Requirements:
o Donors can select donation time slots.

o Donors receive confirmation and reminders of their scheduled appointment.

 Use Case:
o Actor: Donor
o Precondition: Donor is registered and logged in.

o Main Flow:

1. Donor logs into the system.


2. Donor selects the "Schedule Donation" option.
3. Donor chooses an available date and time slot.
4. The system confirms the appointment.
5. Donor receives a confirmation email with details.
6. Donor is reminded of the appointment 24 hours before the donation.
3.3 Feature 3: Blood Request Submission (Recipient)
 Description: Recipients can request blood from the system, specifying the required blood
type and urgency.
 Functional Requirements:
o Recipients provide their personal and medical information.

o Recipients specify the required blood type and the urgency of the request (e.g.,
immediate, planned).
o System checks if the requested blood type is available in the blood bank.

 Use Case:
o Actor: Recipient

o Precondition: Recipient is registered in the system.

o Main Flow:

1. Recipient logs into the system.


2. Recipient submits a blood request by selecting the blood type, quantity, and
urgency.
3. System checks blood availability.
4. Recipient receives an email/phone notification regarding the request status.
3.4 Feature 4: Blood Bank Inventory Management (Admin)
 Description: Admins can manage the blood inventory by updating quantities and types
available.
 Functional Requirements:
o Admin can add, update, and remove blood units from the inventory.

o The system notifies the admin when a blood type is running low.

o Admin can generate reports on inventory usage.

 Use Case:
o Actor: Admin

o Precondition: Admin is logged in.

o Main Flow:

1. Admin logs into the system.


2. Admin accesses the inventory management section.
3. Admin updates the inventory based on incoming blood donations or usage.
4. Admin generates reports for stock levels and usage.
3.5 Feature 5: Blood Availability Status (Recipient)
 Description: Recipients can track the status of their blood request (available or not).
 Functional Requirements:
o Recipients receive real-time status updates on their request.

o The system will notify the recipient when the requested blood becomes available.

 Use Case:
o Actor: Recipient

o Precondition: Recipient has submitted a blood request.

o Main Flow:

1. Recipient logs into the system.


2. Recipient views their request status.
3. Recipient receives an email/phone notification when the requested blood is
available.

4. External Interface Requirements


4.1 User Interfaces
 Donor Interface: Allows donors to register, schedule date and time for blood donation, view
donation history.
 Recipient Interface: Allows recipients to request blood, track blood availability.
 Admin Interface: Allows administrators to manage blood inventory, donor and recipient
records.
4.2 Hardware Interfaces
 The system is hosted on Apache server and supports browsers running on devices like PCs,
smartphones, and tablets.
4.3 Software Interfaces
 Email Service/phone service: For sending notifications to donors, recipients, and admins.
5. System Attributes
5.1 Performance Requirements
 The system should be able to handle up to 1000 concurrent users.
5.2 Security Requirements
 All user data must be encrypted using SSL/TLS.
 The system must comply with medical data protection regulations.
 User passwords must be stored using strong hashing algorithms.
5.3 Reliability Requirements
 The system should be available 99.9% of the time.
 Regular backups of the database should be maintained to prevent data loss.

6. Other Requirements
 Reporting: The system should allow the admin to generate monthly reports on blood
donations, requests, and inventory usage.
 Notifications: The system should send automated notifications via email or SMS for
appointments, requests, and reminders.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy