Sie sind auf Seite 1von 15

Blood Donation Web-Application

Report1/II
7Sep2016

Siddharth Singh
Vijay Pratap Singh

Blood Donation Web-Application


TableofContents
REVISIONHISTORY................................................................................................................................................II
DOCUMENTAPPROVAL........................................................................................................................................II
1.INTRODUCTION.....................................................................................................................................................1
1.1PURPOSE...............................................................................................................................................................1
1.2SCOPE...................................................................................................................................................................1
1.3DEFINITIONS,ACRONYMS,ANDABBREVIATIONS................................................................................................1
1.4REFERENCES.........................................................................................................................................................1
1.5OVERVIEW............................................................................................................................................................1
2.GENERALDESCRIPTION....................................................................................................................................2
2.1PRODUCTPERSPECTIVE........................................................................................................................................2
2.2PRODUCTFUNCTIONS...........................................................................................................................................2
2.3USERCHARACTERISTICS......................................................................................................................................2
2.4GENERALCONSTRAINTS.......................................................................................................................................2
2.5ASSUMPTIONSANDDEPENDENCIES......................................................................................................................2
3.SPECIFICREQUIREMENTS................................................................................................................................2
3.1EXTERNALINTERFACEREQUIREMENTS...............................................................................................................3
3.1.1UserInterfaces.............................................................................................................................................3
3.1.2HardwareInterfaces....................................................................................................................................3
3.1.3SoftwareInterfaces......................................................................................................................................3
3.1.4CommunicationsInterfaces.........................................................................................................................3
3.2FUNCTIONALREQUIREMENTS...............................................................................................................................3
3.2.1<FunctionalRequirementorFeature#1>..................................................................................................3
3.2.2<FunctionalRequirementorFeature#2>..................................................................................................3
3.3USECASES............................................................................................................................................................3
3.3.1UseCase#1.................................................................................................................................................3
3.3.2UseCase#2.................................................................................................................................................3
3.4CLASSES/OBJECTS..............................................................................................................................................3
3.4.1<Class/Object#1>....................................................................................................................................3
3.4.2<Class/Object#2>....................................................................................................................................3
3.5NONFUNCTIONALREQUIREMENTS......................................................................................................................4
3.5.1Performance.................................................................................................................................................4
3.5.2Reliability.....................................................................................................................................................4
3.5.3Availability...................................................................................................................................................4
3.5.4Security........................................................................................................................................................4
3.5.5Maintainability.............................................................................................................................................4
3.5.6Portability....................................................................................................................................................4
3.6INVERSEREQUIREMENTS......................................................................................................................................4
3.7DESIGNCONSTRAINTS..........................................................................................................................................4
3.8LOGICALDATABASEREQUIREMENTS..................................................................................................................4
3.9OTHERREQUIREMENTS........................................................................................................................................4
4.ANALYSISMODELS..............................................................................................................................................4
4.1SEQUENCEDIAGRAMS..........................................................................................................................................5
4.2DATAFLOWDIAGRAMS(DFD)...........................................................................................................................5
4.3ENTITYRELATIONSHIPDIAGRAM..............................................................................................................5

SoftwareRequirementsSpecification

Pageii

Blood Donation Web-Application


A.APPENDICES..........................................................................................................................................................5
A.1APPENDIX1.........................................................................................................................................................5
A.2APPENDIX2.........................................................................................................................................................5

SoftwareRequirementsSpecification

Pageiii

Blood Donation Web-Application


1. Introduction
2. Thisprojectisdevelopedtomanagethebloodstockinthe"BLOODBANK"andthe
bloodpricesaremaintainedinthedatabase.Newblooddetailsareenteredintothe
projecttomanageblooddetails.Blooddonordetailsareenteredandmaintainedinthe
database.
3. Bloodsalesandbloodpurchaseareenteredandmaintainedinthisproject.Blood
stockreports,salesreportsandbloodpurchasereportsaremanagedinthisproject.

