Blood Donors Portal

SOFTWARE REQUIREMENT SPECIFICATION

Submitted by

Kushal Shah
Dhananjay Parmar
Rushang Shah
In fulfillment for the award of the degree
of

BACHELOR OF ENGINEERING
in
COMPUTER ENGINEERING

Kalol Institute Of Technology And Research Center, Kalol [2012-2013]

Gujarat Technological University, Ahmedabad

December, 2012

Umiya Mata KadvaPatidar Education and

SamajSevaTrust,As a Parent body Sanchalit
Kalol Institute of Technology and Research
CentreHighway, B/h Old Janpath Hotel, Kalol (N.G.) 382721
Tel. No. (02764)222603, 222604 Fax No. (02764)222605
Website: www.kitrc.org E-mail:
kitrc1@yahoo.co.in

Kalol Institute of Technology & Research Center

Computer Engineering
2012

CERTIFICATE

This is to certify that the dissertation entitled Blood Donors Portal

has

been

carried

Mr.DhananjayParmar

out

byMr.

Kushal

(090260107026)&Mr.

Shah(090260107010),
Rushang

Shah

(090260107036) under the fulfillment of the degree of Bachelor of

Engineering

in

Computer

Engineering(7

th

Semester)

of

Gujarat

Technological University, Ahmedabad during the academic year 2012-2013.

Date :
Place :
________________
(H.O.D, CE)
Mr.Mahesh Panchal

________________
(Internal Guide)
Mrs.Shilpa D Serasiya

ACKNOWLEDGEMENT
We express thanks and gratitude to Mr. Mahesh Panchal, H.O.D computer science
department, KITRC for his encouraging support and guidance in carrying out the project.
We would like to express gratitude and indebtedness to Mahesh Panchal for his valuable
advice and guidance without which this project would not have seen the light of the day.
We thank Mrs. ShilpaSerasiya, Project guide, for providing us with an excellent project
and guiding me in completing our project successfully. I would like to thank all the staff
members of KITRC for their kind co-operation. I would like to thank my parents for
being supportive all the time, and I am very much obliged to them.

Yours Sincerely:
KushalShah(090260107010)
DhananjayParmar (090260107026)
RushangShah (090260107036)

Thanks All,

ABSTRACT
Android, currently developed by the Open Handset Alliance, is a platform for mobile
devices that includes an operating system, middleware and key applications. The Android
Software Development Kit provides the tools and Application Programming Interfaces
necessary to begin developing applications on the Android platform using the Java
programming language.
The increase on the usage of phones that can run applications has resulted to a significant
increase in their number and variety. A new rapidly growing sector, which is mobile
advertising, provides to brands, agencies and marketers the opportunity to connect with
consumer beyond traditional and digital media on their mobile phones.
The purpose of this study is to create Blood Donors portal to assist the people who
immediately requires the blood can use this application and if someone who wants to
donate the blood that can also use this application. So, it provides an easy way for
communication between the donor and acceptor.
Suppose a person get injured in an accident and requires a very rare blood group than
it becomes very difficult to get for the Hospital, because it is rarely available in the
Hospital then this application is very useful for that person as this application provide
easily interaction between donors and acceptors. For example rare blood group can easy
to access by this application. Such as Rh (-ve), Bombay blood group etc.

LIST OF TABLES
Table No

Table Description

Page No

Table 2.1

Milestone

Table 2.2

Risk Factor

11

Table 2.3

Potential Risk And Planning

12

Table 5.1

Data Dictionary

34

LIST OF FIGURES
Figure No

Figure Description

Page No

Figure 2.1

Work Breakdown Structure

Figure 4.1

Requirement Engineering Process

23

Figure 4.2

Requirement Analysis Process

24

Figure 5.1

Class Diagram

28

Figure 5.2

Use Case Diagram

29

Figure 5.3

Sequence Diagram(Donor)

30

Figure 5.4

Sequence Diagram(Acceptor)

31

Figure 5.5

Sequence Diagram(BDP)

32

Figure 5.6

Activity Diagram

33

NOTATIONS
ACTIVITY DIAGRAM
Action State
Initial state
End State
Join
Control Flow

USE CASE DIAGRAM

Actor

Use Case
Association
Include

TABLE OF CONTENTS

Acknowledgement

Abstract

ii

List of Tables

iii

List of Figures

iv

Chapter : 1 INTRODUCTION TO PROJECT

1.1.

Project Summary

1.2.

Purpose

1.3.

Project Scope

1.4.

Objective

1.5.

Synopsis

Chapter : 2 PROJECT MANAGEMENT

2.1. Project Planning

2.1.1. Project Development Approach

2.1.2 Project Plan

2.1.3 Milestone and Deliverable

2.1.4 Roles And Responsibility

2.2. Project Scheduling

2.2.1. Basic Principal

2.2.2 Work Breakdown Structure

2.3. Risk Management

10

2.3.1. Risk identification

