Beruflich Dokumente
Kultur Dokumente
Report1/II
7Sep2016
Siddharth Singh
Vijay Pratap Singh
SoftwareRequirementsSpecification
Pageii
SoftwareRequirementsSpecification
Pageiii
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
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
Password
A set of characters which can be used to correctly identify the exact personwho is log into the
system
Id number
The donor who will reply to the system to indicate that he/she will attendto the donation.MB
SoftwareRequirementsSpecification
Page2
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
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
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
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
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:
Page7
Changetheloginpasswordofadmin
Primaryactor :Systemadministrator
:
Precondition:
Mainscenario:
Internetconnectionshouldbeavailable.Adminloggedin
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
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
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
Attribute
SoftwareRequirementsSpecification
Page10
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
SoftwareRequirementsSpecification
Page12