Srs Blood Donation

“Blood Donation Web-Application”

Report – 1/II 7-Sep -2016

Siddharth Singh Vijay Pratap Singh

Blood Donation Web-Application Table of Contents REVISION DOCUMENT 1.

HISTORY................................................................................................................................................ II APPROVAL........................................................................................................................................ II

INTRODUCTION.................................................................................................................................................... .1 1.1 PURPOSE .............................................................................................................................................................. .1 1.2 SCOPE.................................................................................................................................................................. .1 1.3 DEFINITIONS, ACRONYMS , AND ABBREVIATIONS..................... ................................ ..................... .................... ..................... ..................... ................................ ...................... .1 1.4 REFERENCES........................................................................................................................................................ .1 1.5 OVERVIEW........................................................................................................................................................... .1

2. GENERAL DESCRIPTION................................................................................................................................... .2 2.1 PRODUCT PERSPECTIVE....................................................................................................................................... .2 2.2 PRODUCT FUNCTIONS.......................................................................................................................................... .2 2.3 USER CHARACTERISTICS.................... .............................. ..................... ..................... .................... ..................... ..................... ..................... ..................... .................... .............................. .................... .2 2.4 GENERAL CONSTRAINTS...................................................................................................................................... .......................................................................................................................................2 .2 2.5 ASSUMPTIONS AND DEPENDENCIES..................................................................................................................... ......................................................................................................................2 .2 3. SPECIFIC REQUIREMENTS............................................................................................................................... .2 3.1 EXTERNAL INTERFACE REQUIREMENTS.................... ............................... ..................... .................... ..................... ..................... ..................... ...................................... ........................... .3 3.1.1 User Interfaces............................................................................................................................................ .3 3.1.2 Hardware Interfaces................................................................................................................................... .3 3.1.3 Software Interfaces..................................................................................................................................... .3 3.1.4 Communications Interfaces........................................................................................................................ .3 3.2 FUNCTIONAL REQUIREMENTS.............................................................................................................................. ...............................................................................................................................3 .3 3.2.1 ................................................................................................. .3 3.2.2 ................................................................................................. .3 3.3 USE CASES........................................................................................................................................................... ............................................................................................................................................................3 .3 3.3.1 Use Case #1................................................................................................................................................ .3 3.3.2 Use Case #2................................................................................................................................................ .3 3.4 CLASSES / OBJECTS..................... ............................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ..................... ..................................... .......................... .3 3.4.1 ................................................................................................................................... .3 3.4.2 ................................................................................................................................... .3 3.5 NON-FUNCTIONAL REQUIREMENTS..................................................................................................................... ......................................................................................................................4 .4 3.5.1 Performance................................................................................................................................................ .4 3.5.2 Reliability.................................................................................................................................................... .4 3.5.3 Availability.................................................................................................................................................. .4 3.5.4 Security....................................................................................................................................................... .4 3.5.5 Maintainability............................................................................................................................................ .4 3.5.6 Portability................................................................................................................................................... .4 3.6 INVERSE REQUIREMENTS..................................................................................................................................... ......................................................................................................................................4 .4 3.7 DESIGN CONSTRAINTS......................................................................................................................................... ..........................................................................................................................................4 .4 3.8 LOGICAL DATABASE REQUIREMENTS..................... ................................ ..................... .................... ..................... ..................... ..................... ........................................ ............................. .4 3.9 OTHER REQUIREMENTS.................... .............................. .................... ..................... ..................... ..................... ..................... .................... ..................... ..................... ................................ ...................... .4 4. ANALYSIS MODELS............................................................................................................................................. .4 4.1 SEQUENCE DIAGRAMS......................................................................................................................................... .5 4. 2DATA FLOW DIAGRAMS (DFD)........... (DFD)..................... .................... ..................... ..................... ..................... ..................... ..................... ..................... ...................................... ............................ .5 4.3 ENTITY RELATIONSHIP DIAGRAM............................................................................................................. .5