10

2.3.2. Risk Management Planning

11
7

Chapter : 3 SYSTEM REQUIREMENT

3.1. User Characteristics

14

3.2. Functional Requirement

14

3.2.1 Functionality

14

3.2.2 Usability

14

3.2.3 Reliability

15

3.2.4 Design Constraints

15

3.3. Non Functional Requirement

15

3.3.1 User Interface

15

3.3.2 Hardware Interface

16

3.3.3 Software Interface

16

3.3.4 Communication Interface

16

3.4. Assumptions And Dependencies

16

3.5. Technology And Platform Dependencies

16

3.5.1 Android

16

3.5.2 Hardware Interface

18

3.5.3 Application Server

19

Chapter : 4 SYSTEM ANALYSIS

4.1. Study of Current System

22

4.2. Problem and Weakness of the Current System

22

4.3. Requirement Of New System

22

4.3.1 Requirement Engineering Process

23

4.3.1 Requirement Analysis Process

24
8

4.4. Study

25

4.4.1 Technical Feasibility

25

4.4.2 Operational Feasibility

25

4.4.3Economical Feasibility

26

4.4.4 Schedule Feasibility

26

4.5. Features of New System

26

Chapter : 5 SYSTEM DESIGN

5.1. Class Diagram

28

5.2. Use Case Diagram

29

5.3. Sequence Diagram

30

4.4.1 Sequence Diagram (Donor)

30

4.4.1 Sequence Diagram (Acceptor)

31

4.4.1 Sequence Diagram (BDP)

32

5.4. Activity Diagram

33

5.5. Data Dictionary

34

Chapter : 6 FUTURE ENHANCEMENT

38

Chapter : 7 CONCLUSION

40

Chapter : 8 REFERENCES LIST

42

Blood Donors Portal

CHAPTER 1
INTRODUCTION OF PROJECT

Blood Donors Portal

1.1

PROJECT SUMMARY

Today many people use android mobile phones and they use many different types of
application , but there is not a single application on android that provide a functionality by
which we can get a rare blood group such as O-ve , Bombay blood group when are in need of
it in an hospital immediately. By this application we can request for particular blood group
using this application and the registered person who want to donate the blood can easily
contact the acceptor.

FEATURES:

Highly Based on GPS System

Providing easy communication between donor and acceptor
Request for blood group as per need

Donor

Can get registered on the application

Can also have sign in and forgot password utilities as well.
Can create the profile
Will specify their blood group to donate
Record will be maintain about when donor last time donated blood
Can communicate with acceptor for blood donation
Can set the privacy policy and terms and conditions aspects

Acceptor

Admin

Can get registered on the application

Can also have sign in and forgot password utilities as well.
Can create the profile
Will specify their blood group to request
Can communicate with available donor for requesting blood
Can set the privacy policy and terms and conditions aspects

Can manage all details of the donor

Can also manage all details of acceptor as well
Can also manage the general contents of the application too
Application can work in online mode
We will make sure that application will have backward compatibility
Proper placement of header and footer contents
Application development will be on module based so future enhancement will easy
one
Proper unit and integration testing
Complete deployment of the application

Blood Donors Portal

1.2 PURPOSE
The purpose of the document is to collect and analyze all assorted ideas that have come up to
define the system, its requirements with respect to user. Also, we shall predict and sort out
how we hope this application will be used in order to gain a better understanding of the
project, outline concepts that may be developed later, and document ideas that are being
considered, but may be discarded as the application develops.
In short, the purpose of this SRS document is to provide a detailed overview of our software
application, its parameters and goals. This document describes the project's target audience
and its user interface, hardware and software requirements. It defines how our client, team
and audience see the Android application and its functionality.

1.3 PROJECT SCOPE

It can act as targeted marketing that can reach one user, on one medium, at the right time and
the right place. The approach used in the current project is of an Online Interactive
advertising system. The user is given the opportunity to use his/her device to connect to a
single source of advertisement data whenever he/she desires to do so. This means that data
from the Advertising Server flow into the users device only when the user requests these
data.

The user opens an application dedicated for displaying advertisements from the
Advertising Server.

The user opens an application which is compatible with displaying this

information.

1.4

kind of

OBJECTIVES

This application will provide commission based marketers to advertisers as well and so
they can pay as per the marketing person is doing

Marketer will have the way to do marketing online and can have source of income
on that site can earn something too.
This application will be free initially in android market so it will attract the large
number of audience too.

The system is not bound to subscribers, but it is open to however want to make a request,
although it keeps track of the users data and changes that might happen to them. The user is
automatically recorded by the system on his/her first interaction with it.

Blood Donors Portal

1.5 SYNOPSIS
Project title

Android Application for Online

Advertisement

Objective

To make an application which helps

the society more than market

Time Duration

Approximately 10 Months.

Software specification

Eclipse, ADT,SQLite ,SDK.

