1. DILLA UNIVERSITY
COLLEGE OF ENGINEERING
AND TECHNOLOGY
SCHOOL OF COMPUTING
AND INFORMATICS
DEPARTMENT OF COMPUTER
SCIENCE
PROJECT TITLE: WED-BASEDONLINE BLOOD BANK MANAGEMENT SYSTEM
PROJECT DONE BY: SECTION 2
GROUP MEMBERS ID NO
1. ZEKARIYAS ALEMU______________________________________________ 7703/19
2. TOLESA TARIKU_________________________________________________ 3824/18
3. ZEWDU FEREDE__________________________________________________ 5742/19
4. TADELE DEMELASH______________________________________________ 9208/19
5. TESHOME ANAGAW______________________________________________ 2611/19
COURSE TITLE: - SOFTWARE ENGINEERING
COURSE CODE: - COSC3061
INSTRUCTOR NAME: - HIWOT W.
SUBMET DATE MAY 13/06/2014
DILLA ETHIOPIA
2. 1 | P a g e
Contents
Chapter 1 introduction…………………………………………………………………………………………………………….2
1.1 Background…………………………………………………………………………………………………………………………2
1.2 Statement of the Problem ......................................................................................................4
1.3 Objective .................................................................................................................................5
1.4 Scope and Limitations..............................................................................................................6
1.4.1 Scope.....................................................................................................................................6
1.4.2 Limitations.............................................................................................................................6
1.5 Methodology............................................................................................................................7
1.5.1 Data gathering methodology ................................................................................................7
1.5.2 System Analysis and Design Methodology ...........................................................................7
1.5.3 System Development Model.................................................................................................8
1.5.4 Implementation Methodology..............................................................................................8
1.5.5 Development Environment and Programming Tools ...........................................................9
1.6 Feasibility study................................................ .....................................................................10
1.6.1 Technical Feasibility ............................................................................................................10
1.6.2 Operational Feasibility ........................................................................................................10
1.6.3 Economic Feasibility............................................................................................................11
1.6.4 Other Feasibility…………........................................................................................................11
1.7 The Significance of the Project…………………………………………....................................................11
1.8 Organization of the rest of the document………………………………………………………………………….13
Chapter 2: Existing system...........................................................................................................15
2.1 Introduction ...........................................................................................................................15
2.2 Description of the existing system.........................................................................................15
2.3 Forms and Other Documents of the Existing Systems ……………………………………………………….16
2.4 Model of the Existing system.................................................................................................16
2.5 Business Rule .........................................................................................................................17
2.6 Limitation of the Existing System...........................................................................................18
Chapter 3: Proposed system....................................................................................................... 19
3.1 Overview of the proposed system.........................................................................................19
3.2 Requirement specification......................................................................................................19
3.3 User interface specification and description ........................................................................ 26
4.1 Chapter 4: System Modeling.................................................................................................28
4.2 Functional model (Use case diagram and description) ..........................................................28
4.3 Dynamic Model.......................................................................................................................42
4.4.1 Sequence Diagram ..............................................................................................................42
4.4.2 Activity Diagram...................................................................................................................46
4.4.3 State Chart Diagram.............................................................................................................52
4.4 Object Model (using class diagram) .......................................................................................54
4.5 User Interface Flow Diagram .................................................................................................55
3. 2 | P a g e
Chapter 1
1. Introduction
Management is one of the difficult and complex works around the
world. Every organization needs talent management system to facilitate the
work and achieve the goals of that institute specially to manage resource and
personal activities it needs to use the computerized system as well, due to this,
The Blood Management System is to create an e-Information about the
donor and organization that are related to donating a blood. Through
this application any person who is interested in donating a blood can
register himself in the same way if any organization wants to register
itself with this site that can also register. Moreover, if any general
consumer wants to make request blood online, he can also take the
help of this site. Admin is the main authority who can do addition,
deletion, and modification if required.
1.1 BACKGROUND
Blood is a specialized body fluid in humans that delivers
necessary substance such as nutrients and oxygen to the cell and
transport metabolic waste product away from cells. Human blood is an
element of human life. The national blood bank service of Ethiopia’s
(NBBS) was established in 1969 by Ethiopian Red Cross society but
since 2004 has been known by the federal ministry of health Ethiopia.
Its main center is located in Addis Ababa and it has also the
responsibility to oversee, support and monitor the activities of regional
blood bank in the country which are administratively under their
respective regional health bureaus. The national blood bank service of
4. 3 | P a g e
Ethiopia (NBBS) mission is to ensure the availability of safe and
adequate supply of blood and blood products to all transfusion health
facility in Ethiopia. The NBBS office is non-profit governmental
organization established with core community mobilization and
education on voluntary blood donation, blood collection laboratory
processing, testing and production of blood.
Blood bank is one of the important departments. It plays an important
role with blood collection and issue of blood components. Its activities
include blood donation, blood grouping, antibody screening, antibody
identification, blood infectious test, issuing compatible blood and blood
component etc. Ethiopian Blood Bank is one of these and it was
established by the Red Cross association this organization provide
blood for 10 seekers and 3 clinics. These clinic and seekers received
blood by fulfilling certain forms and getting permission from Lab
technician. The organization passed several obstacles in case of creating
awareness and also during the starting stage there is lack of blood and
impossible to give the required service. This organization was begun by
giving small capacity of blood service. The aim of the organization is to
provide efficient service to user increase the capacity of providing blood
to the recipient, to increase the number of blood donor by creating
awareness about blood donation to the society.
Background of our Project
Has already manual system which is needed many things those are materials
and workers with takes long period of time. The system is done the activities by
paper each and every thing.
5. 4 | P a g e
1.2 STATEMENT OF THE PROBLEM
Today in the 21st
century every activity is done by the help of
computerized system or automated system, In the current system the
activities such as documenting, finding and searching of specific information
is done manually. Employee cannot perform their activity like, donor
registration. Because of the absence of permanent storage or central DB that
each process or workflow cannot traced from database, it is hard to give
Feedback about blood bank service, it is tedious for blood seeker to search
the required blood type in case of emergency, lack of smooth interaction
between donor and blood bank, lack of security, Difficult to know amount of
blood in stock, Error handling is not efficient, Difficult to know fit blood
during blood transfusion service, difficult to prepare organized report,
difficult to prepare organized report and it is difficult to see the availability
blood in the stock. This type of system leads to the documenting of erroneous
and redundant information. The current system consumed the time and cost
of user even to complete specific task. The medium used to inform the staff
about the schedule of the month using whiteboard and written whiteboard
marker, these leads the written schedule become unclear.
Generally, we will face these problems if we use the manual system
Time
The existing system is totally done by manual system to Manage Blood
Donation and Requests. so, the system takes more time, tedious and complicated to
run it for the Donator’s, the Hospital which Request a Blood and For The workers
inside Blood Bank Institute.
Resource
6. 5 | P a g e
It needs high energy or human powers to do the activity around the
blood management system or to reduce the human power we must be
automate the system. In addition to this it requires much more resource like
paper, pen, printer-color etc.
Loss of Data
When the paper in which all the data had been recorded is lost all the data
recorded on that paper is destroyed or loss. Finally, the Blood Donators’ and
Receivers cannot get relevant data they want. Generally, the Blood donator and
Receiver files are encircled endanger of data lose because it has not any
computerized or moderate system to keep the data lost.
So, because of these and other problem we are initiated to do this project.
1.3 OBJECTIVE
In this section we discuss about the objective that we went to accomplish at
the end of this project.
1.3.1 General Objective
The main objective of this project is to change the manual system of
Ethiopian blood bank into computerized system.
1.3.2 Specific Objective
7. 6 | P a g e
To achieve the general objective mentioned above we should consider the
following specific objectives:
Analyzing the current manual system.
Implementing the proposed new system
Design interactive user interfaces for the Ethiopian blood bank management
system to users.
Testing the new system and make the required modification.
1.4 Scope and Limitations
1.4.1 Scope
The scope of this project only lies within the time frame given to us at
the current moment. So, our project scope is
Create account for users.
Post and retrieve general report.
The administrator sends message to donor when the time they
donate blood is reached.
Advertising the organization service.
Show available blood online with their type.
Provide secured and authorized feature to the system where
private and confidential data can only be viewed and updated by
authorized user.
Facilitate or improve the information shared between the user and
the organization.
User can provide Feedback to the organization about the service
they provide.
Avoiding redundant and erroneous data.
Record blood details and blood donation.
Manage the collected blood data.
Record blood details with their expired date.
8. 7 | P a g e
1.4.2 Limitations
Our project has the following limitation:
Our project is limited on the allocated time
The skill needed for this new project is a little bit not enough
1.5 Methodology
In this section we are going to discuss about system development
methodology that we follow to develop our system and the method we used
to collect data.
1.5.1 Data gathering methodology
The method we employed in the data collection are observation, analysis
of document that is directly related with this blood bank organization also we
have used Google search.
1.5.1.1 Observation
Is one of the data collection methods and all the team members are
tried to observe and understand the actual workflow or event performed in
the current system. During observation we saw many papers and document
that store the information and also, we saw that different notification posted
on the notice board in the blood bank.
1.5.1.2 Document Analysis
Another way that we used to collect data is document analysis. We read
written documents which are the existing system currently uses, to know
rules, regulation and constraints in the existing system that can be used to
design the new system.
1.5.2 System Analysis and Design Methodology
In this project the team members decide to use object-oriented system
analysis and design to develop our system because of the following reason:
9. 8 | P a g e
It can be easily maintained
It supports the design and representation of the system using UML
diagram like, use case, sequence and activities.
It allows to break down complicated system into smaller, clear
and more manageable part;
Increase extensibility: means make modification on some part of
the code will not affect the other.
It facilitates change in the system at low cost
Increase reuse of component: - the object oriented provides
opportunities for reuse of code or component through the concepts
of inheritance, polymorphism, and encapsulation.
Fastest development
Increase quality
It makes our system more usable and more productive
1.5.3 System Development Model
One of the approaches in object-oriented technique that we used to
develop our system is Iterative System Development Model. Because it
used as fast development and delivery of high-quality system at relatively
low cost. We improve the sub system until the complete version is reached.
1.5.4 Implementation Methodology
The number of persons who are in need of blood are increasing in
large number day by day. In order to help people who are in need of
blood,
Our Online Blood Bank can be used effectively for getting the
details of blood donors having the same blood group and within the
same city. With the help of Our Online Blood Bank people who are
having the thought of donating blood gets registered in Our Online
Blood Bank giving his total details.
Our Online Blood Bank site is available to everyone easily. A
person who likes to donate blood gives his entire details i.e., fill in the
registration form and can create a username with a password by
10. 9 | P a g e
which he can modify his details if at all there are any changes in his
information given before.
Our site also helps people who are in need of blood by giving the
details of the donors by searching, if at all there are no donors having
the same group and within their own city, they will be given the
addresses with phone numbers of some contact persons in major
cities who represent a club or an organization with free of cost. If at all
the people find any difficulty in getting blood from the contact persons
we will give them a Mobile Link i.e., Ethiopia’s Largest Paging Service
number through which they can give the message on every one’s
pager with the blood group and city they are living in, such that the
donors who view the messages in their pagers having the same blood
group and the in the same city, he contacts the person on phone who
are in need of a blood. Such that the person gets help from us which
saves his life.
1.5.5 Development Environment and Programming
Tools
To develop our system, we are going to use different tools to
develop the web-based system:
Hardware Tools
Personal computer (PC): - For every activity of the project.
Flash disc: - to store files.
Digital camera: - to capture pictures which are necessary for
developing the website.
Printer: - to print the document
Software Tools
Adobe Photoshop: - to edit pictures.
Microsoft office word 2019: - to prepare the documentation.
Edraw-max: - to draw Gantt chart and other software diagrams in
design phase.
11. 10 | P a g e
PhpMyAdmin: - to view data for a website that store in the
database server.
MySQL: -used to manage database
Web browser: - to search reference and to execute the
implementation.
Snipping tool: - to cut and save some required parts of a web
page and diagrams.
CSS: -used to styling layout
HTML and java script: -used front end or client-side coding
PHP: -for server-side scripting
1.6 Feasibility Study
The feasibility our project can be examined based on different categories:
Technical Feasibility
Operational Feasibility
Economic Feasibility
Legal feasibility
1.6.1 Technical Feasibility
The proposed system can be easily maintained and repaired.
Technically, the system will be Powerful to be applied by low skilled users as
much as possible. There is no need for the developer involvement in almost
all implementation of the entire system. It is easily accessible by the people
who have basic computer knowledge.
1.6.2 Operational Feasibility
The proposed system will provide best services for user and it will be
highly secure. The system will also be on behalf of origination’s goal and
user satisfaction, because the system will have good user interface and easily
interact with it. Our system will be compatible with the requirement of the
organizations. The user is serviced at their place of work. So, operationally
feasible or it will be operationally acceptable by users.
12. 11 | P a g e
1.6.3 Economical Feasibility
As cost/benefit analysis, show the new system is developed using
minimum cost and it give a lot of benefits such as advancing the services of
the system, decreasing the work load of the users. The organization does not
use any media advertises because it makes information online and every one
can get the information from the site.
The proposed web-based blood bank management system is economically
feasible because:
The system requires very less human power.
The system will provide fast and efficient automated
environment.
The system will have excellent and easily understand user interface and
very less user training is required to learn it. The cost of the proposed system
is almost negligible when compared to the benefits gained.
1.6.4 Legal Feasibility
The proposed system has no any conflict with any government directives,
because it gives Services for the people effectively and efficiently and the
system is politically feasible.
1.7 The Significance of the Project Who will benefit
from the system?
The existing system is not computerized rather it is manual. So, the web-
based system is playing an important role by simplifying the complicated
work.
The main benefits of this system as it is computerized web-based system:
It saves the user’s time to search the required blood.
The Blood donors can register using the system without going to
the blood bank
It decreases employee effort required to do their task properly.
It attracts blood donors to join and register under the system.
Introduces the blood bank to technology and also facilitates
technology throughout the coverage area, as it is web-based system.
13. 12 | P a g e
Since it is interactive system, many users join into the system.
Generates more secured information and reduce redundancy.
It makes smooth relation between the blood bank and their user.
Generates and improves socio economic change to the society.
Faster decision making by searching records from database.
Increase security by providing authorized user can only access the
organizational service.
Who will benefit from the system?
1. Blood Donor’s
It provides the unique identification number easily at the time of blood
donation which helps the user for future correspondence.
Donors can view the blood donation place organizing at different time.
Donor can make registration online.
Donor can check the status of particular blood group.
2. Blood Seeker’s (seekers and clinic)
Blood seeker can get the information of the desired blood group.
Blood seeker can see available blood on the database.
Seeker can save money, time and effort.
3. Blood Bank Organization
It helps to rid the manual system.
The occurrence of error should be decreased.
Information retrieval should be precise and effective.
Report about donor and seeker can be generated easily.
4. Project Team Members
While developing the system
Developer team will be increasing their knowledge skill and can
have good awareness for developing web-based system
The developer’s team has a potential to solve problem.
14. 13 | P a g e
1.8 Organization of the Rest of the Document
we have now completed chapter one basic points which are crucial for
our system. And in the next chapter we will describe about the existing
system which is the current manual system; about its implementations, how it
is done from donation to store and even to how it is delivered to blood
seekers in hospitals and clinics, and the limitations and the problems arise
from it. In chapter 3 we will discuss about the proposed system which is our
system based on the limitations and problems seen and gathered from the
worker’s, blood donators and seekers by different data gathering
methodologies and having that we can decide what shall we will do to
overcome these limitations and problems, in what software and hardware
environments can work our project, and other’s regarding to these ideas.
In our last chapter we will see different UML diagrams that describe all
about our system in a diagrammatic description way. Which is important to
us to manage the all in all project activities easily; and if someone in the
developer’s team can not proceed because different reasons this chapter will
be useful for the new coming developer to easily understand the proposed
system quickly and proceed with the remaining team members without any
confusions left.
so, our schedule will be like this using Gant chart
16. 15 | P a g e
Chapter 2 Existing System
2.1 Introduction
In this chapter we will see abut the existing system for blood
bank management which is all in all manual system. We will discus
how a donor can donate his blood and how the management staffs in
the system interact with it, we also discus what are the limitations of
this system in which a base for our new web-based project clearly and
briefly as much as we can.
2.2 Description of the Existing Project
As we described in the first chapter, we used observation together the
information required in the current system so based on the above data
Collection techniques. We study the background of the organization.
Generally, the overall activities of existing system the donor goes to the
blood bank and reach to the receptionist nurse then nurse ask some questions
about her/his willingness and motivate to full fill questioners. Then the donor
goes to Nurse to donate blood, while nurse test about his/her healthiness (i.e.,
weight, blood pressure etc.), donor gets counseling and refreshment. If the
donor healthy the nurse receive blood. After donation the donor, get some
advice.
The nurse transferred blood to the laboratory class to check by the lab
technician about his/her blood type (A, B, AB, O etc.), blood purity (hepatitis
A, B, HIV and syphilis). if the blood is pure stored in stock otherwise
discarded. If the donor wants to know about his/her blood, profile gets from
lab technician. Then the lab technician transfer donor’s profile report to data
encoder.
17. 16 | P a g e
When the client hospital (seeker) wants blood, they get blood from lab
technicians.
2.3 Form and Other Documents
This the form that we get for blood doner to Donation
2.4 Models of Existing System
Users are entities that interact with the system. It concerns only in Blood
Bank management system in Ethiopia. There are many basic beneficiaries
which can get benefits from the Ethiopian blood bank Services. Which are
Blood Donors: person who wants to donate the blood voluntarily at the
blood donation camp.
18. 17 | P a g e
Blood Seekers: An Organization who wants the blood from the blood
bank due to various reasons like accidents, surgeries, delivery and
many more.
Blood bank: staff people, who are working in the blood bank, which
includes staff member, operator, blood bank in charge, head of
pathological department.
Nurses: -check donor healthiness and received blood.
Manager: -managing, supervising, budget all of action for the overall
activity of the system.
Lab Technician: -test blood, give blood for client hospitals and
manage the sock.
Data Encoder: - Register all the donor profile and send report for
manager.
The Receptionist-Nurse Register blood donors give pre donation
information and motivate donors to full fill questionnaires
2.5 Business Rules
A business rule is effectively an operating principle or polices that must
be fulfilled and obligated in order the system will function properly and
effectively.
The Blood Bank’s core functions include blood collection, blood
grouping, infectious testing, component preparation, and blood components
disposition. Currently, all the data and information exchange and processing
of the functions of Blood bank is done manually. Only Access Database is
used to keep records of donor’s, Recipient’s, and hospital’s information in the
current system. Information is highly exposed to error, incompleteness, lose
as well as damage.
Generally, the following business rules (BR) are used in the project: -
BR 1: Donors must be at least 18 years old or at most 65
years old
BR 2: If donor have desire to "give back", he/she can be donating
his/her blood to the community in every 3 Months.
19. 18 | P a g e
BR 3: No donation if the Donor have any disease and not in
proper health condition.
BR 4: The blood in the bloodstock is expired after 35 days.
BR 5: If donor has a temperature above 37.5 C, donor may
not donate.
BR 6: Persons who is pregnant is not eligible to donate wait 6
weeks after giving birth.
BR 7: Donors should not give blood if they have AIDS or have
ever had a positive HIV test.
BR 8: If donor had hepatitis, donors are not eligible to donate
blood.
BR 9: If weight of donor is between (45-50) kg can donate blood
up to 350ml and if greater than 50kg can give 450ml at a time.
Therefore, BR1, BR2, BR3, BR4, are used in the proposed
system the rest are used in existing system.
2.6 Limitations of The Existing System
From the requirement gathering process performed so far, we can get the
information how the current system works, the problem of the current system,
the requirement of the organization and the requirement of the user. The
information gathered here also helps us to specify our system requirement
and used as an input for the development of our project.
The following results are found while gathering requirements regarding the
problem of the current system:
The lab technician said that searching information, storing donors and
seekers file is very difficult because the file is stored on paper.
The Nurse said that collecting blood, register donation, telling the place
of donation to donor is very difficult.
20. 19 | P a g e
The admin said that generating report is difficult because of lack of
organized data.
The donor said that knowing the place where donation takes place is
difficult and they do not even know where the nearby station is. So,
even if they want to donate their blood, they can’t.
Based on the analysis investigated so far, the problems of the
existing systems are stated.
Use more professional’s human power for more awareness on
community as a result there will be a spaced out on
organization service.
Because of the lack of Budget, they do not use any
advertisements like TV, radio or magazine.
They only decide when and where the reservation for blood
donation can behold.
It is time consuming Difficulty in Maintenance of Records
It leads to error prone results
there is high data Redundancy and data Inconsistency.
Editing of data becomes a tedious job.
It lacks of data security, Percentage of accuracy is less.
21. 20 | P a g e
Chapter 3 Proposed System
To avoid all problems existing in the blood bank and make the
operations and activities more accurate, the system needs to be
computerized and should perform some of the activities online. The aim
of this project is to develop improved system that can overcome all the
problems of the existing system. The system provides proper security
and reduces a wide range of manual work. Our proposed system is focus
on user satisfaction and increase the efficiency of works in the
organization.
3.1 Overview of the Proposed of System
In Ethiopian blood bank there is no any computerized system used
before. All activities are performed manually and no any central database so,
user information is stored on paper. After analyzing all the current system,
we are proposed to do a system that simplify the activities performed in the
current system. Using our system donor can register within their home. The
blood seeker can see available blood in stock without going to the blood
bank. If there is blood compatible to their need they can go and get blood if
the required blood cannot available in the blood stock using this system, they
can see possible donor and contact with them and get blood. The admin
register blood seeker, delete user account, generates report, post information
etc.
In General, our proposed system has the properties like better
utilization of resources, good performance, high security, reliability,
accuracy and give better service. The new system is aimed to perform
basic and crucial tasks of the blood bank. It contains a well-organized
database which makes data to retrieve, update easily.
22. 21 | P a g e
3.2 Requirement Specification
The purpose of System Requirements Analysis is to obtain a thorough
and detailed understanding of the business need as defined in Project
Origination and captured in the Business Case, and to break it down into
discrete requirements, which are then clearly defined, reviewed and agreed
upon with the Customer Decision-Makers. During System Requirements
Analysis, the framework for the web-page is developed, providing the
foundation for all future design and development efforts.
Systems Requirement Analysis gives the professional systems engineer
the tools to set up a proper and effective analysis of the resources, schedules
and parts that will be needed in order to successfully undertake and complete
any large, complex project.
3.2.1 Functional Requirements
These are the statement of service that the system should provide. It explains
how the system should react to particular input and how the system should
behave in a particular situation. Functional requirement captures the intended
behavior of the system.
The system provides the following basic functionality: -
1. Advertisement and announcement: The system to promoting about
the organization what is their services, how they treat customers and others.
Like other advertising media, it frequently involves a publisher, who
integrates advertisements into its online content and users of the system who
has an account can be visited published information through internet access.
2. Member signup and staff member registration: This BBMS allows
the users to store his/her details in to the system to gain the system services.
23. 22 | P a g e
3. Online appointment: The system allows to public can make online
reservation on their desired session and date. The blood centers'
administrators can then manage their appointments.
4. Blood request and Cross matching: BBMS allows the user to request
for blood and blood transfusion for which the cross matching using the
appropriate technique can be carried out and the results can further be
processed and analyzed by the experts to issue the blood. In addition, various
reports for blood requisition and the cross matching can be generated at run
time.
5. Searching functionality: functionality in order to allow normal and
privileged users to search the details of a given user to permit or prevent
access.
6. No installation: As it is a website, it prevents users from any kind of
hindrances faced during installation or up-gradation of application. User
simply needs a browser to access the website.
7. Retrieving Report: Various comprehensive reports can be retrieved any
time by the end user to measure the performance parameters in the blood
bank and to analyses the user and other aspects in blood bank.
Generally, the proposed system is design to do the
following functionalities:
RQ1: The system should allow the users or donor to create account.
RQ2: The system should allow the user to send request for blood.
RQ3: The system should allow the user to give Feedback and view
information.
RQ4: The system should allow to the Lab technician to register blood
RQ5: The system should allow the administrator to generate report and
advertisement.
RQ6: The system should allow the administrator to view Feedback.
RQ7: The system should allow the administrators to register blood
seeker.
RQ8: The system should allow the Nurse to register donation.
RQ9: The system should allow the seeker to search the required blood
online.
24. 23 | P a g e
RQ10: The system should allow the user to update and change their
profile.
RQ11: Register and Keep record of donors and seeker in the database
is possible.
3.2.2 Non- Functional Requirements
Non-functional requirement describes visible aspects of the system that
are not directly related to the system. Non-functional requirement deals with
additional quality of the system such as performance, cost benefits,
documentation, new information preserving and security matter.
Non-functional requirement of the system deals with how well the system
provides service to the user
The following are the non-functional requirements associated
with the new system:
3.2.2.1 User interface and human factor
The user interface for the proposed system is very interactive, easily
understandable. The user interface of the proposed system is directly related
with the system functionality. So, the user need not have extra knowledge to
use the system.
3.2.2.2 Documentation
Documentation will help the project team to have basic knowledge and also
used for users to guide how to operate the system. Therefore, it is a necessary
requirement and it helps for maintenance purpose. This documentation
includes proposal, project report, and final document.
3.2.2.3 Hardware consideration
The system may use different operating systems like window 7 and window 8
and window 10. The hard ware required to run the system are network cable,
laptop and desktop computer or tablet with capability of connecting to the
internet and provide connection to the system.
3.2.2.4 Performance characteristics
25. 24 | P a g e
Response Time: The output should be generated within a
maximum of 3 seconds depending on the performance of the
computer device.
The proposed system should provide all service that is essential
for the user.
Many users can use the system concurrently.
3.2.2.5 Error handling and extreme condition
Incorrect input: the system handles many exceptions like
inserting empty string to the database and inserting alphabetic
value in integer text field and displays an appropriate message for
each error.
Login error: the system shall handle an attempt to login with
incorrect username and password and display appropriate
message.
3.2.2.6 Quality Issue
Since the system to be developed is web based and used different latest
software when it will develop, the system should give a fast and efficient
service to all users. Adaptability, availability, flexibility, and reliability are
the key issues of this requirement. Use suitable software and hardware to
develop system, will able to achieve this requirement.
Availability: The system, which is called web-based blood
bank management system for Ethiopia, is available all the
time if internet connection is reliable.
Security: The project allows only authorized user to login
into the system and Sensitive data is accessed and changed
by authorized body (i.e., we use password encryption
method).
Usability: The system will be easy to be used by all People
who can read and write in English language.
Performance: The system performs its task efficiently and
effectively because the team project will use advanced
programing language, a smaller number of iterations for a
given task and optimized query to develop the system.
26. 25 | P a g e
Modifiability: the authorized body can modify the system
easily; since the system is developed with user-friendly
programming language, which is PHP.
No Redundancy: - The proposed system can be avoided
repetition of data anywhere in the database.
3.2.2.7 System modification
As technology is capable of change from time to time there will be
future change to the system as new technology is invent. Therefore,
the system can be upgrade to the new technology by maintainer or
the systems developers.
3.2.2.8 Physical environment
This BBMS is affected by weather condition when the hardware
and software available for our system may be crash. The system is
affected by weather conditions like earthquake and electronic
shock.
3.2.2.9 Security issues
We are going to develop a secured database. There are different
categories of users namely Administrator, Nurse, Lab technician, Donor
who will be viewing either all or some specific information from the
database. Depending upon the category of user the access rights are
decided. It means if the user is an administrator, then he can be able to
modify the data, Update etc. All other users only have the rights to retrieve
the information about database.
the system shall provide high level of security by blocking
anyone to view system secured page.
The external security should be provided by given the login
authentication.
3.2.2.10 Resource issue
Server
Apache Web Server
Minimum hardware requirements for Apache server are:
CPU: 32 bit or 64 bits
Cores: single (single core 2Hz or higher
dual core 2GHz or higher is recommended).
Display resolution: 1360X768(or higher).
27. 26 | P a g e
Client:
CPU: 64 bits
RAM: 512 Mb or higher
Editor
Visual Studio code 2017(for coding)
Adobe Photoshop (for editing an image)
3.3 User Interface Specification and Description
Voluntary User
Anybody can use this BBMS to Donate as well as who need blood e.g.,
Public Hospitals, Blood Banks, etc.
Login Interface
User should enter the valid username and password to get access to its
profile.
Donor Profile
User will be able to see its Account No. The receipts of the blood donated
to the bank, Donation to the Bank, Need of the Blood to the Bank and
Request for Blood.
Blood Stock Management
It will show the Blood Detailed of the specific bottle with its Full Donor
Detail or Account No. if he/she is registered to the Bank.
Report
It will be available on the Admin’s Profile and will show the Availability of
the Blood Groups with its no of available bottle as per admin’s choice to
view their port as Month, Day, or Year.
Operating Environment
28. 27 | P a g e
Operating system: Windows
Intel P4 1.5GHz or above.
512MB ram.
80GB HDD Minimum.
System Owner: The Blood Bank
System Users: has full privilege on the system's functions
Administrators: has full privilege on the system's functions
Public: can view the blood donation events and donate or can make
requests for donation (Donor and Recipients fall under this category).
GUI will be only on English
End User’s will not be able to get the information about the availability of
the
blood in the bank of which he/she donated.
Types of packs
To provide pure blood with no wastages blood is been collected in different.
They are double, triple, and triple (AS), quadruple pack.
Blood bank
To provide an efficient donor and blood stock management functions to the
by recording the donor and blood details.
blood bank staffs
To improve the efficiency of blood stock management by alerting the blood
bank staffs when the blood quantity is below its par level or when the blood
stock has expired.
29. 28 | P a g e
Chapter 4 System Modeling
4.1 Introduction
In this section we are going to see about use case diagram, description
of use case diagram and activity diagram this helps to know the functional
interaction between user and the system. Use cases are drawn by examining
the actors and defining what the actor will be able to do with the system.
4.2 Functional Model (Use case diagram and
description)
Scenario Name: Login
Participating actor: Admin, Nurse, Lab technician, Donor, Seeker
Event: User Log-In
User select Log-In and system displays login form. Then user
enters username and password the system checks whether the
username and Password is valid. If it’s valid user log into the
system and the system displays all available operations. If the
entered values are incorrect error message is displayed.
Scenario Name: Manage Account
Participating actor: Admin, Donor
Event 1: Event: Create account
Admin and Donor log in to the system with user name and
password. Then select create account link then the system
Prompts account form. The Admin and Donor fill the form and
submit the form. System validates the filled form and display
account created successfully if it is correct or error message if it
is incorrect.
Event 2: Update account
Admin and Donor log in to the system with username and
password and then select update account link system display
select the parameters you want to update. Admin and Donor
select parameter. The system display enters new value then
30. 29 | P a g e
Admin and Donor enter the value and click on update button.
Then system validates the entry and display the value is updated
successfully if it is correct or error message if it is incorrect.
Scenario Name: View
Participating actor: Seeker, Admin, Nurse, Donor, Lab technician
Event 1: View blood request
Lab technician log into system with password and user name and
select view link then system displays View feedback, View blood
request then select View blood request link after that system
displays Donor’s and seeker’s request.
Event 2: View Feedback
Admin, Nurse and Lab technician log into system with password
and user name and then select view link system displays View
Feedback, View Request link then select View Feedback link
system displays donor’s and seeker’s Feedback.
Event 3: View Report
First the Lab technician and Nurse must login into the system and
the system display Lab technician and Nurse page then Lab
technician and Nurse select view report menu the system display
view report form and Lab technician and Nurse enters report date
and select submit button then the system displays viewed report
message.
Scenario Name: Registration
Participating actor: Admin, Donor
Event1: Seeker registration
First the admin must login into the system and the system
displays admin page then admin select seeker registration menu
and the system display registration form when the admin fills the
form and select register button, then the system display seeker
successfully registered message.
Event2: Donor registration
First Donor must login into the system and system display Donor
page, the Donor select donor registration link and the system
display registration form then Donor fill required information, the
31. 30 | P a g e
system check the filled information and if it is correct, it
generates successfully registered message.
Scenario Name: Request
A use case diagram is helpful in visualizing the context of a
system and the boundaries of the system’s behavior. Each use
cases in the use case diagram can also be described using a
narrative form.
Participating actor Nurse and Seeker
Event1: Donation request
First Nurse login into the system and the system display donor
page, Nurse select donation request link and the system display
donation request form the Nurse fill the donation request form
and select send button then the system generate successfully send
message.
Event2: Blood request
First the seeker must login into the system and system display
seeker page, seeker select blood request link and the system
display request form and seeker fill request form and select send
button then the system generates your request is successfully sent
message.
Scenario Name: Approve
Participating actor: Lab technician, Nurse
Event: Approve
First the Lab technician and Nurse must login into the system and
the system display Lab technician and Nurse Page then Lab
technician and Nurse select approve request menu and the system
display requested information and check the requested
information and if it is correct the system generate successfully
approved message.
Scenario name: Give
Participating actor: Donor, Seeker
Event: Give Feedback
32. 31 | P a g e
The system display user page and the user select Feedback link.
Then the system displays the contact us page with feedback form,
when the user or the visitor fill the required field and select
submit button, system display thanks for your Feedback message.
Scenario Name: Send
Participating actor Nurse and seeker or seeker, Admin
Event 1: Send Request
Nurse and seeker log in to the system and click on send menu
then system displays the request and feedback link Nurse and
seeker then select request link and writes the request and then
clicks on send. If it is correct system display your request has
been sent message. Otherwise try again message will be
displayed.
Event 2: Send Message
Admin login to the system and select send message link. Then
system displays send message form. After that admin writes the
message and click on submit button. then system displays
message sent correctly. Otherwise please try again message will
be displayed.
Scenario Name: Logout
Participating actor: Admin, Nurse, Donor, Seeker, Lab
technician
Event: Logout
User click on logout menu then the system display login form.
A Use Case represents a discrete unit of interaction between a user and
the system. A use case diagram contains four components.
1. Boundary: -which defines the system of interest in relation to the
world around it.
2. Actors: -usually individuals involved with the system defined
according to their roles.
3. Use cases: -which the specific roles are played by the actors within
and around the system.
33. 32 | P a g e
4. The relationships between the actors and the use cases as depicted
in the following figure.
Figure Use Case Diagram for Blood Bank Management System
Description of the Use Case Model
The following consecutive tables show the use case description for each
of the use cases. Each table contains the use case name, the actor that initiates
and interacts with the use case, description of the use case and typical course
of events that show the interaction between the actor and the use case which
enable the team member to easily depict the functions of the proposed
system.
34. 33 | P a g e
Use Case id UC-01
Use Case Name Login
Actor Admin, Donor, Nurse, Seeker, Lab technician
Description It is authenticating method that allows users to login to
the system.
Goal To be accessed by an authorized and trust system user
Precondition Any user must have user name and password.
Basic Flow of
Event
Actor action System response
Step1:user initiate the
system
Step3:user enter user name
and password
Step2: system show login
interface
Step4: the system checks the
validity of the user’s name and
password
Step5: system display
user page
Post Condition System transfer control to user main screen to precede
actions.
Alternative A. If the username and password is invalid.
1. The system displays error message.
2. The system continues at step 2 to fill user name and
password again.
Use Case id UC-02
Use Case Name Post Information
Actor Admin
Description It is authenticating method that allows users to login to
the system.
35. 34 | P a g e
Goal Post new information about the blood bank that is accessed by
the users of this system
Precondition To post new information to the users in order to create
awareness and to initiate donors for donation
Basic Flow of
Event
Actor action System response
Step1: admin enter user
name and password
Step4: admin select post
information link
Step6: System admin enter
the information to be post
information
Step2: the system checks the
validity of user name and
password
Step3: the system displays
main admin page
Step5: System display post
information page.
Step7: System check post
information
Step8: System posted new
information
Post Condition The posted information will be viewed by an authorized
user
Alternative If the new information is not post properly:
1. The system displays error message.
2. Go to Step5 to post again.
Use Case id UC-03
Use Case Name View report
Actor Nurse, Lab technician
Description The Nurse and Lab technician can be viewing the report
generated by the admin
Goal To view users about the activities the of organization
Precondition They Should Log in into the system
Basic Flow of
Event
Actor action System response
36. 35 | P a g e
Step1: user enter user name
and password
Step4:user select view
report link
Step2: the system checks the
validity of user name and
password
Step3: system display user
page
Step5: system display report
Post Condition The users view report
Use Case id UC-04
Use Case Name Approve request
Actor Lab technician and Donor
Description Approving blood request and donation request send from
blood seeker and blood Donor respectively
Goal Give decision or response for the user request
Precondition The user request must be viewed by the nurse and lab
Technician
Basic Flow of
Event
Actor action System response
Step1: Donor and lab
technician enter user name
and password
Step4: Donor and lab
technician select approve
form
Step6: Donor and lab
technician search request
and if the request is valid
approve
Step2: the system checks the
validity of user name and
password
Step3: system display
Donor or lab technician page
Step5: the system display
approves
Step7: system check
information
Step8: system display the
request is approved
Post Condition Send for donor and seeker notice to donate the blood and
respectively receive blood
37. 36 | P a g e
Alternative The request is may be disapproved
Use Case id UC-05
Use Case Name View Feedback
Actor Admin, Nurse, Lab technician
Description Admin can see the Feedbacks that are submitted from
the user.
Goal To view user feedback about the organization service.
Precondition Login to the system
Basic Flow of
Event
Actor action System response
Step1: admin, Nurse and
Lab technician enter user
name and password
Step4: admin, Nurse and
Lab technician select view
Feedback link
Step6: admin, Nurse and
Lab technician view
Feedback
Step2: the system checks the
validity of user name and
password
Step3: system display
admin, Nurse and Lab
technician page
Step5: system display
Feedback records
Post Condition Admin, Nurse and Lab technician views the submitted
Feedbacks
Alternative If there is no Feedback.
1. The system displays error message.
2. Go to step4 to view Feedback again.
Use Case id UC-06
Use Case Name Blood Seeker Registration
Actor Admin, Seeker
Description The seeker must be registration to get access from the blood
bank.
38. 37 | P a g e
Goal To get service from blood bank using this system.
Precondition Go to the site and register
Basic Flow of
Event
Actor action System response
Step1: Admin enter user
name and password
Step4: Admin select
registration link
Step6: Admin fill seeker
registration form
Step2: the system checks the
validity of user name and
password
Step3: system display admin
page
Step5: the system display
seeker registration form
Step7: system check seeker
registration information
Step8: system Display
successfully registered
Post Condition If valid successfully register if not valid Alternate action
Alternative If not correctly fill to registered
1. The system displays error message.
2.Go to step5 to fill again registration information
Use Case id UC-07
Use Case Name Manage account
Actor Admin and donor
Description Admin and donor can create, delete, change user name and
Password
Precondition Admin and donor must be login to the system
Basic Flow of
Event
Actor action System response
39. 38 | P a g e
1) Admin and donor must
login to the system
3) Ad Admin and donor can
click on account
5) Admin and donor can fill
manage account form.
7) Admin and donor can click
on submit button
2)System display required page
4)System display account page
6) Systems validate the user
input and unfilled input
Post Condition Send successfully
Alternative If the fill form is invalid system display the form again
Use Case id UC-08
Use Case Name Generate report
Actor Admin
Description Generating the report about the activities that have been
done by the organization.
Goal To generate the required report information for users
Precondition The admin login to the system knows the activity that have
been done
Basic Flow of
Event
Actor action System response
Step1: admin enter user
name and password
Step4: Admin select generate
report link
Step2: the system checks the
validity of user name and
password
Step3: system display admin
page
Step5: system check report
Step6: system display the
Result
Post Condition Display the generated report
40. 39 | P a g e
Alternative If fail to generate
1.the system display error message
2. Go to step6 to check again
Use Case id UC-09
Use Case Name Give Feedback
Actor Donor, Seeker
Description Feedback the blood bank system about any thing
Goal To give the weakness and strength of the organization
Precondition User must register and create account system
Basic Flow of
Event
Actor action System response
Step1: User initiate the
system
Step3:user select feedback
link
Step5: user write Feedback
about organization service
Step2: system display user page
Step4: system display feedback
form
Step6: system check Feedback
information
Step7: system display Feedback
Submitted
Post Condition User send Feedback to the system
Alternative If not valid Feedback
1. The system displays error message.
2. Go to step4 to fill again Feedback
Use Case id UC-10
Use Case Name Blood Request
Actor Seeker
Description Sending request for required blood group with the patient
name just for the acceptance of the request.
41. 40 | P a g e
Goal Asking blood from the blood bank for the patient.
Precondition Seeker must be register and become a member of the
organization.
Basic Flow of
Event
Actor action System response
Step1: seeker enter user
name and password
Step4: seeker select send
blood request link
Step6:user fill the blood
request in the name of patient
Step2: the system checks the
validity of user name and
password
Step3: system display seeker
page
Step5: system display blood
request form
Step7: system check blood
request information
Step8: system display inserted
request record
Post Condition Indirectly accept the required blood thorough patient name
Alternative If the seeker fails to fill the form correctly.
1. The system displays error message.
2. Go to step6 to fill again the request
Use Case id UC-11
Use Case Name Donor Registration
Actor Donor
Description To register new donor and search the possible donor for the blood
collection mechanism
Goal To search the possible blood donor to communicate with
seeker.
Precondition Donor should access the system
Basic Flow of
Event
Actor action System response
42. 41 | P a g e
Step1: Donor enter user name
and password
Step4: Donor select
registration link
Step6: If the new donor come
fill the donor registration form
Step2: the system checks the
validity of user name and
password
Step3: system display donor page
Step5: system display donor
registration form
Step7: the system check donor
registration information
Step8: system display new
donor information
Post Condition donor information can be register and store into DB
Alternative If donor is filled invalid new donor registration information
1. The system displays error message.
2. Go to step6 to register new donor or search old donor
Use Case id UC-12
Use Case Name Donation request
Actor Nurse
Description The Nurse should be sends donation request with the required
Details
Goal To get permission for blood donation.
Precondition Want to login to the system and fill donation form.
Basic Flow of
Event
Actor action System response
Step1: Nurse activate the
system
Step3: Nurse select
donation request link
Step5: fill the donation
request form and send
Step2: system display main page
Step4: system display donation
request menu
Step6: system save the request in
DB
Post Condition Nurse request can be approved
43. 42 | P a g e
Alternative A. If Nurse do not fill the form correctly to send donation request
1. The system displays error message.
2. Go to step5 to fill again donation request.
4.3 Dynamic Model
Here in this dynamic model section, we will see some of the
activities done in the system using different UML diagrams including
sequence diagram, activity diagram, state chart or machine diagram and in
the next sections we will add class diagram.
4.3.1 Sequence Diagram
Sequence diagrams describe interactions among classes in terms
of an exchange of messages over time. It shows object interaction
arranged in time sequence to perform specific task. A sequence diagram
is a good way to visualize and validate various runtime scenarios
44. 43 | P a g e
Figure Sequence diagram for login
45. 44 | P a g e
Figure Sequence diagram for View blood
Figure Sequence diagram for request blood
46. 45 | P a g e
Figure Sequence diagram for Create account
Figure Sequence diagram for give Donor registration
47. 46 | P a g e
Figure Sequence diagram for view report
4.3.2 Activity Diagram
Activity diagram is another important behavioral diagram in UML
diagram to describe dynamic aspects of the system. Activity diagram is
essentially an advanced version of flow chart that modeling the flow from
one activity to another activity.
48. 47 | P a g e
Figure Activity diagram for login
49. 48 | P a g e
Figure Activity diagram for generate report
Figure Activity diagram for register
50. 49 | P a g e
Figure Activity diagram for create account
Figure Activity diagram for post information
51. 50 | P a g e
Figure Activity diagram for send blood request
Figure Activity diagram for register blood
52. 51 | P a g e
Figure Activity diagram for view report
Figure Activity diagram for donation request
53. 52 | P a g e
4.3.3 State Chart Diagram
State chart diagram also called state machine diagram is an illustration of the
states an object can attain as well as the transition between those states in the
unified modeling language. It is used to model the dynamic nature of the
system. It defines different state of an object during its life time and these
states are changed by event.
Figure State chart diagram for Login
Figure State chart diagram for Seeker registration
54. 53 | P a g e
Figure State chart diagram for generate report
Figure State chart diagram for Seeker registration
55. 54 | P a g e
4.4 Object Model (Using Class Diagram)
UML class diagrams show the classes of the system, their
interrelationships (including inheritance, aggregation, and association) and
the operations and attributes of the classes.
The following shows the class diagram for the proposed system.
Figure Class diagram
56. 55 | P a g e
4.5 User Interface Flow Diagram
Some of the screenshots of our project how it looks, even though it is not
completed all in all.