Software Requirements Specification

Page ii

Blood Donation Web-Application A.

APPENDICES......................................................................................................................................................... .5 A.1 APPENDIX A.2 APPENDIX

1.................. 1............................ ..................... ..................... .................... ..................... ..................... ..................... ..................... .................... ..................... ......................................... .............................. .5 2.................. 2............................ ..................... ..................... .................... ..................... ..................... ..................... ..................... .................... ..................... ......................................... .............................. .5


Page iii

Blood Donation Web-Application 1. Intro Introdu duct ctio ion n 2. This project project is developed developed to manage manage the blood blood stock in the "BLOOD "BLOOD BANK" BANK" and the blood prices prices are maintained maintained in the database. database. New blood blood details details are entered entered in to the project to manage blood blood details. details. Blood donor donor details details are entered entered and maintained maintained in in the database. database. 3. Blood sales sales and blood blood purchase purchase are entered entered and maintaine maintained d in this project. project. Blood stock reports, reports, sales reports reports and blood purchase purchase reports reports are managed managed in this this project. project.

1.1 Purpose st opr o v i det he The purpose of this SRS and the (intended) audience for which it is written i s of t war er equi r eme nts pec i fi c at i onr ep or tf orBl oo dDon at i onWebApp l i c at i on. 1.2

INTENDED AUDIENCE AND READING SUGGESTIONS

Thi spr oj ec ti st hec ol l egel e vel pr oj ec tandi si mpl ement i ngundert hegui danc eofc ol l ege pr of es sor s .Thi spr oj ec ti sus ef ul t oe v er y onewhot r a vel si nfl i ght s .

1.3 Project Scope Th epur pos eoft h eon l i nes y s t em i st oc r eat ec on v eni enta ndea sy t ou seon l i nes y s t em f o r us er s ,t r y i ngt ogetordonat ebl ood.Thesy s t em i sbas edonar el at i onal dat abas ewi t h.Wewi l l h av ead at a ba s es up po r t i n gd oz en so fma j o rc i t i e sa r ou ndt h ewo r l da swe l l a sh un dr e dsof fl i ght sbyv ar i ou sai r l i nec ompan i es .Abo v eal l ,wehop et opr o v i deac omf or t a bl eus ere x per i enc e al ongwi t ht hebes tpr i c i nga vai l abl e.  Thespe ci fic a t i onbui l dsont hee xpe r i e nc eofus e r sofI Tt e c hnol ogyi nbl ood

t r a ns f us i ont ha ti sc ur r e nt l ya v ai l a bl ea ndi nf or msbot hConne ct i ngf orHe al t h( Cf H) andcomm mmer ci alcomp mpani espr oduci ngbot hhar dwa war eandsof t war e.  Thema ma i nobj e c t i v eoft hi ss pe ci fic a t i oni st os uppor tt hea ut oma t e dt r a c ki ngofbl ood pr oduct sf r om t hei ni t i alor der i ngofabl oodt r ansf usi onf orapat i ent ,t hr ought ot he t a ki ngofabl oods ampl ef orc r os sma t c hi ng,t oa dmi ni s t r a t i onofabl oodt r a ns f us i on andsubsequentupdat est ocar er ecor ds.Thescopeoft hespeci ficat i oni ncl udest he f ol l owi ngs ce na r i os :  •Rout i nebl oodt r a ns f us i on;  •T r a ns f us i onf ors pe ci a lr e qui r e me me nt s( f ore x ampl e ,c yt ome ga l ov i r us( CMV) s er one ga t i v ebl ood,i r r a di a t e dbl oodora nt i ge nne ga t i v ebl ood) ;  •Eme r gencyi ssueofbl ood;  •Ma nageme mentofr et ur nedandunusedbl ooduni t s.


Page 1

Blood Donation Web-Application 1.3 Problem Definition of Existing System  Entering the details about the blood groups, members, addresses etc. And tracking the