Division of responsibility
We are working as a group of three
person on the software with help of
some people of the organization.
Status
Submitted To
Internal Guide

Partially Completed
Kalol Institute Of Technology &
Research Center.
Mrs. Shilpa Patel.

Blood Donors Portal

CHAPTER 2
PROJECT MANAGEMENT

Blood Donors Portal

2.1 PROJECT PLANNING

2.1.1 Project Development Approach
The aim of this chapter is to give a brief description of the Android Fundamentals in order
to provide the basis for the forthcoming chapters to become more easily comprehensive.
More attention will be paid to the Android features that are widely used in the advertising
application. Some elements that were not used in the application will be briefly mentioned as
well for the sake of description continuity. In this section, the Android application by means
of processes will be illustrated and the Android components that an application consists of
will be described.
According to the Android tutorial: Android is a software stack for mobile devices that
includes an operating system, middleware and key applications. The Android SDK provides
the tools and APIs necessary to begin developing applications on the Android platform using
the Java programming language . Android comes with a number of features, such as:
The application Framework, which enables the reuse and replacement of Android
applications components.

The Dalvik virtual machine, a specialized VM implementation designed for mobile

device use for compilation and execution of Software written in Java.

SQLite, for structured data persistence.

Media support, including the following formats: MPEG4, H.264, MP3, AAC, AMR,
JPG, PNG, GIF.

Connectivity, using various technologies including GSM/EDGE, CDMA, EV-DO,

UMTS, Bluetooth, and Wi-Fi.

Web Browsing, based on the open-source WebKit application framework.

Optimized graphics, based on custom 2D graphics library and 3D graphics based on

the OpenGL ES 1.0 specification.

Additional hardware support, including video/still cameras, touchscreens, GPS,

accelerometers, magnetometers e.t.c.

Development Environment, including a device emulator, tools for debugging,

memory and performance profiling and a plug-in for the Eclipse IDE.

Using the former components, a developer can use, extend or even replace one or more of
the later components. The Application Framework consists of services and systems such as:
6

Blood Donors Portal

A set of views including buttons, lists, grids etc.

The Content Providers, which allow applications to access data from other
applications, or to share their own data.

A Resource Manager, which allows applications to access various resources (for

instance strings, arrays, layout descriptors and graphics).

An Activity Manager, which is responsible for managing the

and proving some navigation capabilities

lifecycle of applications

2.1.2 Project Plan

Project planning is basically concerned with identifying and measuring activities, milestones
and deliverables produced by project. Thus in this section I cover following:Estimating some basic attributes of the project
a) Duration: How long will it take to complete the development?
The Client for which the Application is to be developed is not clear with his requirements and
not very rigid with the demands due to the unawareness of possibilities. Hence it is necessary
to understand his requirements in details, do a detailed research of what combination of
technologies would be best for the project, get acclimatized to them, do the rest of the
planning and go ahead with the work. Hence the duration of the Project can be roughly
estimated to 10 months.
b) Efforts: How much efforts would be required?
Since it is a three person group and as it is a very hazy picture ahead of how to go about the
project, figuring that out and considering the pros and cons would take up a lot of effort in
itself. Thus efforts can be estimated to 3 hours of weekdays work for 10 months

2.1.3. Milestones And Deliverable

Management needs information. As software is intangible, this information can only be
provided as documents that describe the state of the software being developed. Without this
information, it is impossible to judge progress and cost estimates and schedules cannot be
updated. When planning a project series of milestones are established.

Sr.No

Activities

Date

Study of System

20/07/2012

Prior tool study

27/07/2012

Blood Donors Portal

3

Similarly tools study

01/08/2012

Project Synopsis

12/08/2012

Analysis iteration-1

20/09/2012

Analysis iteration-2

02/09/2012

SRS

16/09/2012

UML Diagrams

29/09/2012

Database

10/10/2012

10

Code (Implementation)

16/01/2013

11

Midway testing

02/03/2013

12

Testing report

22/03/2013

13

Final project documentation

06/04/2013

Table 2.1 Milestones

2.1.4 Roles And Responsibility
The team members are responsible for all documentation to be developed and for all work to
be done. As I am individual team member for this project development, partition of project
work is not there. For better development of a project, internal and external help me.

2.2PROJECT SCHEDULING

Project scheduling is one of the main key aspects of any project. Any project must be
schedule before developing it.
When project developer works on scheduled project it is more advantageous for
him/her to compare to unscheduled project. It gives us timeline for finishing the
particular activity. Scheduling gives us idea about project length, its cost, its normal
duration of completion and we can also find out the shortest way to complete the
project with less overall cost of project.
Project schedule describes dependency between activities. The estimated timerequired
to reach each milestones and allocation of people to activities.

2.2.1 Basic Principal

Software project scheduling is an activity that distributes estimated effort across the planned
project duration by allocating the effort to specific software engineering tasks.

Proper scheduling requires:

Blood Donors Portal

