Android based Blood Bank Network System

Software Requirements Specification

Version 1.0

  

Group Id: F170233080

Supervisor Name : Asim Mehmood

 Revision History
Date Version Description Author
(dd/mm/yyyy)
24/11/2017 1.0 A Software Requirement
Specification is a document
that captures complete
description about how system
will work.
It lays out Functional and non
Functional requirements, it
also include set of use-cases
that describe user interactions
that software must provide. It
also include usage scenario
and adopted methodology.
SRS should be complete,
consistent, verifiable,
unambiguous and correct.
 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 Android project mainly used in emergency situations, through mobile

user can get whole information regarding blood donors. This project acts as
a significant role in saving life of human beings and which is also its main
aim. The project Android Blood Bank network system is developed so that
users can view the information about registered blood donors such as name,
address, and other such personal information along with their details of
blood group and other medical information of donor.
Thus this application helps to select the right donor online instantly using
medical details along with the blood group.
The main aim of developing this application is to reduce the time to a great
extent that is spent in searching for the right donor and the availability of
blood require.. Thus this application provides the required information in no
time and also helps in quicker decision making.

Android Blood Bank is mobile based project. Mobile is a portable device, so

far it can move easily from one place to another place. So mobile is the best
choice for communication. By using of this application people who want to
donate their blood can register in this application by providing their details.
And persons who needs blood then they can search and found the blood
which group they need. After searching, the list of donors will be displayed.
Then user can communicate with them easily.

Functional and non Functional Requirements:

Functional Requirements:
1: Register the user

2: Login of user

3: Register the donor by himself

 4: Insert personal and medical information plus the blood group by the
donor

5: User can view all the donor details

6: Select the required donor

7: Send the request to the selected donor

8: The donor should be able to respond the request

9: The requester can contact donor

Non Functional Requirements:

1. Performance: Application should be designed and developed in such a
way that it should not utilize too many resources.

2. Usability: Usability defines how well the application meets the

requirements of the user and consumer by being intuitive, easy to localize
and globalize, providing good access for disabled users, and resulting in a
good overall user experience.
3. Secure: login system should be safe and secure.

Use Case Diagram(s):

Usage Scenarios:

Usage Scenario 1:
Use case related to registration of user
Use case title Register user
Abbreviated title Reg_user
Use case ID ABBN_FR_1
Actors User
Description This use case enable user to register himself.
Pre conditions Internet connection should be available.
Task sequence Exceptions
1. User initiates the 1. User has entered the invalid
command to starts the mobile phone number.
application
2. System is shown the all
features
3. User initiates the
register of user
command
4. A small questionnaire
given to the user, which
is related to personal &
contact details.
5. The user answers the
questionnaire and
finishes the registration.
6. Alert the user by
sending e-mails & SMS
messages about the
registration
Post User has registered successfully.
condition

Author Mc160401662
Usage Scenario 2:
Use case related to registration of donor
Use case title Register donor
Abbreviated title Reg_donor
Use case ID ABBN_FR_1
Actors Donor
Description This use case enable donor to register himself.
Pre conditions Internet connection should be available.
Task sequence Exceptions
1. Donor initiates the command 1. Donor has entered the invalid
to starts the application. mobile phone number.
2. System is shown the all 2. Donor doesn’t submit the
features. required reports.
3. Donor initiates the register of a
donor command.
4. A small questionnaire given to
the donor, which is related to
personal & contact details.
5. The donor answers the
questionnaire & goes to the
next step.
6. The system asks the donor to
submit the health condition
report & the evidence report of
blood group.
7. The donor submits the reports
& finishes the registration.
8. Alert the donor by sending e-
mails & SMS messages about
the registration .
Post Donor has registered successfully.
condition

Author Mc160401662
Usage Scenario 3:
Use case related to login of user
Use case title Login user
Abbreviated title Login_user
Use case ID ABBN_FR_1
Actors User
Description This use case enables the user to login.
Pre conditions Internet connection should be available.
Task sequence Exceptions
1. User initiates the 1. The provided password is
command to starts the wrong.
application 2. Allow the user to re-enter the
2. System is shown the all password.
features
3. Click the ‘Login of
user’ command button.
4. The system asking for
the user name & the
password.
5. User provides the user
name & the password.
Post User has logged in successfully.
condition

Author Mc160401662
Usage Scenario 4:
Use case related to change the password of user
Use case title Change the password
Abbreviated title password_user
Use case ID ABBN_FR_1
Actors User
Description This use case enables the user to change his password.
Pre conditions Internet connection should be available. User logged in.
Task sequence Exceptions
1. User selects the 1. Current password is wrong.
command to change the 2. New password doesn’t match
password. with the current new
2. The system is asked to password.
type the current
password, new
password & again the
new password to
confirm it.
3. User provides the
current password, new
password & confirm
new password.
4. New password is stored
in the system.
Post User has changed the password successfully.
condition

