Android Application for VU Blood Donation Society
Software Requirements Specification
Version 1.0
Group Id: S2402907B1 (BC210205874,BC210206522)
Supervisor Name : Abdur Rafay
Revision History
Date Version Description Author
(dd/mm/yyyy)
18/05/2024 1.0 Software Requirements BC210206522
Specifications, also known as
SRS, is the term used to
describe an in-depth description
of a software product to be
developed. It's considered one
of the initial stages of the
software development lifecycle
(SDLC). Think of it like the
map that points you to your
finished product.
The "Android Application for
VU Blood Donation Society"
aims to modernize and
streamline the process of blood
donation management through
an automated system. This
application addresses the
inefficiencies of traditional
blood bank methods, such as
outdated data entry and lack of
online donor databases, by
providing a platform for real-
time donor and patient
interactions.
Table of Contents
1. Scope (of the project)
2. Functional Requirements Non Functional requirements
3. Use Case Diagram
4. Usage Scenarios
5. Adopted Methodology
6. Work Plan (Use MS Project to create Schedule/Work Plan)
SRS Document
Scope of Project:
The scope of the "Android Application for VU Blood Donation Society"
encompasses a comprehensive framework for creating a user-friendly and
efficient platform for managing blood donation activities. The project is
designed to facilitate seamless interactions between blood donors, patients in
need of blood, and administrators overseeing the system.
User Registration and Authentication
Donor Registration and Approval:
Donors will register through the application, providing essential details
including blood type, contact information, and donation history.
After registration, donors require administrator approval to activate their
accounts, ensuring data accuracy and security.
Patient Registration:
Patients can register, providing necessary personal and medical details to
facilitate blood requests.
Similar to donors, patients can manage their profiles and update information
as needed.
Donor Profile Management:
Donors can update their profiles, including personal details and donation
history.
The application will track the donor's last donation date, donation frequency,
and eligibility based on donation intervals.
Patient Profile Management:
Patients can modify their profiles to keep their medical and contact
information current.
The system will maintain a history of blood requests made by the patient.
Functional and non Functional Requirements:
Functional Requirements
Donor Functional Requirements
Registration:
Donors must provide personal details, blood type, and contact information during
registration.
Login/Logout:
Donors can log in to access their profiles and application features.
Profile Management:
The profile should include the donor’s last donation date and frequency of donations.
Search Records:
Donors can search for patients in need of blood based on blood type and location.
Notifications:
Donors receive notifications about upcoming donation opportunities based on their blood
type and location.
View Patient Requests:
Donors can view requests from patients needing blood, filtered by relevant blood groups
and areas.
Patient Functional Requirements
Registration:
Patients must provide necessary personal and medical details during registration.
Login/Logout:
Patients can log in to access their profiles and application features.
Profile Management:
Patients can update their personal and medical information.
Generate Blood Requests:
Patients can create and submit blood requests specifying the required blood type and
location.
Requests are published for donors after administrator verification.
Search Active Donor Records:
Patients can search for active donors based on blood type and location.
Request Blood:
Patients can request blood for themselves or others by specifying any required blood
group.
Administrator Functional Requirements
Login/Logout:
Administrators can log in to manage the system and user accounts.
Secure logout functionality to ensure system integrity.
Profile Management:
Administrators can update their profiles and manage their account settings.
User Management:
Administrators can add, delete, or block donor and patient accounts.
Administrators must verify and approve donor registrations before
activation.
Approve Blood Requests:
Administrators review and approve blood requests submitted by patients
before they are published for donors.
Send Notifications:
Administrators can send messages and notifications to registered donors and
patients to facilitate communication.
Database Management:
Administrators maintain the database, ensuring data accuracy and security.
They can generate reports on donation activities, donor eligibility, and
patient requests.
Non Functional :-
1. Performance:
Response time: The system should respond to user interactions
within 2 seconds.
Throughput: The system should handle at least 1000 concurrent user
requests per minute.
Scalability: The system should be able to scale horizontally to
accommodate increasing user loads.
Resource usage: The system should not consume more than 50% of
CPU and memory resources under normal operation.
2. Reliability:
Availability: The system should be available 99.99% of the time,
excluding scheduled maintenance.
Fault tolerance: The system should continue to operate in the event
of hardware or software failures.
3. Security:
Authentication: Users should be required to authenticate with a
username and password.
Authorization: Access to sensitive data should be restricted based on
user roles and permissions.
4. Usability:
User interface: The user interface should be intuitive and easy to
navigate.
5. Scalability:
The system should be able to handle a tenfold increase in user traffic
without significant performance degradation.
Use Case Diagram(s):
Usage Scenarios:
Use Case Title Donor Registration
01
Use Case Id
User
Actors
Donor registers with the application providing necessary details.
Description
Donor fills out registration form.
Actions
Alternative N/A
Paths
Pre-Conditions Donor must not be registered previously.
Post Conditions Donor is registered successfully.
Author BC210206522
Registration form submission failure due to network issues or
Exception server errors.
Use Case Title Donor Login
02
Use Case Id
User
Actors
Donor logs in to the application using their credentials.
Description
Donor enters username and password.
Actions
Alternative N/A
Paths
Pre-Conditions Donor must be registered and approved by the administrator.
Post Conditions Donor successfully logged in.
Author BC210206522
Incorrect username/password combination, account not yet
Exception approved by administrator.
Use Case Title Donor Profile Modification
03
Use Case Id
User
Actors
Donor updates their profile information or donation history.
Description
Donor navigates to profile settings.
Actions
Alternative N/A
Paths
Pre-Conditions Donor must be logged in.
Post Conditions Donor profile is updated successfully.
Author BC210206522
Failure to save changes due to server errors or invalid data
Exception format.
Use Case Title Blood Donation Notification
04
Use Case Id
User
Actors
Donor receives notifications regarding blood donation requests
Description matching their blood group and location preferences.
Donor enables notification settings.
Actions
Alternative N/A
Paths
Pre-Conditions Donor must be logged in.
Post Conditions Donor receives relevant notifications.
Author BC210206522
Failure to receive notifications due to device settings or app
Exception permissions.
Adopted Methodology
Agile methodology is well-suited for the development of the PHP-Based Web Page
Speed Analysis Tool for SEO.
Here's why:
1. Flexibility:
Agile methodologies, like Scrum, emphasize flexibility and adaptability to changes.
In a project like developing a PHP-based web application for web page speed
analysis, requirements may evolve as the project progresses or as feedback is received
from users. Agile allows for these changes to be incorporated easily.
2. Iterative Development:
The project involves developing a web application with specific functionalities. Agile
methodologies break down the project into smaller increments called sprints. Each
sprint delivers a potentially shippable product increment. This approach aligns well
with the need to continuously improve and refine the speed analysis tool based on
user feedback.
3. Collaboration:
Agile methodologies emphasize collaboration among team members, including
developers, testers, and stakeholders. Given the interdisciplinary nature of the project,
involving aspects of web development, SEO, and user interface design, effective
collaboration is crucial for success.
4. Customer Feedback:
Agile methodologies encourage early and frequent feedback from stakeholders and
end-users. This is essential for ensuring that the developed tool meets the needs and
expectations of users, particularly in terms of providing actionable insights for SEO
enhancement and a user-friendly interface.
5. Adaptation to Emerging Technologies:
In the rapidly evolving landscape of web technologies and SEO practices, Agile
methodologies enable teams to adapt to changes and incorporate emerging
technologies or best practices as needed.
WATER FALL MODEL:
The Waterfall Model was first Process Model to be introduced. It is also referred to as a
linear-sequential life cycle model. It is very simple to understand and use. In a waterfall
model, each phase must be completed before the next phase can begin and there is no
overlapping in the phases. Waterfall model is the earliest SDLC approach that was used
for software development. The waterfall Model illustrates the software development
process in a linear sequential flow; hence it is also referred to as a linear-sequential life
cycle model. This means that any phase in the development process begins only if the
previous phase is complete.
SPIRAL MODEL:
1. To eliminate the risk that could be faced in development of software the use of
spiral methodology is adopted. For example, the risk might be a resignation from the key
person
2. Spiral Model has two dimensions. One is Radial dimension which represents the
cumulative cost to date, and the other is angular dimension which represents the progress
through the spiral.
3. The spiral model is very sensitive to risks. In this model development and
maintenance run in parallel. This method is used for development of large-scale and in-
house software.
VU PROCESS MODEL:
The VU Process Model is a framework used in software development to guide the
development process. It stands for Validate and Update, and it emphasizes the iterative
nature of software development. The model is often used in conjunction with the V-
Model or other software development lifecycle models.
The VU Process Model consists of the following phases:
1. Validate Requirements:
The requirements are validated to ensure they are complete, consistent, and feasible.
2. Validate Design:
The design is evaluated to ensure it meets the requirements and is technically feasible.
3. Validate Implementation:
This phase involves the validation of the software implementation.
Work Plan (Use MS Project to create Schedule/Work Plan)