All tasks appear in network and dependent on some of other.

Effort and timing are intelligently allocated to each task.

Interdependencies between tasks are properly indicated.

Resources are allocated for the work to be done.

2.2.2 Work Breakdown Structure

Figure 2.1 Work breakdown structure

2.3 Risk management

Risk Analysis and management are a series of steps that helps a
software team to understand and manage uncertainty. Many problems can plague a
software project. A risk is a potential problem it might happen, it might not but,
regardless of the outcome, its really good idea to identify it, assess its probability of
occurrence, estimate its impact, and establish a contingency plan should the
problem occur.
Software is difficult undertaking. Lots of thing can go wrong, may
often do. Its for this reason that being prepared-understanding the risks and talking
proactive measures to avoid or manage them-is a key element of good software project

Blood Donors Portal

management. Different steps in risk analysis and management are Risk Identification,
Risk Analysis and Risk Planning & Management.

2.3.1 Risk Identification

Risk identification is the first stage of Risk Management. It is concern with

discovering possible risks to the project. In principle, this should not be assessed or
prioritized at this stage, although in practice risks with very minor consequences or
very low probability risk are not usually considered.
Dependencies:
Availability of trained, experienced people.
Intercommoning or Inter group dependencies.
Customer furnished items or information.
Requirement Issue:
Lack of clear product vision ..
Lack of agreement on product requirement .
Technical staff conflict .
Un prioritized requirements .
Management Issues:
Inadequate planning and task identification
Inadequate visibility into actual project status
Unclear project owner ship and decision making
Unrealistic commitment made, some times for the wrong reasons.
Managers or customers with unrealistic expectation
Staff Personality conflicts
Poor communication
General Risks:
The general risks that can be affect the development of software as follows:
1. Lack of resources:
The resources which are needed for the development of this project are not
available during project. We need at least one computer per member in the
company with all the software required software installed in order to
develop the project as well as for evaluation purpose. If we do not get
these resources which can cause the big effect in the form of failure of the
project.
2.Time Duration:
We are creating this software module for real time project of company so it
takes time to implement correctly and completely.
3.Customer Requirement :
Customer may have such requirement during project development that will
cause change of the whole design. So we might not implement the project
according the schedule.
2.3.2 Risk Management and Planning
During the risk analysis process, each identified risk is contained in turn and a
judgment made about the probability and seriousness of the risk. Once the
risks have been analyzed and ranked, a judgment must then make about which
are the most important risks, which must be considered during the project.
Risk planning process considers each of the key risks, which have been
identified and identified strategies to manage the risk. Again there is no
10

Blood Donors Portal

simple process that can be followed to establish risk management plans. It
relies on the judgment and experience of the project manager.
Risk
Resources unavailability
Domain misunderstanding
Interface with other software
Change of Customer requirement
Unknown dependency of system
Lack of direct contact with user
Gap due to communication
Schedule break up
Compatibility

Portability
Low
Moderate
Moderate
Moderate
Low
Low
Low
Low
High

Effect
Serious
Catastrophic
Serious
Serious
Tolerable
Tolerable
Tolerable
Tolerable
Serious

Table 2.2 Risk Factor

Risk
Resources unavailability
Domain misunderstanding
Interface with other software
Change of customer requirement
Unknown dependency of system
Lack of direct contact with
Gap due to communication
Schedule Break up

Planning
Prior analysis of resource required
Study of existing and root application
Demonstration required
Periodic online meeting and support help
External scope and future planning
user Online meeting and e-communication
Progress and problem report etiquette
Preplanned schedule with recovery
Table 2.3 Potential Risk and Planning

11

Blood Donors Portal

CHAPTER 3
SYSTEM REQUIREMENT

12

Blood Donors Portal

3.1 USER CHARACTERISTICS

Identify and list the users of the application. Also describe their general characteristics such
as online blood request, to register for donating blood, and technical expertise that impose the
important constraints on the system's operating environment

GroupBuying has three users:

Administrator
Admin manages the database of the application. Admin can access the profile of any user and
can update the profile of user. For this task admin must have Internet knowledge and need
Android Phone.

Donor
Donor willregister in this application. He will check his profile can update his profile. He will
get notification for blood request. He can contact the acceptor to donate blood.

Acceptor
Acceptor will register in this application. He will check his profile can update his profile. He
will request for the blood to donors.

3.2 Functional Requirements:

3.2.1 Functionality:
Logon Capabilities
The application shall provide the users with logon capabilities.
Mobile Devices
The Blood Donation Portal help is also supported on android mobile
devices such as cell phones.
Alerts
The application can alert the users in case of any problems.
3.2.2 Usability:
The application shall allow the users to access the system from the
Internet using GPS or its derivative technologies. The system uses a
MAP and GPS as an interface.
Since all users are familiar with the general usage of GPS, no specific
training is required.
The system is user friendly and self-explanatory.

13

Blood Donors Portal