1.1Purpose
ThepurposeofthisSRSandthe(intended)audienceforwhichitiswrittenis to provide the
software requirement specification report for Blood Donation Web-Application.

1.2 INTENDEDAUDIENCEANDREADINGSUGGESTIONS
This project is the college level project and is implementing under the guidance of college
professors. This project is useful to everyone who travels in flights.

1.3ProjectScope

The purpose of the online system is to create convenient and easy-to-use online system for
users, trying to get or donate blood. The system is based on a relational database with. We will
have a database supporting dozens of major cities around the world as well as hundreds of
flights by various airline companies. Above all, we hope to provide a comfortable user experience
along with the best pricing available.
The specification builds on the experience of users of IT technology in blood
transfusion that is currently available and informs both Connecting for Health (CfH)
and commercial companies producing both hardware and software.
The main objective of this specification is to support the automated tracking of blood
products from the initial ordering of a blood transfusion for a patient, through to the
taking of a blood sample for cross matching, to administration of a blood transfusion
and subsequent updates to care records. The scope of the specification includes the
following scenarios:
Routine blood transfusion;
Transfusion for special requirements (for example, cytomegalovirus (CMV)
seronegative blood, irradiated blood or antigen negative blood);
Emergency issue of blood;
Management of returned and unused blood units.

SoftwareRequirementsSpecification

Page1

Blood Donation Web-Application


1.3ProblemDefinitionofExistingSystem
Enteringthedetailsaboutthebloodgroups,members,addressesetc.Andtrackingthe
databaseiscomplicatedwhenthedetailsaremaintainedmanually.Thismakesthe
maintenanceofscheduleerroneous.
Limitationofmanualsystem:
Itistimeconsuming.
Itleadstoerrorproneresults.
Itconsumeslotofmenpowertobetterresults.
Itlacksofdatasecurity.
Retrievalofdatatakeslotsoftime.
Percentageofaccuracyisless.
Reportstakestimetoproduce.

1.4Definitions
Donor
The person who donate the blood.
Accepter
The person who accepts the blood
Transfusion
An act of transfusing donated blood, blood products, or other fluid into the circulatory system of a
person or animal.

WBBDSWebbasedblooddonationsystem
DatabaseConsistofallinformationrelatedtodonors&doctors
Login

The process which is related to logging into the system

Password

A set of characters which can be used to correctly identify the exact personwho is log into the
system
Id number

Identity card numberReplied donor

The donor who will reply to the system to indicate that he/she will attendto the donation.MB
SoftwareRequirementsSpecification

Page2

Blood Donation Web-Application

Mega byte (Unit of memory storage in computer)SRD

System requirement definitionSRS

System requirement specification

1.4References
http://www.bharatbloodbank.com
http://www.lionsbloodbank.net/

1.5Overview
The first section tells about introduction of blood bank management system and its scope. The
remaining sections of this document provide a general description, including characteristics of the
users of this project, the products hardware, and the functional and data requirements of the
product. General description of the project is discussed in section 2 of this document. Section 3
gives the functional requirements, data requirements and constraints and assumptions made while
designing the E-Store. It also gives the user viewpoint of product. Section 3 also gives the specific
requirements of the product. Section 3 also discusses the external interface requirements and gives
detailed description of functional requirements. Section 4 is for supporting information.
Now the description of SRS is follow:Section 1.
1.Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions
1.4 References
1.5 Overview
Section 2.
2.Overall Description
2.1 Product Perspective
2.2 Product Functions
2.3 User Characteristics
2.4 Constraints
Section 3.

SoftwareRequirementsSpecification

Page3

Blood Donation Web-Application


3. Specific Requirements
3.1 External Interfaces
3.2 Functions
3.3 Performance Requirements
3.4 Logical Database Requirements
3.5 Design Constraints
3.6 Assumptions and Dependencies

