2. 2
EXECUTIVE
SUMMARY
This
report
has
been
prepared
by
the
members
of
our
Capstone
team
as
part
of
the
Capstone
project
for
the
MSIS
program
at
Santa
Clara
University.
Our
team
was
successfully
able
to
draw
upon
our
collective
experiences
in
the
program
in
order
to
design,
create
and
complete
a
cloud-‐based
system
that
provides
sales
data
to
an
insurance
agency.
Our
system
provides
a
Dashboard
and
Reporting
capabilities
as
well
as
Goal
Setting.
Though
the
system
has
not
actually
been
implemented
in
a
real-‐world
setting,
it
could
easily
provide
great
value
to
an
insurance
agency.
The
system
focuses
on
gathering
the
sales
data
and
providing
tools
to
make
the
data
meaningful
with
minimal
effort.
The
Producer
is
responsible
for
selling
the
insurance
policies
to
the
Clients
and
he
or
she
has
certain
goals
that
are
set
for
him
or
her
by
Management
every
year.
Our
system
provides
up-‐to-‐date
visualization
of
where
each
Producer
stands
at
a
given
time
with
regard
to
new
business,
retention
as
well
as
other
measurements.
A
Manager
is
able
to
check
on
any
of
the
Producers
as
well
as
the
agency
as
a
whole.
Both
the
Producer
and
Management
are
able
to
run
reports
to
display
new
business,
retention
and
a
combination
of
both,
with
Management
having
additional
reporting
tools
to
measure
the
quality
of
the
book
of
business
and
Carrier
statistics.
Beyond
that,
Management
has
the
ability
to
set
goals
for
each
Producer.
There
is
no
longer
a
need
for
manual
Excel
spreadsheets
or
calculations.
All
of
the
most
important
information
is
readily
available
with
the
most
current
data.
The
final
deliverables
include
the
specifications
and
design
of
the
project,
testing
details,
potential
implementation
information,
future
enhancements
and
the
working
system.
Our
team
is
incredibly
proud
of
our
final
product
and
feels
confident
that
it
could
benefit
a
typical
insurance
agency
if
given
the
opportunity
to
be
implemented.
Our
system
was
heralded
by
a
real
insurance
agency
Vice
President
as
being
able
to
“become
an
integral
part
of
our
insurance
agency
operations
and
will
certainly
help
us
to
achieve
our
revenue
goals
and
take
us
to
the
next
level”.
3. 3
TABLE
OF
CONTENTS
I.
Introduction
Background…………………………………………………………………………………………………….……….5
Proposed
Solutions………………………………………………………………………………………………….6
System
Actors………………………………………………………………………………………………………….6
Business
Needs
and
Scope………………………………………………………………………………………..7
II.
Project
Planning
Project
Staffing………………………………………………………………………………………………………..9
Project
Timeline……………………………………………………………………………………………………...9
Project
Methodology……………………………………………………………………………………………..13
Risks…………………………………………………………………………………………………………………….13
Assumptions……………………………………………………………………………………………………...…14
Dependencies……………………………………………………………………………………………………….15
Project
Deliverables…………………………………………………………………………………………...…15
III.
Analysis
Design
Requirements
Definition……………………………………………………………………………………….16
Use
Cases……………………………………………………………………………………………………………...21
Data
Flow
Diagrams…………………………………………………………………………………...…………34
Data
Dictionary…………………………………………………………………………………………………….47
IV.
Design
Phase
Architecture
Design……………………………………………………………………………………………...56
Program
Design……………………………………………………………………………………………………63
Database
Design…………………………………………………………………………………………………...69
V.
Implementation
Phase
Testing………………………………………………………………………………………………………………...70
User
Guide…………………………………………………………………………………………………………144
4. 4
VI.
Conclusion
Success
Criteria………………………………………………………………………………………………….162
Future
Enhancements………………………………………………………………………………………...162
VII.
Appendix
Letter
from
Lighthouse
Management…………………………………………………………………..164
5. 5
I. Introduction
Background
This
project
was
conceived
to
solve
real
problems
in
a
simulated
environment.
While
it
is
possible
for
our
system
to
be
useful
to
insurance
agencies,
we
have
not
actually
been
contracted
to
create
this
system
for
use
in
a
real
business.
We
were
fortunate
enough
to
have
access
to
a
Vice
President
at
an
insurance
agency,
who
provided
us
with
guidance
throughout
the
process
so
that
our
finished
product
represents
the
needs
of
an
actual
client.
We
were
also
provided
with
data
to
use
made
up
of
fictitious
information
to
help
us
understand
real-‐world
insurance
policies.
Lighthouse
Group
is
an
insurance
agency
located
in
West
Michigan
with
24
offices
in
the
region.
They
provide
services
to
over
5,000
clients
offering
Property
&
Casualty,
Benefits
and
Life
insurance.
Management
holds
several
meetings
throughout
the
year
to
keep
abreast
of
goals
with
the
Producers
as
well
as
the
insurance
Carriers
that
they
work
with,
though
much
of
the
data
is
gathered
manually
or
through
excel.
They
have
a
main
system
that
houses
all
of
the
quoting
and
policy
details
but
it
is
not
efficient
in
providing
the
figures
that
the
company
needs
to
effectively
run
the
business
and
maintain
the
goals
they
marked
at
the
beginning
of
the
year.
An
all
too
common
theme
is
for
Management
to
come
up
with
expectations
of
the
Producers
and
organization
as
a
whole
in
January,
only
to
realize
in
December
that
they
are
missing
key
targets.
With
Lighthouse
having
to
rely
on
Excel
spreadsheets
and
manual
reports,
they
are
not
only
doing
extra
work,
but
they
are
likely
going
to
miss
important
data
such
as
where
revenue
is
compared
to
the
goals
set
or
what
Niches
are
proving
to
be
most
profitable,
either
by
accident
or
because
it
is
too
much
effort
to
get
the
information.
The
main
policy
system
that
they
use
is
full
of
policy
data,
but
it
is
not
designed
to
input
targets,
provide
visualization
of
business
data
or
generate
reports.
A
comparable
system
with
a
provider
such
as
salesforce.com
is
extremely
expensive
(sometimes
at
$1,500
per
seat
per
year)
and
not
an
option
for
a
company
like
Lighthouse.
Though
the
tools
it
could
provide
would
help
solve
the
problem,
the
cost
just
is
not
feasible
for
them.
6. 6
Proposed
Solution
As
with
any
sales
organization,
there
are
always
ways
that
they
can
improve
their
profitability
and
our
system
will
assist
in
increasing
visibility
of
their
targets
and
sales
measures.
The
dashboard
system
serves
two
main
purposes.
The
first
is
to
give
the
Producers
and
Management
a
snapshot
of
where
they
are
at
toward
their
goals
year-‐to-‐date.
This
lets
them
know
with
the
click
of
a
button
where
they
stand
and
will
be
an
integral
part
of
their
keeping
on
track
throughout
the
year.
The
second
aspect
of
the
system
is
the
reporting
element.
At
any
time,
Management
can
run
a
detailed
report
with
a
variety
of
specifications
to
get
up-‐to-‐date
information
and
statistics.
The
main
objective
of
the
system
is
to
allow
the
members
of
the
company
to
keep
their
fingers
on
the
pulse
of
the
vital
pieces
of
information
that
inform
them
of
where
they
are
and
where
they
need
to
go.
These
measurements,
and
the
knowledge
of
them,
are
what
can
make
or
break
a
company.
A
note
from
our
contact,
Mike
Boros
(see
Appendix
A),
highlights
the
usefulness
and
necessity
of
a
system
such
as
the
one
we
created.
System
Actors
• Lighthouse
Group
Management
-‐
There
is
a
Manager
for
each
Department
(Property
&
Casualty,
Benefits
and
Life),
and
an
overall
Manager
for
the
organization.
Each
Manager
is
responsible
for
the
performance
of
the
Producers
in
their
department.
• Lighthouse
Group
Producers
-‐
The
Producers
are
the
employees
responsible
for
selling
insurance
policies
to
the
clients.
They
act
as
advisors
to
the
client
and
guide
them
to
find
the
right
insurance
coverage
with
the
right
Carrier
for
the
company.
They
have
goals
set
for
them
by
their
Manager
and
have
to
meet
certain
criteria
each
year.
• Lighthouse
Group
Account
Managers
-‐
The
Account
Managers
are
responsible
for
assisting
the
Producers
in
servicing
the
Clients.
They
complete
the
data
entry
for
the
Producers
and
act
as
the
first
line
of
contact
with
their
accounts.
7. 7
Business
Needs
and
Scope
There
were
different
features
we
thought
about
adding
but
ultimately
settled
on
the
scope
for
sales
tracking,
reporting
and
goal
setting.
Since
our
model
agency,
Lighthouse,
uses
their
main
system
to
provide
prospecting
and
financial
tools,
we
did
not
go
down
those
paths.
We
considered
a
customer
service
element
that
would
help
the
Producer
keep
track
of
important
dates
and
contacts,
but
thought
that
adding
this
feature
might
go
beyond
the
bounds
that
a
6-‐month
project
would
allow.
Our
main
concern
is
thus
on
what
written
accounts
Lighthouse
Producers
have
in
their
book
of
business
and
what
the
goals
were
for
the
current
year.
A
big
concern
for
Management
is
accountability
and
the
present
state
of
the
agency.
Our
system
provides
this
and
will
allow
Management
to
not
only
stay
on
top
of
their
Producers
but
also
to
identify
areas
that
need
immediate
attention.
We
were
able
to
identify
the
key
solutions
that
would
provide
Lighthouse
with
the
most
benefit:
• Goal
Setting
and
Tracking
-‐
An
element
of
the
system
that
is
currently
only
available
to
Lighthouse
through
a
manually
entered
Excel
spreadsheet
is
goal
setting
and
tracking.
Each
Producer
has
a
sales
goal
that
is
set
at
the
beginning
of
the
year.
In
order
to
move
past
unsophisticated
methods
of
tracking,
it
is
important
to
integrate
the
ability
for
Lighthouse
to
enter
specific
goals
each
year
for
the
Producers
and
then
be
able
to
keep
the
status
of
these
goals
at
the
forefront.
o Example:
A
Producer
has
a
goal
set
by
Management
of
$100,000
in
new
business
for
the
year.
The
system
will
show
this
goal
and
compare
it
to
the
new
business
that
was
entered
for
that
Producer
in
the
year.
• Visibility
of
Sales
Performance
-‐
The
main
system
that
Lighthouse
is
currently
using
to
house
client
information
is
effective
in
storing
the
data,
but
does
not
allow
Lighthouse
employees
to
easily
view
important
statistics
and
up-‐to-‐date
sales
figures.
It
is
incredibly
important
for
the
Producers
and
Management
to
know
where
they
stand
in
certain
areas
at
any
given
time.
For
example,
a
Producer
will
want
to
see
how
much
business
they
have
written
up
to
that
date
and
Management
is
going
to
want
to
see
how
the
agency
is
performing
overall,
perhaps
with
the
8. 8
percentage
of
new
business
accounts
that
were
written.
With
the
Dashboard
aspect
of
our
system,
an
employee
can
log
on
and
view
their
latest
data,
based
on
their
custom
settings.
Having
this
information
available
with
just
a
simple
login
will
ensure
that
the
Producers
and
Management
remain
informed
with
the
most
accurate
sales
data
possible.
o Example:
Management
can
view
their
Dashboard
at
any
given
moment
and
can
see
how
much
new
business
the
company
has
written
as
well
as
the
retention
percentage
of
existing
accounts.
• Useful
Analysis
of
Information
-‐
Using
the
information
gathered
and
stored
in
the
system,
Lighthouse
can
gain
insights
and
identify
patterns
that
can
inform
Management
to
make
data-‐
driven
business
decisions
and
leverage
it
for
its
competitive
advantage.
As
trends
and
relationships
in
the
data
are
uncovered,
Management
can
ask
new
questions
and
iterate
on
the
process
until
the
business
goal
is
met.
o Example:
Management
can
view
the
amount
of
new
business
for
a
certain
niche
(such
as
Agriculture
accounts)
and
discover
if
the
accounts
seem
to
be
profitable
and
should
be
pursued
more
heavily
in
the
future.
• Provide
Accurate
and
Timely
Reporting
Tools
-‐
Often,
Lighthouse
relies
on
numerous
offline
Excel
spreadsheets
owned
by
different
departments
to
understand
where
the
company
is
standing
in
terms
of
business
performance.
This
antiquated
method
is
inefficient
and
impedes
fast
decision
making
for
the
business.
With
the
new
system,
reporting
tools
are
available
for
Management
to
gain
accurate
and
timely
charts
in
order
to
help
them
plan
for
the
future.
o Example:
The
system
will
allow
for
a
wide
variety
of
reports
to
be
produced,
but
an
important
element
of
the
business
is
to
run
reports
for
the
Carriers
that
they
work
with.
The
Carriers
want
to
know
how
much
new
business
and
retention
they
have
with
Lighthouse
compared
with
the
goals
they
have
agreed
upon.
9. 9
II.
Project
Planning
Project
Staffing
Name Role Responsibilities
Stefanie
Boros Team
Member
&
Business
Analyst
Lead
Formed
the
idea
for
the
project
and
identified
the
appropriate
users,
their
needs
and
what
functionalities
were
important
for
the
system
to
have.
Amra
Iskander Team
Leader
&
Product
Management
Lead
Managed
the
system
development
timelines
and
developed
the
system
functionalities
for
Producer
and
Management.
Pallavi
Khadamkar Team
Member
&
Technical
Lead
Managed
and
implemented
the
security
and
session
management
features
for
the
system
and
facilitated
the
integration
of
the
codes.
Namita
Nair Team
Member
&
Technical
Lead
Implemented
system
functionalities
for
account
managers
and
designed
and
deployed
the
overall
system
architecture
on
the
cloud.
Yasin
Ceran Capstone
Advisor Gave
appropriate
guidance
for
the
direction
of
the
project
and
frequent
feedback
on
the
progress
made.
Project
Timeline
The
team
knew
the
importance
of
project
planning
and,
with
the
guidance
of
our
advisor,
Professor
Ceran,
set
up
as
realistic
a
timeline
as
possible
in
order
to
maintain
a
steady
and
forward-‐
moving
pace.
No
matter
how
skilled
a
team
or
how
impressive
a
product
is,
without
proper
planning,
there
is
only
a
recipe
for
disaster.
We
made
sure
that
we
considered
all
of
the
important
milestones
for
the
project
as
well
as
set
realistic
but
ambitious
deadlines
to
keep
us
on
track.
Phase Deliverables Activities Duration Actual
Initiation Project
Overview Introductory
Meeting Start
date:
1/7/2015
End
date:
1/7/2015
Start
date:
1/7/2015
End
date:
1/7/2015
10. 10
System
Concept
Development
Define
Scope
and
Boundaries
Develop
System
Boundary
Document
Start
date:
1/8/2015
End
date:
2/5/2015
Start
date:
1/8/2015
End
date:
2/5/2015
Planning Create
Project
Management
Plan
Chalk
Out
the
Plan
of
Actions Start
date:
2/6/2015
End
date:
2/28/2015
Start
date:
2/6/2015
End
date:
2/28/2015
Create
Schedule
for
Requirement
Gathering
Identify
Proper
Configurations
Required
to
Set
Up
Individual
Systems
(PCs)
Requirement
Analysis
Analyze
user
requirements
Identify
user’s
needs Start
date:
1/22/2015
End
date:
2/28/2015
Start
date:
1/22/2015
End
date:
2/28/2015
Create
requirements
definition
document
1.
The
document
would
capture
technical
solution.
2.
Number
of
hours
needed
to
accomplish
the
task.
3.
The
go
live
date
time.
Design Create
Design
Documents
Create
architecture
diagram
identifying
the
following
parameters:
Start
date:
1/22/2015
Start
date:
1/22/2015
11. 11
1.
Users
2.
Application
Interface
3.
Database
layer
End
date:
3/31/2015
End
date:
3/31/2015
Define
the
system
flow.
1.Create
use
cases,
data
flow
diagrams
and
structure
charts
to
chalk
out
the
user
and
application
interaction.
Create
a
prototype
of
the
entire
new
screens/user
interface
using
programming
language
and
review
for
approval.
Development Setup
Environment
Install
Apache
Server Start
date:
4/1/2015
End
date:
4/30/2015
Start
date:
4/1/2015
End
date:
4/30/2015
Install
mySQL
server
Check
database
connectivity
Implement
multi-‐user
case
Coding Start
development
of
user
interfaces
as
per
requirements
Start
Date:
4/8/2015
End
Date:
4/30/2015
Start
Date:
4/1/2015
End
Date:
5/15/2015
12. 12
Code
review Create
a
standard
checklist
for
code
review.
Start
Date:
4/22/2015
End
Date:
4/30/2015
Start
Date:
5/16/2015
End
Date:
5/23/2015
Conduct
code
review
to
make
it
compliant
as
per
the
checklist.
Testing Create
test
plans Create
unit
test
plans
inclusive
of
positive
and
negative
test
cases
based
on
the
functional
requirement
document
Start
Date:
5/1/2015
End
Date:
5/8/2015
Start
Date:
5/1/2015
End
Date:
5/8/2015
Perform
testing
on
development
environment
Perform
manual
testing
based
on
the
test
plan
Start
date:
5/8/2015
End
date:
5/22/2015
Start
date:
5/9/2015
End
date:
5/22/2015
In
case
of
failure
of
any
test
case,
redevelop
the
screen
and
execute
all
test
cases
again
unless
the
system
passes
all
of
them
Implementation Deployment Deploy
all
necessary
modified
or
newly
created
interfaces
on
the
production
server.
Start
date:
5/15/2015
End
date:
5/29/2015
Start
date:
5/23/2015
End
date:
6/6/2015
Test
the
changes
on
production
environment
Execute
all
test
cases
on
production
environment
to
check
the
new
interfaces
are
intact
and
running
as
expected
13. 13
Project
Methodology
In
our
project,
we
used
a
combination
of
methodologies
to
help
us
manage
the
process
and
complete
our
development
work.
• Waterfall
-‐
At
the
start
of
the
project
and
throughout
the
project,
we
used
a
sequential
design
process
known
as
the
waterfall
methodology
to
execute
our
development
work
in
different
phases.
The
project
went
through
a
phase
of
conception
where
we
gathered
the
business
needs
of
the
project.
At
this
stage
we
communicated
intensely
with
the
Lighthouse
team
to
understand
the
user
needs.
We
moved
on
to
the
analysis
and
design
stage
where
we
translated
the
requirements
gathered
into
physical
and
logical
design
documents
to
scope
out
the
system
requirements
further.
From
that,
we
started
the
code
implementation
stage
and
began
testing
once
the
different
components
of
the
program
were
integrated.
Once
the
system
was
implemented
on
the
cloud,
the
team
rigorously
tested
the
system
to
ensure
it
was
robust.
• Rapid
Prototyping
-‐
In
the
process
of
managing
the
project
using
the
waterfall
methodology,
we
created
software
prototypes
of
the
system
at
the
design
and
analysis
stage.
This
is
to
ensure
that
it
matches
the
requirements
that
we
have
gathered.
We
also
used
the
prototype
to
gather
feedback
from
the
users
so
that
we
can
improve
the
system
to
make
it
as
user-‐friendly
as
possible.
• Scrum
-‐
When
it
came
to
developing
the
code
for
the
system,
we
used
Scrum
to
schedule
priorities
for
each
sprint.
The
team
met
on
a
weekly
basis
to
select
the
tasks
and
scope
out
the
estimated
time
needed
to
complete
these
tasks.
In
these
meetings,
the
team
discussed
the
functionalities
and
identified
how
the
development
work
would
be
carried
out.
The
team
lead
would
send
out
the
sprint
tasks
to
the
entire
team.
At
the
end
of
each
sprint,
status
updates
were
sent
out
to
track
the
team’s
progress.
Risks
• Technical
Risks
-‐
The
hardware
must
satisfy
at
least
the
standard
system
requirements
such
as:
o Computer
and
Processor:
1
gigahertz
(GHz)
or
faster
x86
or
x64
bit
processor
with
SSE2
instruction
set
14. 14
o Memory
(RAM):
1
gigabyte
(GB)
RAM
(32-‐bit);
2
gigabytes
(GB)
RAM
(64-‐bit)
o Hard
Disk:
3.0
gigabytes
(GB)
available
o Display:
Graphics
hardware
acceleration
requires
a
DirectX10
graphics
card
and
a
1024
x
576
or
higher
resolution
monitor
o Operating
system:
Windows
operating
system
o .NET
version
3.5,
4.0
or
4.5
• Project
Risks
o Any
changes
in
requirements
could
delay
the
proposed
timeline
o The
Capstone
team
may
need
to
spend
time
learning
new
technologies
that
may
be
necessary
to
use
to
develop
the
system
o Scope
creep
-‐
Increase
in
development
time
will
result
in
insufficient
time
for
testing,
giving
rise
to
unknown
bugs
o Limited
access
to
Lighthouse
resources
Assumptions
• Technical
Assumptions
o MySQL
database
will
be
compatible
or
need
minimal
development
effort
to
interface
it
with
Apache
server
and
other
open
source
codes
o There
is
no
OS
preference
and
will
be
compatible
with
Windows
and
MAC
Operating
Systems
o Connection
to
the
server
is
always
readily
available
• Project
Assumptions
o The
new
system
will
be
implemented
by
June
2015
o The
new
system
will
be
a
prototype
o Lighthouse
will
take
responsibility
of
implementing
the
system
if
they
choose
to
adopt
the
new
system
o The
new
system
will
be
designed
on
the
capability
of
easy
configuration
and
minimal
customization
effort
to
implement
15. 15
Dependencies
• Wi-‐Fi
connectivity
for
the
team
to
complete
the
project
on
schedule
• Access
to
the
database
• Dependency
on
Capstone
MSIS
management
for
regular
feedback
and
verification
of
the
project
progress
and
for
necessary
information
and
documentation
related
to
the
system
and
database
• Access
to
an
up
and
running,
available
server
Project
Deliverables
The
team
has
provided
a
complete
and
functioning
system
as
well
as
this
report,
including
analysis
and
design
cases,
diagrams
and
charts,
test
cases
and
a
user
manual.
16. 16
III.
Analysis
Design
Requirements
Definition
Functional
Requirements
–
Process
Oriented
Account
Manager
1.
Search
for
existing
records
1.1
The
system
will
allow
Account
Managers
to
search
for
records
by
Company
Name,
Effective
Date,
Zip
Code
on
the
homepage.
1.2
The
system
will
display
a
maximum
of
5
search
results
of
the
last
added/searched/edited
records
on
the
homepage.
2.
Edit
existing
records
2.1
The
system
will
enable
Account
Managers
to
edit
existing
policy
or
line
of
business
(LoB)
information.
2.2
The
system
will
enable
Account
Managers
to
add
a
new
LoB.
2.3
The
system
will
enable
Account
Managers
to
delete
a
LoB.
3.
Renew
existing
records
3.1
The
system
will
enable
Account
Managers
to
select
the
renewal
button
on
the
homepage.
3.2
The
system
will
enable
Account
Managers
to
change
the
effective
and
expiration
dates.
3.3
The
system
will
enable
Account
Managers
to
modify
the
LoB
information.
4.
Cancel
existing
records
4.1
The
system
will
enable
Account
Managers
to
select
the
cancellation
button
on
the
homepage.
4.2
The
system
will
enable
Account
Managers
to
enter
the
cancellation
date.
5.
Delete
existing
records
5.1
The
system
will
enable
Account
Managers
to
select
the
delete
button
on
the
homepage.
5.2
The
system
will
verify
if
the
account
should
be
deleted.
6.
Add
new
records
6.1
The
system
will
enable
Account
Managers
to
enter
the
policy
information.
6.2
The
system
will
validate
the
policy
information
entered.
17. 17
6.3
The
system
will
store
the
policy
information
in
the
connect_lob_client
datastore.
6.4
The
system
will
enable
Account
Managers
to
enter
the
LoB
information.
6.5
The
system
will
validate
the
LoB
information
entered.
6.6
The
system
will
store
the
LoB
information
in
the
LoB
data
store.
Producer
1.
Display
goals
set
for
each
Producer
on
the
dashboard
1.1
The
system
will
display
goals
specific
to
the
Producer
on
the
goal
dashboard.
2.
Update
actual
results
2.1
The
system
will
calculate
the
actual
results
of
each
goal
and
display
the
values
against
the
goal
set
to
track
performance
progress.
3.
Display
charts
3.1
The
system
will
calculate
and
display
cross-‐sold
policies
by
number
of
accounts.
3.2
The
system
will
calculate
and
display
niche
breakdown
by
revenue.
3.3
The
system
will
calculate
and
display
niche
breakdown
by
commission.
3.4
The
system
will
calculate
and
display
niche
breakdown
by
number
of
accounts.
3.5
The
system
will
calculate
and
display
new
business
per
month.
4.
Display
Newsfeed
updates
4.1
The
system
will
display
newsfeed
updates
when
a
client
account
is
added,
renewed
or
cancelled.
4.2
The
system
will
enable
Producers
to
click
on
the
update
to
view
the
record
details.
5.
Run
reports
5.1
The
system
will
enable
Producers
to
select
pre-‐defined
reports
and
parameters
to
generate
reports.
Management
1.
Display
goals
set
for
company-‐wide
and
each
Producer
1.1
The
system
will
display
the
goals
specific
to
the
company
on
the
goal
dashboard.
1.2
The
system
will
display
the
goals
specific
to
each
Producer
on
the
goal
dashboard.
2.
Update
actual
results
18. 18
2.1
The
system
will
calculate
the
actual
results
of
each
goal
and
display
the
values
against
the
goal
set
to
track
performance
progress
for
the
entire
company.
2.2
The
system
will
calculate
the
actual
results
of
each
goal
and
display
the
values
against
the
goal
set
to
track
performance
progress
for
each
Producer.
3.
Display
charts
3.1
The
system
will
calculate
and
display
cross-‐sold
policies
by
number
of
accounts
for
the
entire
company
and
for
each
Producer.
3.2
The
system
will
calculate
and
display
niche
breakdown
by
revenue
for
the
entire
company
and
for
each
Producer.
3.3
The
system
will
calculate
and
display
niche
breakdown
by
commission
for
the
entire
company
and
for
each
Producer.
3.4
The
system
will
calculate
and
display
niche
breakdown
by
number
of
accounts
for
the
entire
company
and
for
each
Producer.
3.5
The
system
will
calculate
and
display
new
business
per
month.
4.
Run
Reports
4.1
The
system
will
enable
Management
to
select
pre-‐defined
reports
and
parameters
to
generate
reports.
5
Set
goals
5.1
The
system
will
enable
Management
to
set
company
wide
book
of
business
and
retention
goals.
5.2
The
system
will
calculate
new
business
goals
based
on
the
book
of
business
and
retention
goals.
5.3
The
system
will
calculate
each
Producer’s
recommended
book
of
business,
retention
and
new
business
goals
based
on
each
Producer’s
historical
performance
over
two
years.
5.4
The
system
will
calculate
new
Producers’
recommended
book
of
business,
retention
and
new
business
goals
based
on
a
typical
Producer’s
historical
performance
over
two
years.
5.5
The
system
will
enable
Management
to
edit
recommendations.
5.6
The
system
will
store
the
new
goals
set
in
the
Producer
data
store.
19. 19
Functional
Requirements
–
Process
Oriented
1.
The
system
will
contain
client
information.
2.
The
system
will
contain
LoB
information.
3.
The
system
will
contain
department
information.
4.
The
system
will
contain
carrier
information.
5.
The
system
will
contain
login
information.
6.
The
system
will
contain
niche
information.
7.
The
system
will
contain
producer
information.
8.
The
system
will
contain
LoB
history
information.
9.
The
system
will
contain
information
on
the
roles
of
each
employee.
10.
The
system
will
contain
policy
information.
Nonfunctional
Requirements
1.
Operational
1.1
The
system
should
run
on
any
internet-‐connected
device
with
a
web
browser.
1.2
The
system
should
be
able
to
work
on
any
web
browsers.
2.
Performance
2.1
The
system
should
support
50-‐100
concurrent
users.
2.2
The
system
should
be
updated
with
changes
made
to
the
database
immediately.
2.3
The
system
will
be
backed
up
through
the
cloud
every
night.
3.
Security
3.1
Passwords
will
be
encrypted
in
transmission
to
and
from
the
database.
3.2
Users
will
be
prompted
to
change
their
passwords
every
6
months.
3.3
Passwords
set
will
be
checked
for
their
strength
following
the
digit,
character,
upper
case,
lower
case
and
at
least
8
characters
standards.
3.4
Users
are
not
allowed
to
use
previous
3
passwords
used
when
users
are
resetting
or
changing
their
passwords.
20. 20
3.5
Data
in
flight
will
be
secured
through
https
implementation
between
the
web
server
and
database
server
in
the
cloud.
3.6
Users
can
log
in
from
another
location
when
a
session
is
in
use
and
the
system
will
log
the
user
out
from
the
previous
session
and
continue
the
new
session
in
the
new
location.
3.7
The
system
will
end
the
session
and
wipe
out
any
data
that
is
not
saved
if
the
session
is
idle
for
20
minutes.
3.8
No
user
can
access
the
data
of
another
user,
other
than
Management.
4.
Cultural
and
Political
4.1
The
system
will
adopt
the
Lighthouse
logo
and
color
scheme.
4.2
The
system
will
run
on
Amazon
Web
Service
(AWS)
cloud.
4.3
Customer
personal
information
is
protected
in
compliance
with
the
Data
Protection
Act.
21. 21
Use
Cases
Login
Use
Cases
Use
Case
Name:
ALL
–
Login
Actor:
All
Users
Description:
This
use
case
describes
how
a
user
would
be
able
to
log
in
to
the
system.
Trigger:
User
wants
to
log
in.
Type:
External
Preconditions:
• The
system
is
online
and
available.
• The
user
has
the
credentials
and
access
to
the
system.
Normal
Course: Information
for
Steps:
1. Go
to
login
page
2. System
accepts
username
from
the
user
3. System
accepts
password
from
the
user
4. System
validates
the
user
5. System
retrieves
username
from
the
login_info
datastore
6. System
retrieves
password
from
the
login_info
datastore
7. System
matches
the
username
against
the
7.1. Password
7.2. System
updates
the
login_status
to
1
in
the
login_info
datastore
8. System
checks
the
user
role
of
the
logged
in
person
9. System
retrieves
the
role_ID
of
the
record
from
login_info
datastore
10. System
redirects
the
user
to
the
admin
homepage
if
the
role_ID
is
1
11. System
redirects
the
user
to
the
producer
homepage
if
the
role_ID
is
2
12. System
redirects
the
user
to
the
management
homepage
if
the
role_ID
is
3
13. System
updates
the
login_info
datastore
14. System
updates
the
session_ID
in
login_info
datastore
I:
Username
I:
Password
I:
Username
I:
Password
O:
login_status
I:
role_ID
O:
session_ID
Postconditions:
• User
is
logged
in
to
the
system.
• DataStore
is
updated
with
the
login_status
and
session_ID.
Inputs Source Outputs Destination
Username
Password
Username
Password
role_ID
User
User
login_info
Datastore
login_info
Datastore
login_info
Datastore
login_status
session_ID
login_info
Datastore
login_info
Datastore
22. 22
Use
Case
Name:
ALL
-‐
Forgot
Password
Actor:
All
Users
Description:
This
use
case
describes
how
a
user
would
be
able
to
change
their
password
if
they
forgot
it.
Trigger:
User
forgets
password.
Type:
External
Preconditions:
• The
system
is
online
and
available.
• The
user
has
the
credentials
and
access
to
the
system.
Normal
Course: Information
for
Steps:
1. Go
to
login
page
2. If
session
already
exists
on
one
browser
2.1. System
3. Enter
email
address
into
field
4. Click
on
“Generate
Password”
5. Check
email
and
click
on
the
link
to
change
password
6. Enter
email
ID,
temporary
ID
(given
in
the
email),
new
password
and
confirm
password
7. Select
“submit”
8. Log
out
or
continue
into
system
Postconditions:
• Password
is
updated
in
the
database.
Inputs Source Outputs Destination
23. 23
Account
Manager
Use
Cases
Use
Case
Name:
Account
Manager
-‐
Add
Client
Actor:
Account
Manager
Description:
This
use
case
describes
how
an
Account
Manager
would
add
a
new
client.
Trigger:
Producer
writes
a
business
and
notifies
the
Account
Manager
to
add
it
to
the
system.
Type:
External
Preconditions:
• The
system
is
online
and
available.
• The
Producer
has
given
the
Account
Manager
the
complete
information
to
enter.
• The
Account
Manager
has
the
credentials
and
access
to
the
system.
Normal
Course: Information
for
Steps:
1. Account
Manager
receives
Client
information
from
the
Producer
2. Log
in
to
system
3. In
the
Home
Page
click
on
‘Add
New
Record’
button
3.1
Input
Client
Information
3.2
Input
Line
of
Business
3.3
Click
on
submit
3.4
May
have
multiple
Lines
of
Business
3.4.1
Click
“submit”
after
entering
each
Line
of
Business
4.
Display
Line
of
Business
Information
5.
Update
Line
of
Business
Information
5.1
Change
values
in
the
form
5.2
Click
on
Update
to
update
the
values
I:
Producer’s
Client
Info
I:
Client
Information
O:
Line
of
Business
Info
Postconditions:
• The
system
updates
the
database
with
Client
information.
• The
system
notifies
the
Producer
selected
via
news
feed
on
their
Dashboard
of
the
addition.
• Updated
information
will
be
reflected
in
reports.
Inputs Source Outputs Destination
Producer’s
Client
Info
Client
Information
User
User
Line
of
Business
Info client
data
store
connect_lob_client
data
store
24. 24
Use
Case
Name:
Account
Manager
-‐
Edit
Client
Actor:
Account
Manager
Description:
This
use
case
describes
how
an
Account
Manager
would
edit
an
existing,
active
Client
by
either
adding
another
Line
of
Business,
changing
policy
information
and/or
existing
Line
of
Business
information
or
adding/editing
loss
information.
Trigger:
Producer
notifies
the
Account
Manager
to
make
changes
to
a
Client
in
the
system.
Type:
External
Preconditions:
• The
system
is
online
and
available.
• The
Producer
has
given
the
Account
Manager
the
complete
information
to
enter.
• The
Account
Manager
has
the
credentials
and
access
to
the
system.
Normal
Course: Information
for
Steps:
1. Account
Manager
receives
Client
information
from
the
Producer
to
be
edited
2. Log
in
to
system
3. In
search
bar,
enter
name
of
Client
and
search
3.1
Search
first
by
full
name
3.2
Try
partial
name(s)
if
unsuccessful
4.
Select
“Edit”
next
to
the
Client
and
Term
being
edited
5a.
If
adding
Line
of
Business
5a.1
Select
“Add
Line
of
Business”
5a.2
Enter
Line
of
Business
details
5a.3
Select
“Add
LoB”
5a.4
Update
appropriate
fields
5a.5
Update
appropriate
fields
5a.6
Once
all
information
is
updated,
select
“Update”
5b.
If
editing
Account
information
5b.1
Update
appropriate
fields
5b.2
Once
all
information
is
updated,
select
“Update”
5c.
If
deleting
a
Line
of
Business
5c.1
Select
“Delete”
next
to
LoB
to
be
deleted
5c.2
A
confirmation
message
shows
5c.3
Click
“Ok”
to
delete
the
LoB
6.
Go
back
to
search
page
or
log
out
I:
User
info
I:
Search
info
I:
Line
of
business
info
O:
Line
of
business
info
I:
Account
info
O:
Account
info
Postconditions:
• The
system
updates
the
database
with
Client
information.
• Updated
information
will
be
reflected
in
reports.
Inputs Source Outputs Destination
User
info
Search
info
Line
of
business
info
Account
info
User
User
connect_lob_client
data
store
client
data
store
Line
of
business
info
Account
info
Account
info
connect_lob_client
data
store
client
data
store
client
data
store
25. 25
Use
Case
Name:
Account
Manager
-‐
Renew
Client
Actor:
Account
Manager
Description:
This
use
case
describes
how
an
Account
Manager
would
renew
an
existing,
active
Client
by
either
adding
another
Line
of
Business,
changing
policy
information
and/or
existing
Line
of
Business
information
or
adding/editing
loss
information.
Trigger:
Producer
notifies
the
Account
Manager
to
make
changes
to
a
Client
in
the
system.
Type:
External
Preconditions:
• The
system
is
online
and
available.
• The
Producer
has
given
the
Account
Manager
the
complete
information
to
enter.
• The
Account
Manager
has
the
credentials
and
access
to
the
system.
Normal
Course: Information
for
Steps:
1. Account
Manager
receives
Client
information
from
the
Producer
to
be
edited
2. Log
in
to
system
3. In
search
bar,
enter
name
of
Client
and
search
3.1
Search
first
by
full
name
3.2
Try
partial
name(s)
if
unsuccessful
4.
Select
“Renew”
next
to
the
Client
and
Term
being
edited
5.
If
editing
Line
of
Business
information
5.1
Update
appropriate
fields
5.2
Once
all
information
is
updated,
select
“Renew”
6.
Go
back
to
search
page
or
log
out
I:
Line
of
business
Information
O:Line
of
business
Information
Postconditions:
• The
system
updates
the
database
with
Client
information.
• Updated
information
will
be
reflected
in
reports.
Inputs Source Outputs Destination
Line
of
business
Information User Line
of
business
Information connect_lob_client
data
store
lob_history
data
store
26. 26
Use
Case
Name:
Account
Manager
-‐
Delete
Client
or
LoB
Actor:
Account
Manager
Description:
This
use
case
describes
how
an
Account
Manager
would
delete
an
existing,
active
Client
or
Line
of
Business.
Trigger:
Producer
notifies
the
Account
Manager
to
delete
the
Client
or
Line
of
Business
in
the
system.
Type:
External
Preconditions:
• The
system
is
online
and
available.
• The
Producer
has
given
the
Account
Manager
the
complete
information
to
enter.
• The
Account
Manager
has
the
credentials
and
access
to
the
system.
Normal
Course: Information
for
Steps:
1. Account
Manager
receives
Client
information
from
the
Producer
to
be
deleted
2. Log
in
to
system
3. In
search
bar,
enter
name
of
Client
and
search
3.1
Search
first
by
full
name
3.2
Try
partial
name(s)
if
unsuccessful
4.
If
deleting
entire
Client
4.1
Select
“Delete”
next
to
desired
Client
and
Term
4.2
A
confirmation
message
is
shown
4.3
Click
“Ok”
5.
Go
back
to
search
page
or
log
out
I:
Policy
information
Postconditions:
• The
system
updates
the
database
with
Client
information.
• Updated
information
will
be
reflected
in
reports.
Inputs Source Outputs Destination
Policy
information User
27. 27
Use
Case
Name:
Account
Manager
-‐
Cancel
Client
Actor:
Account
Manager
Description:
This
use
case
describes
how
an
Account
Manager
would
cancel
an
existing
Client.
Trigger:
Producer
notifies
the
Account
Manager
that
a
Client
has
cancelled
their
policy
and
it
needs
to
be
updated
in
the
system.
Type:
External
Preconditions:
• The
system
is
online
and
available.
• The
Producer
has
given
the
Account
Manager
the
complete
information.
• The
Account
Manager
has
the
credentials
and
access
to
the
system.
Normal
Course: Information
for
Steps:
1. Account
Manager
receives
Client
information
from
the
Producer
to
be
cancelled
2. Log
in
to
system
3. In
search
bar,
enter
name
of
Client
and
search
3.1
Search
first
by
full
name
3.2
Try
partial
name(s)
if
unsuccessful
4. Enter
the
cancellation
date
5. Select
“Cancel”
next
to
the
Client
being
cancelled
6. Confirm
cancellation
7. Policy
is
cancelled
8. Go
back
to
search
page
or
log
out
I:
Client
info
I:
Line
of
business
info
O:
Client
info
Postconditions:
• The
system
updates
the
database
with
Client
information.
• Updated
information
will
be
reflected
in
reports.
Inputs Source Outputs Destination
Client
info
Line
of
business
info
User Client
information connect_lob
client
data
store
lob_history_data
store
28. 28
Use
Case
Name:
Account
Manager
-‐
Sign
Up
User
Actor:
Account
Manager
Description:
This
use
case
describes
how
an
Account
Manager
would
add
a
new
user
to
the
system.
Trigger:
New
employee
is
hired
as
either
an
Account
Manager,
Producer
or
Manager.
Type:
External
Preconditions:
• The
system
is
online
and
available.
• The
Account
Manager
has
the
complete
information
to
enter.
Normal
Course: Information
for
Steps:
1. Account
Manager
receives
sign
up
information
from
the
new
employee
2. Log
in
to
system
3. Select
“Sign
Up”
4. Fill
in
user’s
email,
password
then
confirm
the
password
5. Select
“Submit”
6. Go
back
to
search
page
or
log
out
I:
Username/password
I:
Sign
up
info
O:
Sign
up
info
Postconditions:
• The
system
updates
the
database
with
sign
up
information.
• The
DB
Administrator
will
assign
the
appropriate
role
to
the
user
in
the
Roles
database.
Inputs Source Outputs Destination
Username
Password
Sign
up
info
Account
Manager
Account
Manager
Account
Manager
Sign
up
info Login_Info
database
29. 29
Producer
Use
Cases
Use
Case
Name:
Producer
-‐
Dashboard
Actor:
Producer
Description:
This
use
case
describes
how
a
Producer
would
utilize
the
dashboard
by
viewing
latest
updates
in
news
feed,
selecting
various
filters
for
charts
and
viewing/printing
the
charts.
Trigger:
Producer
wants
to
view
dashboard
data.
Type:
External
Preconditions:
• The
system
is
online
and
available.
• The
Producer
has
the
credentials
and
access
to
the
system.
• The
datastores
are
available
and
online.
Normal
Course: Information
for
Steps:
1. Log
in
to
system
2. The
system
updates
forecasted
and
actual
book
of
business,
retention
rates
and
new
business
3. The
system
checks
for
any
latest
additions
or
changes
to
new
and
existing
clients
and
displays
the
status
to
the
client
account
4. The
producer
selects
recently
updated
link
in
news
feed
to
view
client
details
5. The
system
will
display
client
data
6. The
Producer
selects
back
to
return
to
the
dashboard
7. The
system
will
update
and
display
cross-‐sell
pie-‐chart
8. The
system
will
update
and
display
niche
pie
chart
by
different
filters
8.1
Producer
selects
“Number”,
“Premium”
or
“Revenue”
to view
different
charts
8.2
Depending
on
the
selection,
“Number”,
“Premium”
or “Revenue”,
different
charts
will
be
displayed
9. The
system
will
update
and
display
new
business
chart
I:
User
info
O:
Producer
info
O:
News
feed
status
I:
Client
record
O:
Client
record
I:
Previous
dashboard
details
O:
Cross-‐sell
info
O:
Niche
info
I:
Type
of
niche
info
O:
Niche
charts
O:
New
business
info
Postconditions:
• Actual
performance
on
goals
dashboards
are
updated.
• News
feeds
are
updated.
• Cross-‐sell,
niche
breakdown
and
new
business
charts
are
updated.
Inputs Source Outputs Destination
User
info
Client
record
Previous
dashboard
details
Type
of
niche
info
Producer
Producer
Producer
Producer
Producer
info
News
feed
status
Client
record
Cross-‐sell
info
Niche
info
Niche
charts
New
business
info
Producer
database
Line
of
Business
database
Client
database
Department
database
Niche
database
Niche
database
Line
of
Business
database
30. 30
Use
Case
Name:
Producer
-‐
Reporting
Actor:
Producer
Description:
This
use
case
describes
how
a
Producer
would
run
a
report.
Trigger:
Producer
wants
to
generate
a
report.
Type:
External
Preconditions:
• The
system
is
online
and
available.
• The
Producer
has
the
credentials
and
access
to
the
system.
• The
datastores
are
available
and
online.
Normal
Course: Information
for
Steps:
1. Log
in
to
system
2. Go
to
Reporting
tab
3. System
displays
reporting
interface
4. Select
type
of
report
from
dropdown
menu
5. Select
start
date
6. Select
time
range
(depending
on
report
type)
7. Select
data
to
be
included
in
the
report
8. Run
report
9. Report
is
generated
I:
User
info
I:
Report
menu
O:
Report
parameters
I:
Report
type
I:
Date
info
I:
Time
interval
I:
Report
filters
I:
Report
activity
O:
Report
info
Postconditions:
• Report
will
be
generated
based
on
filters
selected.
Inputs Source Outputs Destination
User
info
Report
menu
Report
type
Date
info
Time
interval
Report
filters
Report
activity
Producer
Producer
Producer
Producer
Producer
Producer
Producer
Report
parameters
Report
info
Client,
Line
of
Business,
Niche
databases
Producer
31. 31
Management
Use
Cases
Use
Case
Name:
Management
-‐
Dashboard
Actor:
Management
Description:
This
use
case
describes
how
Management
would
utilize
the
dashboard
by
selecting
various
filters
for
charts
for
either
a
specific
producer
or
the
agency
as
a
whole.
Trigger:
Management
wants
to
view
dashboard
data.
Type:
External
Preconditions:
• The
system
is
online
and
available.
• The
Manager
has
the
credentials
and
access
to
the
system.
• The
datastores
are
available
and
online.
Normal
Course: Information
for
Steps:
1. Log
in
to
system
2. Select
to
view
data
for
a
specific
producer
or
the
agency
from
dropdown
menu
3. The
system
updates
forecasted
and
actual
book
value,
retention
rates
and
new
business
for
specific
Producer
or
the
agency
4. The
system
will
update
and
display
cross-‐sell
pie-‐chart
for
specific
Producer
or
the
agency
5. The
system
will
update
and
display
niche
pie
chart
by
different
filters
5.1
Management
selects
“Number”,
“Premium”
or
“Revenue”
to view
different
charts
5.2
Depending
on
the
selection,
“Number”,
“Premium”
or “Revenue”,
different
charts
will
be
displayed
or
specific Producer
or
the
agency
6. The
system
will
update
and
display
new
business
chart
for
specific
Producer
or
the
agency
I:
User
info
I:
Producer
info
O:
Producer
info
O:Cross-‐sell
info
O:
Niche
info
I:
Type
of
niche
info
O:
Niche
charts
O:
New
business
info
Postconditions:
• Actual
performance
on
goals
dashboards
are
updated
for
specific
Producer
or
the
agency.
• Cross-‐sell,
niche
breakdown
and
new
business
charts
are
updated
for
specific
Producer
or
the
agency.
Inputs Source Outputs Destination
User
info
Producer
info
Type
of
niche
info
Management
Management
Management
Producer
info
Cross-‐sell
info
Niche
info
Niche
charts
New
business
info
Producer
database
Department
database
Niche
database
Niche
database
Line
of
Business
database
32. 32
Use
Case
Name:
Management
-‐
Reporting
Actor:
Management
Description:
This
use
case
describes
how
Management
would
run
a
report.
Trigger:
Management
wants
to
generate
a
report.
Type:
External
Preconditions:
• The
system
is
online
and
available.
• The
Management
has
the
credentials
and
access
to
the
system.
Normal
Course: Information
for
Steps:
1. Log
in
to
system
2. Go
to
Reporting
tab
3. System
displays
reporting
interface
4. Select
type
of
report
from
dropdown
menu
5. Select
start
date
6. Select
time
range
(depending
on
report
type)
7. Select
data
to
be
included
in
the
report
8. Run
report
9. Report
is
generated
I:
User
info
I:
Report
menu
O:
Report
parameters
I:
Report
type
I:
Date
info
I:
Time
interval
I:
Report
filters
I:
Report
activity
O:
Report
info
Postconditions:
• Report
will
be
generated
based
on
filters
selected.
Inputs Source Outputs Destination
User
info
Report
menu
Report
type
Date
info
Time
interval
Report
filters
Report
activity
Management
Management
Management
Management
Management
Management
Management
Report
parameters
Report
info
Client,
Line
of
Business,
Niche
databases
Management
33. 33
Use
Case
Name:
Management
-‐
Goal
Setting
Actor:
Management
Description:
This
use
case
describes
how
management
would
set
goals
for
a
producer.
Trigger:
It’s
the
beginning
of
the
year
and
management
wants
to
set
goals
for
his/her
producers.
Type:
External
Preconditions:
• The
system
is
online
and
available.
• Management
has
the
credentials
and
access
to
the
system.
• The
datastores
are
available
and
online.
Normal
Course: Information
for
Steps:
1. Log
in
to
system
2. Go
to
Goal
Setting
tab
3. Management
enters
book
of
business
and
retention
goals
for
entire
company
4. System
calculates
new
business
goal
based
on
book
of
business
and
retention
goals
entered
5. System
calculates
book
of
business,
retention
and
new
business
goals
for
each
producer
6. Management
accepts
the
goals
or
make
changes
to
them
7. Goals
set
are
saved
I:
User
info
I:
Goal
menu
I:
Goal
amount
O:
New
business
value
O:
Goal
info
I:
Goal
modification
O:
Goals
set
Postconditions:
• Dashboard
data
will
be
updated
to
reflect
goals
where
applicable.
• Goals
are
saved
in
the
producer
datastore.
Inputs Source Outputs Destination
User
info
Goal
menu
Goal
amount
Goal
modification
Management
Management
Management
Management
New
business
value
Goal
info
Goals
set
Management
Management
Producer
datastore
47. 47
Data
Dictionary
• Data
Structures
Client
datastore
-‐
The
Client
datastore
will
store
information
on
each
Client
such
as
Client’s
name,
email,
zip,
SIC
Code
and
updates
to
be
displayed
on
the
newsfeed
of
a
Producer’s
dashboard.
Client
ID
Client
Name
Email
Zip
Display
Newsfeed
Niche
ID
SIC
Code
Connect
Line
of
Business
(LoB)
Client
datastore
-‐
The
Connect
Line
of
Business
(LoB)
Client
datastore
will
contain
policy
information
on
each
Client
such
as
premium,
commission,
losses,
effective
and
expiration
dates.
Connect
ID
Client
ID
Carrier
ID
LoB
ID
48. 48
Producer
ID
Premium
Commission
Losses
As
of
Date
Effective
Date
Expiration
Date
LoB
Status
LoB
datastore
-‐
The
LoB
datastore
will
contain
LoB
information
that
is
associated
with
each
Client
record.
LoB
ID
LoB
Name
Carrier
datastore
-‐
The
Carrier
datastore
will
contain
Carrier
information
details
such
as
Carrier
name.
Carrier
ID
Carrier
Name
49. 49
Niche
datastore
-‐
The
Niche
datastore
will
contain
information
on
Niche
details
such
as
the
range
of
SIC
codes
and
Niche
names.
Niche
ID
Starting
Number
Ending
Number
Niche
Name
Department
datastore
-‐
The
Department
datastore
will
contain
Department
information
such
as
Department
name.
Department
ID
Department
Name
Producer
datastore
-‐
The
Producer
datastore
has
information
on
the
goals
set
for
each
Producer
including
book
of
business
value
and
retention
rates.
Producer
ID
Producer
Name
Book
Value
Retention
Rate
Last
Updated
50. 50
Department
ID
Roles
datastore
-‐
The
Roles
datastore
has
information
on
each
user’s
role
in
the
agency
to
direct
each
user
to
the
homepage.
Roles
ID
Role
Name
LoB
History
datastore
-‐
The
LoB
History
datastore
contains
information
on
previous
Client
account
records
when
a
Client
has
been
updated
as
renewed
or
cancelled.
LoB
History
ID
Client
ID
Carrier
ID
LoB
ID
Producer
ID
Premium
Commission
Losses
As
of
Date
Effective
Date
51. 51
Expiration
Date
LoB
Status
Department
ID
Timestamp
Login
Info
datastore
-‐
The
Login
info
datastore
stores
all
employees’
information
such
username,
current
and
old
passwords
and
sessions.
User
ID
Username
Email
Roles
ID
Current
Password
Temporary
Password
Old
Password
1
Old
Password
2
Login
Status
Session
ID
Password
Date
52. 52
• Data
Elements
# Data
Element Description Data
Type Base/Derived Data
Element
Owner
1 Client
ID Identify
client
record int(5) Base Client
datastore
2 Client
Name Name
of
client varchar(25) Base Client
datastore
3 Email Client’s
email varchar(25) Base Client
datastore
4 Zip Client’s
zip
code int(5) Base Client
datastore
5 Display
Newsfeed
Checks
for
any
updates
for
a
client
account
and
display
updates
on
news
feed
varchar(255) Base Client
datastore
6 Niche
ID Identify
niche int(5) Base Client
datastore
7 SIC
Code Classifies
industry
by
standard
codes
int(4) Base Client
datastore
8 Connect
ID Identify
policy
information
with
client
account
int(5) Base Connect
LoB
Client
datastore
9 Client
ID Identify
client
record int(11) Base Connect
LoB
Client
datastore
10 Carrier
ID Identify
carrier
information
int(5) Base Connect
LoB
Client
datastore
11 LoB
ID Identify
LoB
information int(10) Base Connect
LoB
Client
datastore
12 Producer
ID Identify
producer
information
int(5) Base Connect
LoB
Client
datastore
13 Premium Premium
information
for
client’s
LoB
float(5) Base Connect
LoB
Client
datastore
14 Commission Commission
information
for
each
policy
sold
float(255) Base Connect
LoB
Client
datastore
15 Losses Losses
written
for
each
policy
issued
by
a
carrier
float(5) Base Connect
LoB
Client
datastore
53. 53
16 As
of
Date Losses
written
at
that
particular
time
date Base Connect
LoB
Client
datastore
17 Effective
Date Inception
date
of
the
policy
date Base Connect
LoB
Client
datastore
18 Expiration
Date
Expiration
date
of
the
policy
date Base Connect
LoB
Client
datastore
19 LoB
Status Identify
if
LoB
is
new,
renewed
or
canceled
varchar(255) Base Connect
LoB
Client
datastore
20 Last
Edited Identify
when
the
client
information
was
edited
date Base Connect
LoB
Client
datastore
21 LoB
ID Identify
LoB int(5) Base LoB
datastore
22 LoB
Name Information
on
type
of
LoB
varchar(255) Base LoB
datastore
23 Carrier
ID Identify
carrier int(11) Base Carrier
datastore
24 Carrier
Name Information
on
type
of
carrier
varchar(255) Base Carrier
datastore
25 Niche
ID Identify
niche int(10) Base Niche
datastore
26 Starting
Number
Classify
SIC
Code
according
to
standard
industry
practice
int(5) Base Niche
datastore
27 Ending
Number
Classify
SIC
Code
according
to
standard
industry
practice
int(5) Base Niche
datastore
28 Niche
Name Information
on
type
of
niche
varchar(50) Base Niche
datastore
29 Department
ID
Identify
department int(11) Base Department
datastore
30 Department
Name
Information
on
type
of
department
varchar(255) Base Department
datastore
31 Producer
ID Identify
producer int(5) Base Producer
datastore
32 Producer
Name
Producer
name varchar(25) Base Producer
datastore
54. 54
33 Book
Value Book
value
goal
set
for
producer
int(15) Base Producer
datastore
34 Retention
Rate
Retention
rate
goal
set
for
producer
int(5) Base Producer
datastore
35 Last
Updated Displays
when
goals
was
last
updated
date Base Producer
datastore
36 Department
ID
Identify
department int(5) Base Producer
datastore
37 Roles
ID Identify
role int(4) Base Roles
datastore
38 Role
Name Information
on
type
of
role
for
each
employee
varchar(255) Base Roles
datastore
39 LoB
History
ID
Identify
past
LoB
records int(11) Base LOB
History
datastore
40 Client
ID Identify
client int(5) Base LOB
History
datastore
41 Carrier
ID Identify
carrier int(5) Base LOB
History
datastore
42 LoB
ID Identify
LoB int(5) Base LOB
History
datastore
43 Producer
ID Identify
producer int(5) Base LOB
History
datastore
44 Premium Premium
information
for
client’s
LoB
int(25) Base LOB
History
datastore
45 Commission Commission
information
for
each
policy
sold
int(25) Base LOB
History
datastore
46 Losses Losses
written
for
each
policy
issued
by
a
carrier
int(25) Base LOB
History
datastore
47 As
of
Date Losses
written
at
that
particular
time
date Base LOB
History
datastore
48 Effective
Date Inception
date
of
the
policy
date Base LOB
History
datastore
49 Expiration
Date
Expiration
date
of
the
policy
date Base LOB
History
datastore
50 LoB
Status Identify
if
LoB
is
new,
renewed
or
canceled
varchar(255) Base LOB
History
datastore
55. 55
51 Department
ID
Identify
department int(5) Base LOB
History
datastore
52 Timestamp Identify
timestamp
of
record
timestamp Base LOB
History
datastore
53 User
ID Identify
user int(11) Base Login
Info
datastore
54 Username Name
of
user varchar(255) Base Login
Info
datastore
55 Email Email
address
of
user varchar(255) Base Login
Info
datastore
56 Roles
ID Identify
role int(4) Base Login
Info
datastore
57 Current
Password
Stores
current
password
of
user
varchar(255) Base Login
Info
datastore
58 Temporary
Password
Stores
temporary
password
of
user
varchar(255) Base Login
Info
datastore
59 Old
Password
1
Stores
old
password
1 varchar(255) Base Login
Info
datastore
60 Old
Password
2
Stores
old
password
2 varchar(255) Base Login
Info
datastore
61 Login
Status Identify
if
session
is
active int(1) Base Login
Info
datastore
62 Session
ID Identify
session varchar(255) Base Login
Info
datastore
63 Password
Date
Date
password
is
created date Base Login
Info
datastore
56. 56
IV.
Design
Phase
Architecture
Design
• Multi-‐Tenant
Architecture
The
system
supports
a
multi-‐tenant
architecture.
We
evaluated
numerous
options
such
as:
o Using
a
domain
website
hosting
service
o Setting
up
the
system
in
the
cloud
o Using
a
laptop
as
a
local
host
server
and
distributing
the
laptop’s
IP
In
our
analysis,
we
decided
to
configure
a
cloud-‐based
system
because
of
the
numerous
advantages
it
offers.
The
advantages
of
using
a
cloud-‐based
environment
are
that
it
provides
high
computing
performance,
scalability
to
our
system
fairly
quickly
and
provides
added
security
features
such
as
backup
and
recovery
of
data,
archiving
of
data
and
disaster
recovery.
In
addition,
the
cloud-‐
based
environment
has
a
transaction
management
capability
built
in
that
ensures
a
transaction
is
successful
when
a
block
of
MySQL
statements
is
executed
successfully.
With
this
automated
transaction
management
functionality,
any
failure
in
a
statement
should
cause
the
system
to
be
‘rolled
back’
to
its
pre-‐existing
state.
This
prevents
any
data
linkage
or
corruption
problems.
The
system
is
hosted
using
the
Amazon
Elastic
Compute
Cloud
[EC2],
which
is
a
web
service
that
provides
Elastic
computing
capacity.
The
system
is
implemented
using
a
three-‐tier
architecture
with
web
server,
app
server
and
a
database
server.
The
application
server
is
configured
of
Amazon
Linux
AMI.
The
database
server
is
implemented
using
Amazon
Relational
Data
Store,
which
are
instances
of
MySQL
running
on
EC2
platform.
The
database
can
be
accessed
and
managed
through
by
both
SSHing
through
the
terminal
and
through
MS
Workbench.
We
use
the
On-‐Demand
DB
Instances
let
the
organization
pay
for
compute
capacity
by
the
hour
with
no
long-‐term
commitments.
This
frees
the
organization
from
the
costs
and
complexities
of
planning,
purchasing,
and
maintaining
hardware
and
transforms
what
are
commonly
large
fixed
costs
into
much
smaller
variable
costs.
Currently
the
system
uses
the
AWS
Free
Tier
for
Amazon
RDS
offer
provides
free
use
of
Single-‐AZ
Micro
DB
instances
running
MySQL,
PostgreSQL,
Oracle
("Bring-‐Your-‐Own-‐License
(BYOL)"
licensing
model)
57. 57
and
SQL
Server
Express
Edition.
The
free
usage
tier
is
capped
at
750
instance
hours
per
month.
Customers
also
receive
20
GB
of
database
storage,
10
million
I/Os
and
20
GB
of
backup
storage
for
free
per
month.
• Why
EC2?
o Elastic
capacity
-‐
The
capacity
of
the
servers
can
be
increased
or
decreased
as
per
need
and
the
payment
can
be
made
according
to
the
usage.
This
eliminates
the
purchase
of
large
and
expensive
hardware
devices.
o Regions
and
availability
zones
-‐
The
instances
can
be
launched
in
separate
regions
according
to
the
location
of
the
organization.
Each
Region
has
multiple
availability
zones
and
by
launching
the
application
in
multiple
availability
zones,
the
application
is
protected
from
failure
from
a
single
location.
o Storage
-‐
The
Amazon
Elastic
Block
Storage
provides
instances
with
persistent,
block
level
storage.
They
are
essentially
hard
disks
that
can
be
attached
to
a
running
instance.
Amazon
Simple
Storage
Service
stores
the
backed
up
data.
The
system
backs
up
the
data
once
per
day.
o Security:
§ Security
Groups
-‐
The
security
groups
provided
by
Amazon
controls
the
access
to
instances.
The
security
group
for
web
servers
only
allows
access
from
hosts
over
TCP
on
ports
80
and
443
and
from
instances
in
the
App
Servers
security
group
on
Port
22(SSH)
for
direct
host
management.
The
security
group
for
the
app
servers
allows
access
from
the
Web
Servers
security
group
for
web
requests,
and
from
the
corporate
subnet
over
TCP
on
port
22
(SSH)
for
direct
host
management.
The
user’s
support
engineers
could
log
directly
into
the
application
servers
from
the
corporate
network,
and
then
access
the
other
instances
from
the
application
server
boxes.
The
DB
Servers
security
group
permits
only
the
App
Servers
security
group
to
access
the
database
servers.
§ Encrypted
data
storage
-‐
Customers
can
have
the
data
and
objects
they
store
in
Amazon
EBS,
Amazon
S3,
Glacier,
Redshift,
and
Oracle
and
SQL
Server
RDS
encrypted
58. 58
automatically
using
Advanced
Encryption
Standard
(AES)
256,
a
secure
symmetric-‐key
encryption
standard
using
256-‐bit
encryption
keys.
• Why
RDS?
o Scalable
storage
-‐
You
can
scale
the
computer’s
and
storage
resources
available
to
the
organization’s
database
to
meet
your
application’s
needs
using
the
Amazon
RDS
API
or
the
AWS
Management
Console.
With
Amazon
RDS
Provisioned
IOPS
storage
with
Amazon
RDS
for
MySQL,
Oracle,
or
PostgreSQL,
the
organization
can
provision
and
scale
the
storage
up
to
3TB
and
IOPS
to
up
to
30,000.
Note
that
maximum
realized
IOPS
will
vary
by
engine
type.
In
addition,
for
the
MySQL,
PostgreSQL,
and
Amazon
Aurora
database
engines,
one
can
also
associate
one
or
more
read
replicas
with
your
database
instance
deployment,
enabling
you
to
scale
beyond
the
capacity
of
a
single
database
instance
for
read-‐heavy
workloads.
o Rapid
Provisioning
and
High
Availability
-‐
Amazon
RDS
has
multiple
features
that
enhance
reliability
for
critical
production
databases,
including
automated
backups,
DB
snapshots,
automatic
host
replacement,
and
Multi-‐AZ
deployments.
Amazon
RDS
runs
on
the
same
highly
reliable
infrastructure
used
by
other
Amazon
Web
Services.
o Security
-‐
The
data
at
rest
is
encrypted
by
default.
Providing
customized
encryption
by
using
Amazon
Key
Management
System
can
further
extend
it.
Automatic
backups
can
be
created
using
snapshots
of
the
database
within
any
desired
time
interval.
• Encryption
In
designing
the
security
of
our
system,
we
made
sure
that
the
username
and
password
of
each
user
is
encrypted
to
protect
against
any
malicious
attacks.
We
evaluated
multiple
encryption
algorithm
techniques
and
narrowed
it
down
to
MD5,
SHA1
and
CRYPT.
MD5
to
provide
the
first
layer
of
password
protection.
MD5
is
vulnerable
to
collision
attacks
because
decryption
applications
are
now
available
online
to
crack
passwords.
Therefore,
we
added
SHA1
as
an
extra
encryption
security
layer
to
ensure
that
the
passwords
are
not
easily
decrypted
by
undesired
users.
In
recent
times,
new
hacking
technology
has
popped
up
to
decrypt
SHA1.
MD5
and
SHA1
were
used
because
they
are