3.2.3 Reliability:
The application has to be very reliable due to the importance of data
and the damages incorrect or incomplete data can do.
Availability
The application is available 100% for the user and is used 24 hrs a
day and 365 days a year. The application shall be operational 24
hours a day and 7 days a week.
Mean Time Between Failures (MTBF)
The application will be developed in such a way that it may fail
sometimes.
Mean Time to Repair (MTTR)
Even if the application fails, the application will be recovered with
restart of application.
Accuracy
The accuracy of the application is limited by the accuracy of the GPS
system and Internet Connection.
Maximum Bugs or Defect Rate
Not specified.
Access Reliability
The application shall provide 100% access reliability.
3.2.4 Design Constraints:
Software Language Used the languages that shall be used for coding
the Blood Donor Portal is java based android. For working on the
coding phase of the Blood Donor Portal, the Android Virtual Device
(AVD) and SDK needs to be installed.
Development Tools will make use of the available Android
Development Tool kits SDK for working with Eclipse.
Class Libraries will make use of the existing Android libraries. Also
we need to develop some new libraries for the map-based application.
For that we will use Googles map API.
3.3 Nonfunctional Requirements:
3.3.1 User Interfaces:
Application will be accessed through a Mobile Interface. The interface
would be viewed best using 320 x 240pixels resolution setting. The software
would be fully compatible with Android Operating System.
3.3.2 Hardware Interfaces:
14

Blood Donors Portal

Client Side:

Processor: 250MHz

RAM: 256 Mb or more

Hard Drive: 512MB

3.3.3 Software Interfaces:

Android Operating System
3.3.4 Communications Interfaces:
The Customer must connect to the Internet to access the
application:

Through GPRS

Through 3G

Through Wi-Fi
3.4 ASSUMPTIONS AND DEPENDENCIES

The project was started with the assumption that we would be given the necessary
support in the form of hardware and software resources. Our project depends a lot
on the inputs.

User has the basic knowledge of the Application based environment.

The project design is mainly created by keeping in mind the dependency with the
language.

System has necessary installed hardware and software.

3.5 TECHNOLOGY AND PLATFORM DEPENDENCIES

3.5.1 Android
3.5.1.1 Introduction
The aim of this chapter is to give a brief description of the Android Fundamentals in order to
provide the basis for the forthcoming chapters to become more easily comprehensive. More
attention will be paid to the Android features that are widely used in the advertising
15

Blood Donors Portal

application. Some elements that were not used in the application will be briefly mentioned as
well for the sake of description continuity. In this section, the Android application by means
of processes will be illustrated and the Android components that an application consists of
will be described.
Most object-oriented development environments consist of several parts:

An object-oriented programming language

A library of objects
A suite of development tools

A runtime environment

3.5.1.2 Features Of Android

Each Android application is written in Java code and is accompanied with specially
structured resources and data files (usually in xml format). A tool called the aapt tool then
bundles the code and the accompanying files into an Android package which is a single file
with an .apk suffix. Each .apk file corresponds to a single Android application and can be
installed or downloaded to a mobile device running Android. Each application runs in its own
Virtual Machine and, therefore, in its own process and in isolation from the code of all other
applications (although it can be arranged that an application can be viewed and used by other
applications as well). However, it is theoperating system that is responsible for executing and
stopping each application when it's no longer needed and system resources are required by
other applications .

Android has four different types of components:

Activities that provide a visual user interface. Normally an application consists of at
least one activity. An example of an Activity could be a form where a user is
prompted to fill in data, information in list form or a pop-up window. Each activity
can be seen as a window containing elements called Views. Further details about
activities are provided in the next section .
Services, which run in the background for an indefinite period of time. Services,
contrary to Activities have no visual representation but can work with an activity in
order to be controlled. An example of a Service could be a music player or a service
that sends and receives data from the network. More details about Services are given
in a following section .
Broadcast Receivers, which receive and react to broadcast announcements. They neither
have any visual representation and its only purpose is to react to messages broadcast
through all the system in order to react properly. Such announcement could be a low
battery indication and a reaction could be the initiation of a relevant activity.

16

Blood Donors Portal

3.5.2 Eclipse
3.5.2.1 Introduction
Every Android .apk application file must be accompanied with an XML structured file that is
always called the AndroidManifest.xml. One such file is created automatically whenever a
new Android application is created in Eclipse. The AndroidManifest file is the configuration
file of an application, containing not only declarations of the application components, but
also any external libraries the application might use, the permissions granted to the
application and some information about the SDK version in use.
In addition, Android offers ways to build custom Views as well by extending and combining
existing View widgets. Basic Views, List Views and menus were regularly used in the
targeted advertising project using Eclipse.
Some of the most commonly used basic Views are the following:
TextView, used to display text to the user.
EditText, used to edit the text displayed. It extends the TextView class.
Button, represents a push-button widget
ImageButton, represents a push-image widget. It extends the Button class.
CheckBox, button that has two states: checked or unchecked. It extends the Button class.
ToggleButton, displays checked/unchecked states using a light indicator. It extends the
Button class.
RadioButtonand RadioGroup, buttons that have two states: checked or unchecked. They
extend the Button class.
ImageView, displays an arbitrary image, such as an icon. It extends the View class.