2.GeneralDescription
2.1ProductPerspective
WBBDS is mainly towards persons who are willing to donate blood to thepatients. Through
this system it will be easier to find a donor for exact blood type and easy tobuild the connection
between donor & the blood bank authorities. The main intend of buildingthis software is to
formal the procedure of blood donation & motivate donors in order to donationblood.
The system also consists of some local system hardware devices as well. A printer &
SMSindicator are the main devices among the other devices.
The entire software product includes the all relevant features to create a better
connectionbetween the blood donor & blood bank authorities.

2.2ProductFunctions
1. Admin:
This module focuses on the both donors & acceptors. Each member in a donor & acceptor is given a
user id and password, which identifies him uniquely. The member is given a login form. he enters the
login details user id and password. .. The options given to
Maintain donor details
Maintain referral once
Update donor details
View Experiences
Logout
Change Password
Whenever a user wants to change his / her password he can select the change password option.
The system displays the form, which asks him for his old password and new password. The system
then compares the old password with the existing password in the database

SoftwareRequirementsSpecification

Page4

Blood Donation Web-Application


2. Donor:
Each member in a Donor is given a user id and password, which identifies him uniquely. The
member is given a login form. he enters the login details user id and password. .. The options given
to a each member in a staff are Change password
Find a Blood group
Why donate blood
who needs blood
Find a Donor
Refer a friend
Logout
3. Acceptor:
In this you can store the information about Acceptors.
Change password
Find a blood group.
Who needs blood
Logout?

