Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
2010cs048
Page 1
Table of contents
Table of Contents 1. Introduction 1.1 Purpose 1.2 Scoop 1.3 Definitions, acronyms & Abbreviations 1.4 References 1.5 Document Overview 2. General characteristics 2.1 Introduction 2.2 Product perspective 2.3 Product functions 2.4 User characteristics 2.5 General constraints 2.6 Assumptions & dependencies 3. Specific requirements 3.1 Functional requirements 3.2 External interface requirements 3.3 3.4 3.5 3.6 Performance requirements Design constraints Attributes Other Requirements 7 8 8 8 8 9 9 10 10 10 10 12 12 13 13 13 24 24 25 25 26
Appendix a: Use case diagram Appendix b: Class diagrams Appendix c: User interface diagrams
27 28 29
2010cs048
Page 2
1.
1.1 Purpose
Introduction
Upakara the web based blood donation system is mainly uses for helping the patient who need blood. So this SRS document consists of a simple explanation about the system and its features. The document mainly focuses on providing sufficient design information to the blood bank authorities. And also it will satisfy the functional, design, performance requirements of the system in briefly.
1.2
Scope The main intend of this SRS is to provide a simple description to the blood bank
authorities & system users, about the behavior of the system. And the entire package is consisting of below parts. System software The system will contains a database in order to store all details about the donors as well as doctors. Software documentation A complete document about the software will be given to the blood bank administration in order to future maintenance of the system. Operation Manual A user manual is provided to the system administrator with some simple explanations about the system and its features. User Manual When the donor submits his/her details through internet a simple guidance is also given to the donor.
1.3
Definitions, Acronyms & Abbreviations Upakara WBBDS Database - The name of the web based blood donation system - Web based blood donation system - Consist of all information related to donors & doctors
HC Certificate Health Condition Certificate 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 person who is log into the system
2010cs048 Page 3
1.4
References Appendix A: Use case diagram Appendix B: Class diagrams Appendix C: User Interface Diagrams
1.5
Document Overview The document has 3 major sections. 1. Introduction Overview of the whole SRS document 2. General characteristics A description about the features of the system. Introduction Product perspective Product functions User characteristics General constraints Assumptions & dependencies 3. Specific requirements A description of specific requirements of the system. Functional requirements External interface requirements
Performance requirements Design constraints
Non-functional requirements
Attributes 2010cs048 Page 4
2.
2.1 introduction
General characteristics
Through this section a description is given about the characteristics about the entire system.
2.2
Product perspective WBBDS is mainly towards persons who are willing to donate blood to the
patients. Through this system it will be easier to find a donor for exact blood type and easy to build the connection between donor & the blood bank authorities. The main intend of building this software is to formal the procedure of blood donation & motivate donors in order to donation blood.
The system also consists of some local system hardware devices as well. A printer & SMS indicator are the main devices among the other devices.
The entire software product includes the all relevant features to create a better connection between the blood donor & blood bank authorities.
2.3
Product functions Class of use cases Use cases Login of admin Change password of the admin Register the donor by Use cases related to himself Register the donor by system admin Description Log admin into the system Change login password of the admin of the system Store personal, contact, medical details of donors Store personal, contact, medical details of donors Log donor into the system Change login password of the donor of the system
Page 5
registration of a donor
2010cs048
2010cs048
Page 6
2.5
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 hasnt the internet connection can contribute to the donation through the WBBD system. The donor who uses internet connection will be guided through small & clear descriptions. 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 donors mobile number through counting the number of characters in the entered mobile number System uses the donor registration number & the identity card number to identify each 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 the system in a different manner. The doctor mainly has the connection with the system admin. In donor registration, submission of HC certificates & providing donation details to the system the doctor will connect directly with the system administrator.
2010cs048
Page 7
2.6
Assumptions & dependencies Every donor has a mobile phone. The system doesnt keep the details of 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 the system to the website server hasnt considered as a process inside the system. That process will do by the authorities who are controlling the website. Therefore in here the installation process is considered as a process which is in outside of the scope. A doctor or a patient can request for a exact blood group. But the request comes through blood bank authorities to the system admin. Therefore doctor, patient are not direct users of the system.
3.
3.1
Specific requirements
functional requirements Use case diagrams are used to describe functional requirements of the system. The
diagrams are drawn below. If there is a network failure while a user is working in the system, all login details regarding on user name & password of the user will be removed from the system.
User case related to system authorization Use case 1: Login of admin. Primary actor: System administrator. Pre Condition: Internet connection should be available. Main scenario:
2010cs048 Page 8
Use case 2: Change the login password of admin. Primary actor: System administrator. Pre Condition: Internet connection should be available. Admin logged in. Main scenario: 1. Admin selects the command to change the password. 2. The system is asked to type the current password, new password & again the new password to confirm it. 3. Admin provides the current password, new password & confirm new password. 4. System does authentication. 5. New password is stored in the system. Alternative scenario: 4(a). Authorization fails. 4(a) 1. A message is shown to the admin that the provided current password is wrong. 4(a) 2. Allow the admin to re-enter the current password. 3 chances will be given. 4(b). New password doesnt match with the confirm new password. 4(b) 1. A message is shown to the admin that the provided new password doesnt match with the current new password.
2010cs048 Page 9
7. The system does authentication. 8. The system asks the donor to submit the health condition report & the evidence report of blood group. 9. The donor submits those reports to the system & finishes the registration. 10. The system does authentication. 11. The registration details are sending to blood bank authorities through an e-mail. 12. Authorities approve details & reports. Send the approval to the system admin. 13. Store registration details in the system database. Alert the donor by sending e-mails & SMS messages to the donor about the registration. Send the user name & the password to the donor in order to log into the system. Alternative scenario: 7(a). Donor doesnt provide the answers to some main questions completely. 7(a) 1. A message is shown to the donor that he/she hasnt answered properly. 7(a) 2. Highlight those questions. Allow 3 chances the donor to re-answer those remaining questions. 7(b). Donor has entered an invalid mobile phone number. 7(b) 1. An error message is shown to the donor that the mobile number contains invalid number of characters.
2010cs048 Page 10
Use case 4: Register the donor by system admin. Primary actor: System administrator. Pre Condition: Internet connection should be available. Administrator logged in. Main scenario: 1. Admin select the donor registration command. 2. A small questionnaire is given to the admin which is related to personal & contact details of the donor. 3. Type all details of a donor which is approved by the hospital authorities & goes to next page. 4. System does authentication. 5. The system asks the admin to submit the health condition report & the evidence report of blood group. 6. Admin submits the relevant reports which are approved by the hospital authorities & finishes the registration. 7. System does authentication. 8. Store registration details in the system database. Alert the donor by sending e-mails & SMS messages to the donor about the registration. Send the user name & the password to the donor in order to log into the system. Alternative scenario: 4(a). Admin doesnt provide the answers to some main questions completely. 4(a) 1. A message is shown to the admin that he hasnt answered properly to questions.
2010cs048 Page 11
Use case 5: Login of the donor. Primary actor: Donor. Pre Condition: Internet connection should be available. Main scenario: 1. Log into the official blood bank website. 2. Admin initiates the command to starts the application Upakara - WBBDS 3. System is shown the all features of the system. 4. Selects the Login of a donor command. 5. The system asking for the user name & the password. 6. Donor provides the username & the password. 7. System does authentication. 8. Relevant application relevant to a donor is displayed. Alternative scenario: 7(a). Authorization fails. 7(a) 1. A message is given to the user that the provided password is wrong. 7(a) 2. Allow the admin to re-enter the password. 3 chances will be given.
Use case 6: Change the login password of the donor. Primary actor: Donor. Pre Condition: Internet connection should be available. Donor logged in. Main scenario:
2010cs048 Page 12
Use cases related to change the registration details of donors. Use case 7: Change personal, contact details by the donor himself. Primary actor: Donor. Pre Condition: Internet connection should be available. Donor logged in. Main scenario: 1. Donor initiates the command to edit profile details. 2. The system provides the filled application of the exact donor. 3. Donor changes personal & contact details & finishes. 4. System does authentication. 5. New details will replace the past details & store in the system. Alternative scenario: 4(a). Donor doesnt provide the answers to some main questions completely. 4(a) 1. A message is shown to the donor that he hasnt answered properly to questions. 4(a) 2. Highlight those questions. Allow the donor to re-answer those questions. 4(b). Donor has entered an invalid mobile phone number. 4(b) 1. An error message is shown to the donor that the mobile number contains invalid number of characters.
2010cs048 Page 13
Use case 8: Change personal, contact details by system admin. Primary actor: System administrator. Pre Condition: Internet connection should be available. Admin logged in. Main scenario: 1. System administrator initiates the command to edit profile details of donors. 2. System asks admin to enter the donors registration number & the identity card number. 3. Admin provides the registration number & the identity card number of the donor. 4. System does authentication. 5. The system provides the filled application of the exact donor. 6. Admin changes personal & contact details & finishes. 7. System does authentication. 8. New details will replace the past details & store in the system. Alternative scenario: 4(a). Authorization fails. 4(a) 1. A message is given to the admin that the registration number doesnt match with the id number. 4(a) 2. Allow the admin to re-enter the registration number & the identity number. 3 chances will be given. 7(a). Admin doesnt provide the answers to some main questions completely. 7(a) 1. A message is shown to the admin that he hasnt answered properly to questions. 7(a) 2. Highlight those questions. Allow the admin to re-answer those questions. 7(b). Admin has entered an invalid mobile phone number. 7(b) 1. An error message is shown to the admin that the mobile number contains invalid number of characters.
User case related to withdraw names from the donor list. Use case 9: Withdraw reg. details by the donor. Primary actor: Donor.
2010cs048 Page 14
2. System is shown a message to the donor in order to confirm the decision. 3. Donor confirms the decision. 4. Donor will logged out from the system. 5. Donor will get a thank you note from the system to their mobile phones.
Use case 10: Withdraw reg. details by the admin. Primary actor: System administrator. Pre Condition: Internet connection should be available. Admin logged in. Main scenario: 1. Admin initiates the command to edit donor details. 2. System is shown the sub commands of the edit donor list command. 3. Admin selects the command to remove donor from the system. 4. System asks the registration number & the identity card number of the donor. 5. Admin submits the registration number & the identity card number of the donor. 6. System does authentication. 7. System is shown all details of the donor & system asks to confirm the decision. 8. Admin confirms the decision. 9. All details of that donor are removed from the database. 10. Donor will get a thank you note from the system to their mobile phones. Alternative scenario: 6(a). Authorization fails. 6(a) 1. A message is given to the admin that the registration number doesnt match with the id number. 6(a) 2. Allow the admin to re-enter the registration number & the identity number. 3 chances will be given.
2010cs048
Page 15
Use cases related to replace the older HC certificates. Use case 12: Replace donors HC certificates. Primary actor: System administrator. Pre Condition: Internet connection should be available. Admin logged in. Main scenario: 1. Consider the submission date of the health condition report of those replied donors. 2. The submission date of the HC certificate of those replies donors is older than 5 month. 3. System is shown the names of that kind of donors to the admin.
2010cs048 Page 16
Use cases related to inform blood testing to the donor. Use case 13: Send blood testing details. Primary actor: System administrator. Pre Condition: Internet connection should be available. Admin logged in. Main scenario: 1. Blood bank authorities send blood testing details of donors, to the system admin who is found to be having diseases. 2. Admin store those details with respect to each donor.
3. The admin alerts the relevant donors about disease & sends them the blood testing details through e-mails & SMS messages. 4. Relevant doctors details are also provided by the system administrator to the donor through SMS messages. 5. The names of that kind of donors will remove from the donors list.
Use case related to search access the database. Use case 14: Search relevant details from the database.
2010cs048 Page 17
Use cases related to print statements. Use case 15: Print the list of newly registered donors, donation details & list of removed names as statements. Primary actor: System administrator. Pre Condition: Internet connection should be available. Admin logged in. Main scenario: 1. Admin select the command to print statements. 2. The system is shown a window with relevant commands. 3. The admin selects the details that he wants to print. List of newly registered donors Blood donation details of donors Removed names of donors 4. The system asks for the duration 5. The admin provides the duration & finishes. 6. The system prints relevant statements. Alternative scenario: 5(a). There are no any statements for that exact duration.
2010cs048 Page 18
3.2
external interface requirements The system is basically running on the official website of the govt. blood bank. Mainly
there are 2 actors in the system. The system provides some advance features to the system admin than the donor. If the system admin logs in, the system interface provides some main command buttons to the admin. Change login password. Edit donor profile details. Search Donors for a exact blood group & send messages Print statements. Update the database Send blood testing Details. Search details from the database. If the donor logs in, the system will provide another different interface with different commands. Change login password Edit personal, contact details. Details related to contributions to donation. Future blood donation details. Withdraw name from the system.
3.3
performance requirements 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 for access the database will be no more than 5 seconds.
2010cs048
Page 19
Reliability The system has the ability to work all the time without failures apart from network failure. The donor can have the faith on the system. The authorities will keep the privacy of all donors in a proper manner. When doctors found any disease in the testing stage after providing relevant details to the donor the system keeps the secretively of the donor. Portability As mentioned earlier the system is working on the official website of the blood bank. Therefore if a donor uses different operating system (Linux, Windows) or different web browser, after logging into the system, the system will show the all features in it. Modularity The system mainly consists of many parts. SMS indicating part is the largest part of all. In that section the system interact with the indicating device. Ultimately however the system manages to combine all parts of the system & work as a large system.
Interoperability In here the system Upakara will run on the blood bank website. Therefore the system includes the ability to work with the other applications which are also run on the same website.
2010cs048 Page 20
3.6
OTHER requirements Security This system doesnt have a tight security system. Because people who log into the system are volunteers who like to donate blood for innocent patients. But the system consists of some security features. o Any donor cannot see any detail of any other donor. o If a donor doesnt manage to provide his user name & the password in 3 times the user automatically will log out from the website.
2010cs048
Page 21
System Authorization
Donor Registration
Inform Blood Donation Details System Administrator Replace HC Certificates Blood Donor
Print Statements
- Figure -1
2010cs048
Page 22
User -User_Name -Password -Database_ID +Login() +Change_Password() +Donor_ Registration() +Chage_Reg_Details() +Withdraw_Donor() * * * System_Administrator -Database_ID +Print_Reports() +Search_Donors() +Replace_HC_Certificates() +Inform_Blood_Testing_Details() +Search_Database_Details()
* Donor -Reg_Number -Blood_Group -ID_Number -Mobile_Phone_Number -E-mail_Address -Database_ID +Future_Donation_Details() +Donation_Contribution_Details() +Edit_Profile()
Database_Acess -Database_ID +Acess_Database() +Store_Details() +Remove_Details() Donation -Blood_Group -Donation_Date -Donation_Venue -Donation_Starting_Time -Database_ID +Future_Donation_Details() +Search_Blood_Donors() +Send_Donation_Request()
Alert -Alert_Type +Clarify_Alert() +Display_Alert_Details() * * SMS_Alert -Mobile_Phone_Number -Database_ID +Send_SMS_&_Save() +Read_SMS_&_Save() * Email_Alert -Email_Address -Database_ID +Send_Email_&_Save() +Read_Email_&_Save()
- Figure -2
2010cs048
Page 23
Upakara
Main Features
Change Password Edit Donor Profile Details Search Donors & send messages Print Statements
Update the Database Send Blood Testing Setails Search from the Database
Log Out
of the system
Upakara
Change Password
N.P.S.S.Manorathna
User Name 2010cs048
Reg Date 2011.05.29 T.P No 071 2112684
Main Features
Change Password Edit Personal, Contact Details
OK
of the system
Page 24
Upakara
Registration of a Donor
Registration of a Donor Name in full Date of Birth 1990 November 23 V Age 21
National Identity Number Blood Group Gender Province Address O+ Male Western
Next Page
of the system
Upakara
Registration of a Donor
Registration of a Donor Submit the health condition cretificate Brows.. A acceptance of a authorized doctor is needed
Finish Submission
- Figure 6- The user interface related to Registration of a new donor page 2 of the system
2010cs048 Page 25