3.5.2.2 Overview Of The Android Framework

According to the Android tutorial: Android is a software stack for mobile devices that
includes an operating system, middleware and key applications. The Android SDK provides
the tools and APIs necessary to begin developing applications on the Android platform using
the Java programming language . Android comes with a number of features, such as:
The application Framework, which enables the reuse and replacement of Android
applications components.
The Dalvik virtual machine, a specialized VM implementation designed for mobile
device use for compilation and execution of Software written in Java.
SQLite, for structured data persistence.
Media support, including the following formats: MPEG4, H.264, MP3, AAC, AMR,
JPG, PNG, GIF.
Connectivity, using various technologies including GSM/EDGE, CDMA, EV-DO,
UMTS, Bluetooth, and Wi-Fi.
Web Browsing, based on the open-source WebKit application framework.
17

Blood Donors Portal

Optimized graphics, based on custom 2D graphics library and 3D graphics based on the
OpenGL ES 1.0 specification.

3.5.3 Application Server

As referred earlier, the Application Servers role is to listen for specially encoded requests
and depending on the kind of the request to provide an appropriate response to the caller.
These responses normally contain data that are stored in the Application Servers database
while more than one client can be served at a given moment. The clients can be either
Android mobile users having installed the advertising application in their devices, or user(s)
with an administration role. The server can recognize from whom a message comes from and
to whom to send the response. Each request results to a new connection to be established and
a new thread to be created from the servers network connection interface, in which thread
the given request and its relative response will be served. Upon the dispatch of the response,
the connection with the caller gets closed.
When a new request is received, the message of it is forwarded to a message interpreter,
which in turn calls an appropriate method from the relevant controller (passing it the relative
data decoded from the message), depending on whether the request has come from an
Android mobile user or an administrator, hence depending on the application that made the
request. Each controller method then calls one or more service methods in order to store or
retrieve data to/from the database. The service methods are separated again into two different
classes: One containing methods that interact with database tables that are relevant to user
data and one that has the methods related to interaction with the database tables keeping
advertisements data. Once the result is obtained from the service method(s), they are
propagated back to the controllers layer and then to the message interpreter. The message
interpreter forms a response message that will be understood by the caller and sends the
response message on the network interface class. All the above are illustrated in the diagram
that follows .

3.5.4 SQL SERVER MANAGEMENT

Microsoft, new in Microsoft SQL Server 2008, is an integrated environment for accessing,
configuring, managing, administering, and developing all components of SQL Server. SQL
Server Management Studio combines a broad group of graphical tools with a number of rich
script editors to provide access to SQL Server to developers and administrators of all skill
levels.
SQL Server Management Studio combines the features of Enterprise Manager, Query
Analyzer and Analysis Manager, included in previous releases of SQL Server, into a single
environment. In addition, SQL Server Management Studio works with all components of
SQL Server such as Reporting Services, Integration Services, SQL Server Compact Edition,
and Notification Services. Developers get a familiar experience, and database administrators
get a single comprehensive utility that combines easy-to-use graphical tools with rich
scripting capabilities.

Features
18

Blood Donors Portal

A single, integrated environment for SQL Server Database Engine management and
authorized.

New management dialogs for managing objects in the SQL Server Database Engine,
Analysis Services, Reporting Services, Notification Services, and SQL Server
Compact Edition, that allows you to execute your actions immediately, send them to
a Code Editor, or script them for later execution.

Non-modal and resizable dialogs allow access to multiple tools while a dialog is
open.

A common scheduling dialog that allows you to perform action of the management
dialogs at a later time.

Exporting and importing SQL Server Management Studio server registration from
one Management Studio environment to another.

Save or print XML Show plan or Deadlock files generated by SQL Server Profiler,
review them later, or send them to administrators for analysis.
A new error and informational message box that presents much more information,
allows you to send Microsoft a comment about the messages, allows you to copy
messages to the clipboard, and allows you to easily e-mail the messages to your
support team.

An integrated Web browser for quick browsing of MSDN or online help.

Integration of Help from online communities.

A new activity monitor with filtering and automatic refresh.

Integrated Database Mail interfaces.

19

Blood Donors Portal

CHAPTER4
System Analysis

20

Blood Donors Portal

4.1 STUDY OF CURRENT SYSTEM

Current System is web based Application(i.e. Website),which allows the user to post the
requirement on a group page of particular blood group on social networking sites.
This provides only the information posted by the user which can include any location around
the country.

4.2 PROBLEM AND WEAKNESSES OF THE CURRENT SYSTEM

Not enough Interactivity supported.