2.3UserCharacteristics
Inherethesystemadmin&thedonorarethesystemusers.Accordingtomyassumptionsthedonorwho
willregistertothesystemfromthewebsitecanunderstandeasyquestionswhichareinEnglish
language&he/shehastheabilitytorealizesmallinstructions&filltheapplicationwithoutany
errors&asmallknowledgeofcomputerstouploadthehealthconditioncertificatetothe
system.Userisverygeneroustoattendtothedonationwithsuchasmallannouncement.(emails&
SMSmessages

2.4GeneralConstraints
TheprogramwillbewritteninPHPlanguage.Thesystemwillmainlyrunningontheofficialwebsiteoftheblood
bank(www.slbloodbank.com).
The both kind of donors who has the internet connection & who hasnt the
internetconnectioncancontributetothedonationthroughtheWBBDsystem.Thedonorwhousesinternet
connectionwillbeguidedthroughsmall&cleardescriptions.Everydonormaygetausername&apasswordin
ordertologintothesystem.Aftertheregistrationofadonortheprogramwillauthenticatetheaccuracyofthe
donors
mobilenumberthroughcountingthenumberofcharactersintheenteredmobilenumberSystemusesthedonor
registrationnumber&theidentitycardnumbertoidentifyeachdonorseparately.Insidethesystemthe
administratorhasmoreadvancefunctionsthanthedonor.Thehospitaldoctorisnotauserofthesystem.Butthe
doctorconnectstothesysteminadifferentmanner.Thedoctormainlyhastheconnectionwiththesystemadmin.
SoftwareRequirementsSpecification

Page5

Blood Donation Web-Application


Indonorregistration,submissionofHCcertificates&providingdonationdetailstothesystemthedoctorwill
connectdirectlywiththesystemadministrator.

2.5AssumptionsandDependencies
Every donor has a mobile phone.
The system doesnt keep the details o
f the gathering stock of blood.The system database will be accessible in real time.
The donor doesnt submit
any fake reports to the system.Donors who want to contribute to a donation will definitely reply to the request of system.The
installation of th
e system to the website server hasnt considered as a process
inside the system. That process will do by the authorities who are controlling thewebsite. Therefore in here the installation
process is considered as a processwhich is in outside of the scope.A doctor or a patient can request for a exact blood group. But
the request comesthrough blood bank authorities to the system admin. Therefore doctor, patient arenot direct users of the
system.

4. SpecificRequirements
Software requirements:
Operating System: Windows XP
Front End: NET (Active Server Pages, Visual basic ,Java Script) Back end :
Sql Server
Hardware requirements :
MINIMUM P-IV SYSTEM
512 RAM
40 GB HDD

Performancerequired

Shouldrunon500GHz,64MBmachine.Shouldhaveaproperinternet
connection.Theresponsetimeforoccursachangewillbenomorethan4
seconds.Theresponsetimeforaccessthedatabasewillbenomorethan5
seconds

3.1ExternalInterfaceRequirements
Thesystemisbasicallyrunningontheofficialwebsiteofthegovt.bloodbank.Mainlythereare2actorsinthe
system.Thesystemprovidessomeadvancefeaturestothesystemadminthanthedonor.Ifthesystemadminlogs
in,thesysteminterfaceprovidessomemaincommandbuttonstotheadmin.
SoftwareRequirementsSpecification

Page6

Blood Donation Web-Application


Changeloginpassword.
Editdonorprofiledetails.
SearchDonorsforaexactbloodgroup&sendmessages
Printstatements.
UpdatethedatabaseSendbloodtestingDetails.
Searchdetailsfromthedatabase
Ifthedonorlogsin,thesystemwillprovideanotherdifferentinterfacewithdifferentcommand
Changeloginpassword
Editpersonal,contactdetails.
Detailsrelatedtocontributionstodonation.
Futureblooddonationdetails.
Withdrawnamefromthesystem

3.1.1UserInterfaces
3.1.2HardwareInterfaces
3.1.3SoftwareInterfaces
3.1.4CommunicationsInterfaces

3.2FunctionalRequirements
Use case diagrams are used to describe functional requirements of the system. Thediagrams are
drawn below.

If there is a network failure while a user is working in the system, all login detailsregarding on
user name & password of the user will be removed from the system.
User case related to system authorization
Usecase1:loginadmin
Primaryactor:systemadministrator
Precondition:internetconnectionshouldavailable
Mainscenario:

Log into the official blood bank website.2.


SoftwareRequirementsSpecification

Page7

Blood Donation Web-Application


Admin initiates the command to starts the application Upakara
WBBDS
3.
System is shown the all features of the system.4.
Click the Login of
administrator
command button.
5.
The system asking for the user name & the password.6.
Admin provides the username & the password.7.
System does authentication.8.
Main application relevant to admin is displayed
Alternative scenario:
1(a)authorizationfail.
1. A message is given to the admin that the provided password is wrong.
2. 7(a) 2. Allow the admin to re-enter the password. 3 chances will be given.
Use case 2:

Changetheloginpasswordofadmin

Primaryactor :Systemadministrator
:

Precondition:

Mainscenario:

Internetconnectionshouldbeavailable.Adminloggedin

Admin selects the command to change the password.2.

The system is asked to type the current password, new password & again the newpassword to confirm it.3.
Admin provides the current password, new password & confirm new password.4.
System does authentication.5.

SoftwareRequirementsSpecification

Page8

Blood Donation Web-Application


New password is stored in the system

3.2.1<FunctionalRequirementorFeature#1>
3.2.1.1Introduction
3.2.1.2Inputs
3.2.1.3Processing
3.2.1.4Outputs
3.2.1.5ErrorHandling
3.2.2<FunctionalRequirementorFeature#2>

3.3UseCases
3.3.1UseCase#1
3.3.2UseCase#2

3.4Classes/Objects
3.4.1<Class/Object#1>
3.4.1.1Attributes
3.4.1.2Functions
<Referencetofunctionalrequirementsand/orusecases>
3.4.2<Class/Object#2>

3.5NonFunctionalRequirements
Nonfunctionalrequirementsmayexistforthefollowingattributes.Oftentheserequirements
mustbeachievedatasystemwidelevelratherthanataunitlevel.Statetherequirementsinthe
followingsectionsinmeasurableterms(e.g.,95%oftransactionshallbeprocessedinlessthan
asecond,systemdowntimemaynotexceed1minuteperday,>30dayMTBFvalue,etc).

SoftwareRequirementsSpecification

Page9

Blood Donation Web-Application


3.5.1Performance
3.5.2Reliability
3.5.3Availability
3.5.4Security
3.5.5Maintainability
3.5.6Portability

3.6InverseRequirements
Stateany*useful*inverserequirements.

3.7DesignConstraints
Data should not become corrupted in case of network failure, system crash orpower failure
.
Security

The system is consisting of the features to keep the privacy of everydonor. Any donor cannot see any detail of any other donor

3.8LogicalDatabaseRequirements
Willadatabasebeused?Ifso,whatlogicalrequirementsexistfordataformats,storage
capabilities,dataretention,dataintegrity,etc.

3.9OtherRequirements
Security

This system doesnt have a tight security system. Because people


who log into the system are volunteers who like to donate blood for innocentpatients. But the system consists of some security
features.
Any donor cannot see any detail of any other donor.
Ifa donor doesnt manage to provide his user name & the password in 3
times the user automatically will log out from the website.

Attribute
SoftwareRequirementsSpecification

Page10

Blood Donation Web-Application


Thesystemwillpossessomequalityattributestotheusers.RobustnessTheentiresystem
includeseveryfunctionwhichisalwayshelptothesystemtoworkcorrectly&stronglyinall
conditions.ReliabilityThesystemhastheabilitytoworkallthetimewithoutfailuresapart
fromnetworkfailure.Thedonorcanhavethefaithonthesystem.Theauthoritieswillkeepthe
privacyofalldonorsinapropermanner.Whendoctorsfoundanydiseaseinthetestingstage
afterprovidingrelevantdetailstothedonorthesystemkeepsthesecretivelyofthe
donor.PortabilityAsmentionedearlierthesystemisworkingontheofficialwebsiteofthe
bloodbank.Thereforeifadonorusesdifferentoperatingsystem(Linux,Windows)ordifferent
webbrowser,afterloggingintothesystem,thesystemwillshowtheallfeaturesin
it.ModularityThesystemmainlyconsistsofmanyparts.SMSindicatingpartisthelargest
partofall.Inthatsectionthesysteminteractwiththeindicatingdevice.Ultimatelyhoweverthe
systemmanagestocombineallpartsofthesystem&workasalargesystem.InteroperabilityIn
herethesystemUpakarawillrunonthebloodbankwebsite.Therefore

4.AnalysisModels
ListallanalysismodelsusedindevelopingspecificrequirementspreviouslygiveninthisSRS.
Eachmodelshouldincludeanintroductionandanarrativedescription.Furthermore,each
modelshouldbetraceabletheSRSsrequirements.

4.1SequenceDiagrams
4.3DataFlowDiagrams(DFD)
4.2StateTransitionDiagrams(STD)

5.ChangeManagementProcess
IdentifyanddescribetheprocessthatwillbeusedtoupdatetheSRS,asneeded,whenproject
scopeorrequirementschange.Whocansubmitchangesandbywhatmeans,andhowwillthese
changesbeapproved.

A.Appendices
Appendicesmaybeusedtoprovideadditional(andhopefullyhelpful)information.Ifpresent,
theSRSshouldexplicitlystatewhethertheinformationcontainedwithinanappendixistobe
consideredasapartoftheSRSsoverallsetofrequirements.
ExampleAppendicescouldinclude(initial)conceptualdocumentsforthesoftwareproject,
marketingmaterials,minutesofmeetingswiththecustomer(s),etc.
SoftwareRequirementsSpecification

Page11

Blood Donation Web-Application


A.1Appendix1
A.2Appendix2

SoftwareRequirementsSpecification

Page12

Das könnte Ihnen auch gefallen