database is complicated when the details are maintained manually. This makes the maintenance of schedule erroneous. Limitation of manual system:  It is time consuming.  It leads to error prone results.  It consumes lot of men power to better results.  It lacks of data security.  Retrieval of data takes lots of time.  Percentage of accuracy is less.  Reports takes time to produce.

1.4 Definitions Donor The person who donate the blood.

Accepter The person who accepts the blood

Transfusion An act of transfusing transfusing donated blood, blood products, or other other fluid into the circulatory system system of a person or animal.

WBBDS - Web based blood donation system Database - Consist of all information related to donors & 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!"# Software Requirements Specification

Page 2

Blood Donation Web-Application – "ega byte $%nit of memory memory storage in computer&S computer&SR' R'

– System re(uirement re(uirement definitionS definitionSRS RS

– System re(uirement specification

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

1.5 Overview 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 product’s hardware, and the functional and data requirements of the product. eneral description of the project is discussed in section ! of this document. "ection # gives the functional requirements, data requirements and constraints and assumptions made while designing the $%"tore. &t also gives the user viewpoint of product. "ection # also gives the specific requirements of the product. "ection # also discusses the e'ternal interface requirements and gives detailed description of functional requirements. "ection ( is for supporting information. )ow the description of "*" is follow+% "ection . .&ntroduction . -urpose .! "cope .# Definitions .( *eferences . /verview "ection !. !./verall Description !. -roduct -erspective !.! -roduct 0unctions !.# 1ser 2haracteristics !.( 2onstraints "ection #.


Page 3

Blood Donation Web-Application #. "pecific *equirements #. $'ternal &nterfaces #.! 0unctions #.# -erformance *equirements #.( 3ogical Database *equirements #. Design 2onstraints #.4 Assumptions and Dependencies

2. General Description 2.1 Product Perspective )##'S 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 be betwee tween n dono onor * the blood ban+ ban+ authori horitties! The main int intend of building ingthis soft oftware is to formal the procedure of blood donation * moti,ate donors in order to donationblood! The system also consists of some local system hardware de,ices as well! A printer * S"Sindicator are the main de,ices among the other de,ices! The entire software product includes the all rele,ant features to create a better connectionbetween the blood donor * blood ban+ authorities!

2.2 Product Functions . Admin+ This module focuses on the both donors 5 acceptors. $ach member in a donor 5 acceptor is given a user id and password, which identifies him uniquely. The The member is given a login form. he enters the login details user id and password. .. The options given to 6 7aintain donor details 6 7aintain referral once 6 1pdate donor details 6 8iew $'periences 6 3ogout 2hange -assword 9henever 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 e'isting password in the database;


Page 4

Blood Donation Web-Application !. Donor+ $ach 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 2hange password 0ind a
2.3 User Characteristics Characteristics In here the system admin & the donor are the system users. According to myassumptions the donor who will register to the system from the website canunderstand easy questions which are in English language & he/she has the abilityto realize small instructions & fill the application without any errors & a smallknowledge of computers to upload the health condition certificate to the system.User is very generous to attend to the donation with such a small announcement.(e-mails & SMS messages

2.4 General Constraints The program will be written in PHP language.The system will mainly running on the official website of the blood bank ( www.slbloodbank.com ). ).

The both kind of donors who has the internet connection & who hasn’t the internet connection can contribute to the donation through the WBBD system.The donor who uses internet connection will be guided through small & cleardescriptions.Every donor may get a user name & a password in order to log into the system.After the registration of a donor the program will authenticate the accuracy of the

donor’s mobile number through counting the number of characters in the enteredmobile numberSystem uses the donor registration number & the identity card number to identifyeach donor separately.Inside the system the administrator has more advance functions than the donor.The hospital doctor is not a user of the system. But the doctor connects to thesystem in a different manner. The doctor mainly has the connection with thesystem admin. Software Requirements Specification

Page 5

Blood Donation Web-Application In donor registration, submission of HC certificates & providingdonation details to the system the doctor will connect directly with the systemadministrator.

2.5 Assumptions and Dependencies -,ery donor has a mobile phone!

The system doesn’t keep the details o f the gathering stoc+ of blood!The system database will be accessible in real time!

The donor doesn’t submit any fa+e reports to the system!'onors who want to contribute to a donation will definitely reply to the re(uest of system!The installation of th

e system to the website server hasn’t considered as a process inside the system! That process will do by the authorities who are controlling thewebsite! Therefore in here the installation pro proce cesss is con conside idered red as a proce ocesswh sswhic ich h is in outsi tside of the scope! ope!A A doctor tor or a patient ent can can re(u e(uest est for a exact act blood group! #ut the re(uest comesthrough blood ban+ authorities to the system admin! Therefore doctor. patient arenot direct users of the system!

4. Specif Specific ic Requ Require iremen ments ts "oftware requirements+ /perating "ystem+ 9indows >0ront $nd+ )$T ?Active "erver -ages, 8isual basic ,@ava "cript
Bardware requirements + 7&)&717 -%&8 "C"T$7 ! *A7 ( < BDD

Performance required Should run on 500 GHz, 64MB machine.Should have a proper internet connection.The response time for occurs a change will be no more than 4 seconds.The response time time for access the database will be no more than 5 seconds 3.1 External Interface Requirements The system is basically running on the official website of the govt. blood bank. Mainlythere are 2 actors in the system. The system provides some advance features to the system adminthan the donor. If the system admin logs in, the system interface provides some main commandbuttons to the admin. Software Requirements Specification

Page 6

Blood Donation Web-Application Change login password. Edit donor profile details. Search Donors for a exact blood group & send messages Print statements. Update the databaseSend blood testing Details. Search details from the database If the donor logs in, the system will provide another different interface with differentcommand Change login password Edit personal,contact details. Details related to contributions to donation. Future blood donation details. Withdraw name from the system

.

3.1.1 User Interfaces 3.1.2 Hardware Interfaces 3.1.3 Software Interfaces 3.1.4 Communications Interfaces

3.2 Functional Requirements %se case diagrams are used to describe functional re(uirements of the system! Thediagrams are drawn below! 

If there is a networ+ failure while a user is wor+ing in the system. all login detailsregarding on user name * password of the user will be remo,ed from the system! %ser case related to system authori/ation Use case 1 : login admin Primary actor :system administrator Pre condition :internet connection should available Main scenario:

Log into the official blood ban+ website!0! Software Requirements Specification

Page 7

Blood Donation Web-Application Admin initiates the command to starts the application “Upakara “Upakara 1

WBB!" 2! System is shown the all features features of the system!3! system!3 !

#lick the “$o%in of administrator

" command button 4! The system as+ing for the user name * the password!5 password!5!! Admin pro,ides pro,ides the username * the password!6! System does authentication!7 authentication!7!! "ain application rele,ant to admin is displayed Alternative scenario:

1 (a)authorization fail. 8! A mess message age is gi,en gi,en to the the admin admin that the the pro,ided pro,ided pass password word is is wrong! wrong! 0! 6$a& 0! Allow Allow the admin admin to re1ent re1enter er the passwor password! d! 2 chances chances will will be gi,en! gi,en! Use case 2:

Primary actor

Change the login password of admin :

:System administrator

Pre condition :

Internet connection should be available. Admin logged in

Main scenario :

Admin selects the the command to change the password!0! password!0 !

The system is as+ed to type the current password. new password * again the newpassword newpassword to confirm it!2! it!2 ! Admin pro,ides the current password. new password * confirm new password!3! password!3 ! System does authentication!4 authentication!4!!


Page 8

Blood Donation Web-Application 9ew 9ew pass asswor word is stored ored in the sys system

3.2.1 3.2.1.1 Introduction 3.2.1.2 Inputs 3.2.1.3 Processing 3.2.1.4 Outputs 3.2.1.5 Error Handling 3.2.2 …

3.3 Use Cases 3.3.1 Use Case #1 3.3.2 Use Case #2 …

3.4 Classes / Objects 3.4.1 3.4.1.1 Attributes 3.4.1.2 Functions 3.4.2 …

3.5 Non-Functional Non-Functional Requirements Non-functional Non-functional requirement requirementss may exist for for the following following attributes. attributes. Often these these requirements requirements must be achieved at a system-wide level rather than at a unit level. State the requirements in the following following sections in in measurable measurable terms (e.g., (e.g., 95% of transaction transaction shall shall be processed processed in less less than a second, system downtime may not exceed 1 minute per day, > 30 day MTBF value, etc).


Page 9

Blood Donation Web-Application 3.5.1 Performance 3.5.2 Reliability 3.5.3 Availability 3.5.4 Security 3.5.5 Maintainability 3.5.6 Portability

3.6 Inverse Requirements State any *useful* inverse requirements.

3.7 Design Constraints 'ata should not become corrupted in case of networ+ failure. system crash orpower failure . Security

– The system is consisting of the features to +eep the pri,acy of e,erydonor! Any donor cannot see any detail of any other donor

3.8 Logical Database Requirements Will a database be used? If so, what logical requirements exist for data formats, storage capabilities, data retention, data integrity, etc.

3.9 Other Requirements Security

– This system doesn’t have a ti%ht security system Because people who log into the system are ,olunteers who li+e to donate blood for innocentpatients! #ut the system consists of some security features! Any donor cannot see any detail of any other donor! If a donor doesn’t mana%e to provide his user name & the password in ' times the user automatically will log out from the website!

Attribute


Page 10

Blood Donation Web-Application The system will posses some quality attributes to the users.RobustnessThe entire system includes every function which is always help to the system to work correctly & strongly in all conditions.ReliabilityThe system has the ability to work all the time without failures apart fr fromne omnettwork failure lure.. The dono onor can have the the fait faith h on the system. tem. The aut authoriti ities will ill keepthe pr priva ivacy of all donors nors in a proper manner. er.When doctors found any dise isease in the the testi sting stage tage after providing relevantdetails to the donor the system keeps the secretively of the donor.PortabilityAs mentioned earlier the system is working on the official website of the bloodbank. Therefore if a donor uses different operating system (Linux, Windows) ordifferent web browser, after logging into the system, the system will show the allfeatures in it.ModularityThe system mainly consists of many parts. SMS indicating part is the largest pa partof rtof all all. In that secti ectio on the syst ystem inte interract with the the indi indiccating device ice. Ultimatel tely howev oweveerthe the system manages to combine all parts of the system & work as a large system.InteroperabilityIn here the system Upakara will run on the blood bank website. Therefore

4. Analysis Models List all analysis analysis models models used in developing developing specific specific requirements requirements previously previously given given in this SRS. SRS. Each model model should include include an introduction introduction and a narrative narrative description description.. Furthermore, Furthermore, each model should be traceable the SRS’s requirements.

4.1 Sequence Diagrams 4.3 Data Flow Diagrams (DFD) 4.2 State-Transition Diagrams (STD)

5. Change Management Process Identify and and describe describe the process process that will will be used to update the SRS, as needed, needed, when project project scope or requirements change. Who can submit changes and by what means, and how will these changes be approved.

A. Appendices Appendices Appendices may be used used to provide provide additional additional (and hopefully hopefully helpful) helpful) information information.. If present, present, the SRS should explicitly state whether the information contained within an appendix is to be considered as a part of the SRS’s overall set of requirements. Example Example Appendices Appendices could include include (initial) (initial) conceptual conceptual documents documents for the software software project, project, marketing materials, minutes of meetings with the customer(s), etc.


Page 11

Blood Donation Web-Application A.1 Appendix 1 A.2 Appendix 2


Page 12

Srs Blood Donation

Recommend Documents