Not Much Awareness in the users about the existence of such systems and the
benefits they can reap out of it.

Does not provide better communication between donor and acceptor.

Does not give alerts/Notifications of new request for the blood.

21

Blood Donors Portal

4.3 REQUEREMENT OF THE NEW SYSTEM

4.3.1 REQUIREMENT ENGG. PROCESS
Feasibiltyst
udy

Requireme
nt Analysis
Requiremen
t definition

Feasibility
Report
System
model

Requireme
nt
documents

Specificati
on of
requiremen
t

Requiremen
t
specificatio
n

Specificatio
n of
requirement

Figure 4.1 Requirement Engineering Process

22

Blood Donors Portal

4.3.2

REQUIREMENT ANALYSIS PROCESS

Domain
understanding

Requirement
validation

Requirement
definition and
specification

Prioritization

Requirement
collection

Conflict
resolution

Requirement
Figure 4.2 Requirement Analysis Process

23

Blood Donors Portal

4.4 FEASIBILITY STUDY

Objective of Feasibility Study
An important outcome of the preliminary investigation is the determination that the
system requested is feasible. The feasibility study is carried out to examine the likelihood that
the system will be useful to the organization.
There are four aspects in the feasibility study namely.

Operational Feasibility

Technical Feasibility

Economic Feasibility

Schedule Feasibility

4.4.1 TECHNICAL FEASIBILITY

The main purpose of checking Technical Feasibility is to examine whether the current
technology is sufficient for the development of the system. The outcomes of the technical
feasibility are as follows:

GroupBuying application uses Eclipse , Android OS &MsSQL as a front end and backend
respectively that is provides all APIs that are required for the application.

The application developed in Android can run on any of the OS like which has Android
compatibility like Smartphones.

The application developed in Android can run on any of the web-browser for that one
software should be there on PC.

Back end we can use MsSQL for database connection.

It provides faster response to the user. It is accurate, reliable and easy.

Further expansion of the system is possible easily.

So, this application is Technically Feasible.

4.4.2 OPERATIONAL FEASIBILITY

The main purpose of checking Operational Feasibility is to find out whether the system will
be functional after its development and installation or not. The outcomes of the operational
feasibility are as follows:
They can be administered from remote locations using mail, email or telephone.

So, it is supposed to improve the working efficiency of user.

4.4.3 ECONOMICAL FEASIBILITY

The main purpose of checking Economical Feasibility is to examine whether the financial
investment in the system will meet the organizations requirements or not.
24

Blood Donors Portal

Proposed System is developed as mobile application which is freely available on

WWW and Android App store.

It uses Android device as a front end that is also freely available.

The advantages of the system nullify its development cost as the scope and effect of
the system are very large.

So, this application is economically feasible.

4.4.4 SCHEDULE FEASIBILITY

This type of the feasibility includes a measure of how reasonable the projected with respect to
time aspect.
When developing software it is difficult to measure such things as software complexity,
quality and to estimate the amount of effort it will take to complete the project.

4.5 FEATURES OF NEW SYSTEM

It is completely automated.

The data can be entered on the click event of the mouse button.
All part of information of customer can be entered on the click event of mouse button.

It generates desired reports at the click of a mouse button.

Updated report, User-Friendly Interface, Easy Maintenance of the Record.

25

Blood Donors Portal

PART 5
SystemDesign

26

Blood Donors Portal

5.1 Class Diagram

Figure5.1 Class Diagram

27

Blood Donors Portal

5.2 Use Case Diagram

Figure5.2 Use Case Diagram

28

Blood Donors Portal

5.3 Sequence Diagram

5.3.1Sequence Diagram for Donor Registration

Figure 5.3 Sequence Diagram for Donor Registration

29

Blood Donors Portal

5.3.2 Sequence Diagram for Acceptor Registration

Figure 5.4 Sequence Diagram for Acceptor Registration

30

Blood Donors Portal

5.3.3 Sequence Diagram for Blood Donor Portal

Figure 5.5 Sequence Diagram for Blood Donor Portal

31

Blood Donors Portal

5.4 Activity Diagram

Figure5.6Activity Diagram

32

Blood Donors Portal

5.5Data Dictionary
5.5.1 Table Name: Registration Details
Sr. No
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.

FIELD NAME
Id
First_Name
Middle_Name
Last_Name
User_Name
Sex
Password
Re-password

DATA TYPE
Interger
Text
Text
Text
Varchar2
Text
Varchar2
Varchar2

SIZE
5
25
25
25
25
10
20
20

DOB
Age
Address
Mobile No
City
Pincode
State
Email_Id
Blood_Group

Date/Time
Integer
Varchar2
Integer
Text
Interger
Text
Varchar2
Text

3
50
10
25
6
25
50
10

Description
Id of user
First Name of user
Middle Name of user
Last Name of user
Foreign key for user name
Sex of user
User password for login
Authenticate user
password
Date of birth of user
Age of the of user
Address of the user
Unique and Not null
City of the user
Pincode of user area
State of user
Unique Email id of user
Blood group of user