Author Mc160401662
Usage Scenario 5:
Use case related to login of donor
Use case title Login donor
Abbreviated title Login_donor
Use case ID ABBN_FR_1
Actors Donor
Description This use case enables the donor to login.
Pre conditions Internet connection should be available.
Task sequence Exceptions
1. Donor initiates the 1: The provided password is
command to starts the wrong.
application.
2. System is shown the all
features.
3. Click the ‘Login of donor’
command button.
4. The system asking for the
user name & the password.
5. Donor provides the user
name & the password.
Post Donor has logged in successfully.
condition

Author Mc160401662
Usage Scenario 6:
Use case related to select donor
Use case title Select the donor
Abbreviated title Select_Donor
Use case ID ABBN_FR_1
Actors User
Description This use case enables the user to select the donor.
Pre conditions Internet connection should be available. User logged in.
Task sequence Exceptions
1. User will search the 1. If donor contact information is
donor. wrong request will not be made.
2. User reads information
of the donor.
3. User selects the donor.
4. User sends request.
5. Click on close button.
Post User has successfully selected donor.
condition

Author Mc160401662
Usage Scenario 7:
Use case related to send request
Use case title Send request to the donor
Abbreviated title Req_Send
Use case ID ABBN_FR_1
Actors User
Description This use case enables the user to send request.
Pre conditions Internet connection should be available. User logged in.
Task sequence Exceptions
1. There is no donor in the system
1. User selects the who can donate blood to that blood
command to search group.
donors for exact blood
group.
2. System asks to insert the
blood group.
3. User inserts the needed
blood group details.
4. Select donors for the
donation.
5. Donors who are willing
to attend to the donation
will reply to the system.
Post User has successfully sent the request.
condition

Author Mc160401662
Software Development Methodologies

Software development methodologies are also known as system

development methodologies. Actually this is system development life cycle,
or it can be called System Development Process. Software development
methodologies are frames that are used to structure, control and plan the
process of developing system.

There are several models for such processes each describing approach to
different variety of tasks, or activities that take place during the process. The
names of the some of the methodologies are as follows:

 Agile software Development

 Incremental model
 Crystal Methods
 Extreme programming
 Waterfall model
 Spiral model

My adopted methodology is combination of these two given methodologies

as follows:

Waterfall methodology
The first published model of the software development process was derived
from other engineering processes. Because of the cascade from one phase to
another, this model is known as the waterfall model. This model is also
known as linear sequential model.
The waterfall model is a documentation-driven model. It therefore generates
complete and comprehensive documentation and hence makes the
maintenance task much easier. I t however suffers from facts that the client
feedback is received when the product is finally delivered and hence any
errors in the requirement specifications are not discovered until the product
is sent to the client after completion. This therefore has major time and cost
related consequences.
Spiral Methodology
This model was developed by Barry Boehm. The main idea of this model is
to avert risk as there is always an element of risk in development of
software. For example key personnel may resign at a critical juncture, the
manufacturer of the software development may go bankrupt, etc.
In its simplified form, the Spiral model is Waterfall model plus risk analysis.
In this case each stage is preceded by identification of alternatives and risk
analysis and is then followed by evaluation and planning for the next phase.
If risks cannot be resolved, project immediately terminated.
The main strength of the Spiral Model comes from the fact that it is very
sensitive to the risk. Because of the spiral nature of development it is easy to
judge how much to test and there is no distinction between development and
maintenance.
Each phase in Spiral model start with a design goal and end with a client
reviewing the process.

Adopted Methodology

Analysis In VU model
Requirements
Each phase
report back

Planning Risk analysis

Software requirement Cost effectiveness
Work plan With less risk

Client evaluation Development

Design

Deliver project with Designing coding

specific requirement Testing
otherwise recycle for Coding
further evaluation
Testing
Acceptance

The above is VU process model which is combination of waterfall and

spiral models. It has five phases first one is learning and analyzing
requirements secondly making of SRS third Test phase 1 fourthly Test Phase
2 and at the end Final deliverable .In the requirement phase system goals
services and constraints are established after discussion with users.

Benefits of using this methodology.

 This is sequenced model
 This model is easy to understand and use
 Each phase has specific deliverable
 In this model phases are completed and processed one at a time.
 Avoidance of risk is enhanced.
 Additional functionality can be added later.

why we use this methodology?

 This model is used when cost and risk evaluation is important.
 This methodology is also used when users are unsure of their
requirement.
 It is also used when significant changes are expected.

Work Plan (Use MS Project to create Schedule/Work Plan)

<Provide Gantt chart of your final project>