33

Blood Donors Portal

5.5.2 Table Name: Login

Sr.No

FIELD NAME

DATA TYPE

SIZE

Description

1.

User_Name

Varchar2

20

Primary key for User Name

2.

Password

Integer

20

Not Null users password

5.5.3 Table Name: State_Master

Sr. No

FIELD NAME

DATA TYPE

SIZE

Description

1.

State_Id

Varchar2

25

Primary key for State Id

2.

State_Name

Text

25

Name of the State

5.5.4 Table Name :District_Master

Sr No.

FIELD NAME

DATA TYPE

SIZE

Description

1.

District_Id

Varchar2

25

2.

State_Id

Varchar2

25

Primary key for District

Id
Foreign key for State Id

3.

District_Name

Text

25

Name of the District

5.5.5 Table Name :City_Master

Sr No.

FIELD NAME

DATA TYPE

SIZE

Description

1.

City_Id

Varchar2

25

Primary key for City Id

2.

State_Id

Varchar2

25

3.

City_Name

Text

25

Foreign key for District

Id
Name of the City

5.5.6 Table Name: Area_Master

Sr No.

FIELD NAME

DATA TYPE

SIZE

Description

1.

Area_Id

Varchar2

25

Primary key for Area Id

2.

State_Id

Varchar2

20

Foreign key for City Id

3.

Area_Name

Text

25

Name of the Area

34

Blood Donors Portal

4.

Longitude

Varchar2

25

Longitude of the Area

5.

Latitude

Varchar2

25

Latitude of the Area

5.5.7 Table Name: Request

Sr No.

FIELD NAME

DATA TYPE

SIZE

Description

1.

Request_Id

Varchar2

25

Primary key for Area Id

2.

User_Name

Varchar2

20

3.

Blood_Group

Varchar2

25

Foreign key for

Username
Blood group detail

4.

No_of_Bottle

Integer

25

No. of bottle required

5.

Request_Date

Date/Time

25

Date of request

6.

Request_Detail

Varchar2

100

Request Information

7.

Mobile_No

Integet

10

Mobile No of Acceptor

8.

Request_ Area

Text

25

Area of Acceptor

9.

DueDate

Date/Time

Due Date for Blood

Requirement

5.5.8 Name Table: Notification

Sr No.

FIELD NAME

DATA TYPE

SIZE

1.

Notific_Id

Varchar2

25

2.

User_Name

Varchar2

25

3.

Notific_Detail

Varchar2

100

Description
Primary key of
Notification
Foreign key for
Username
Detail of Notification

5.5.9 Table :Donate_Trans

Sr No.

FIELD NAME

DATA TYPE

SIZE

Description

1.

Id

Varchar2

25

Foreign key for Id

2.

User_Name

Varchar2

25

3.

No_Time_Donated

Integet

10

4.

Last_Donated_Date

Date/Time

25

Foreign key for

Username
No of time Blood
donated
Date of last donated
blood

35

Blood Donors Portal

5.1 Data Dictionary

36

Blood Donors Portal

CHAPTER6
Future Enhancement

37

Blood Donors Portal

Future Enhancement

This application can be enhanced for iphone , blackberry and other mobile device
This application can also built for desktop (Os like windows 8 , Mac , etc)
Social element can be added
One to One calling for better communication between donor and acceptor can be
implemented
Sms feature can be implemented to send notification to the user when the user is
offline to application
Better Navigation for donor to find acceptor location

38

Blood Donors Portal

CHAPTER7
Conclusion

39

Blood Donors Portal

7.1 CONCLUSION
Android Application project served as a great learning experience for us. It gave us the
opportunity to work as a group. Through this experience, we not only learned to do all task
alone but we also also learned to be more responsible.
The group project is by far the most important group piece of work in the project. It provides
the opportunity for us to demonstrate independence and originality, to plan and organize a
large project over a long period, and to put into practice some of the techniques we have been
taught throughout the project. Whatever our level of academic achievement so far, we can
show our individuality and inspiration in this project. It should be the most satisfying piece of
work in our project.
We have developed Android application with great concern and have tried our best to
implement as many as features to make it visible and usable.
Android application is a powerful and easy to use application for administrator, merchant,
and customer. It is the software with the latest platform that fulfills the needs of customers. It
will help the customer to take appropriate decisions quickly and will help them in their
purchase.

40

Blood Donors Portal

CHAPTER8
References List

41

Blood Donors Portal

Referred Books

Android Wireless Application Development ,Shane Conder

Android For Dummies

The Android Developer's Cookbook (7Summits)

Sams Teach Yourself Android Application Development in 24 Hours (7Summits)

Sites Referred

http://developer.android.com/resources/index.html

http://en.androidwiki.com/wiki/Main_Page

http://marakana.com/training/android/

42