Insurance Services

1
(No Transcript)
2
? Our Objectives

• Provide a solid foundation for developing use
  cases
• Provide a best practice for capturing and
  documenting all requirements
• Illustrate the value of good requirements
  practices (client case study)

3
? What is a Use Case?
A Use Case is a written description of the way in
which a user expects to interact with the system
under development (also known as the SuD) to
accomplish a particular goal. The description may
be written either as a narrative describing the
users interaction, or as a stepwise
procedure. That series of steps that describe the
users uninterrupted path to the goal is called
the main success scenario. Exceptions to the main
success scenario are referred to as use case
extensions. Use cases provide the context for
functional and non-functional requirements to
reduce or eliminate ambiguity.
4
Elements of a Complete Use Case
5
? Actors and their Roles
Each entity that interacts with the SuD in the
pursuit of a particular goal is called an
actor. An actor may have multiple goals within
the SuD. An actor is usually a person, but may be
related software, office equipment, a batch
process or the SuD itself. Each goal becomes the
foundation for each use case.
6
? Use Case Development

• Identify actors
• Identify their goals
• Draft use case description
• Draft main success scenario
• Define preconditions/post conditions
• Identify extensions
• Tie requirements to use case

7
? Identify Actors 1
Policy Issuance Applicant, CSR, Underwriter,
Agent/Broker, UW Manager, UW Assistant,
SuD. Claims Agent, Adjuster, Claims Manager,
Insured, Independent Adjuster, Salver,
Administrator, Claimant, Subrogation Expert,
Finance Manager, SuD. Producer Management Agency
Administrator, Marketing Staff, SuD.
8
? Identify Actors Goals 2
Policy Issuance Take application, rate, quote,
underwrite, bind, issue, renew, non-renew,
cancel, report. Claims FNOL, verify coverage,
investigate claim, pay claim, recover loss
through subrogation, salvage or reinsurance,
Producer Management Add producer, appoint
producer, add or modify commission plan, manage
licenses.
9
? Draft Use Case Description 3
At this stage, we write a short narrative to
describe how the use case unfolds and what it
accomplishes. FNOL UC-CL1 (Intake FNOL) A CSR
records information from a claimant or their
representative regarding a loss, including
policyholder information, loss description and
other relevant information.
10
? Draft Main Success Scenario 4
The main success scenario is the best case
series of steps undertaken by an actor to
accomplish the goal. UC-CL1 (Intake FNOL) 1.
CSR clicks Enter New Claim button 2. CSR
verifies coverage 2.1 SuD returns option menu 3.
CSR selects enter new claimant 3.1 SuD
presents FNOL screen 4. CSR enters claimant
contact information 5. CSR clicks submit
button 5.1 SuD returns claimant entered
confirmation screen 5. ...
? Verb (Action)
Noun (Actor) ?
11
? Define Preconditions/Post conditions 5
Preconditions describe the state the environment
must be in for the main success scenario to
initiate. UC-CL1 (Intake FNOL) Precondition The
CSR is logged in. Post conditions describe the
state of the environment upon attainment of the
goal. UC-CL1 (Intake FNOL) Post condition SuD
returns confirmation screen.
12
? Identify Extensions 6
Extensions are alternative paths to the goal, or
paths to an aborted pursuit of the goal, due to
variations in the main success scenario. UC-CL1
(Intake FNOL) 1. CSR clicks Enter New Claim
button 2. CSR verified coverage 2.1 SuD returns
option menu 3. CSR selects enter new
claimant 3.1 SuD presents client contact entry
screen 4. CSR enters insured contact
information 5. CSR clicks submit button 5.1 SuD
returns client entered confirmation screen 6.
... Extensions 5.a. CSR misses required
field 1. SuD returns entry screen with missing
field highlighted 2. CSR enters missing
information 3. Go to 5.
? insertion point
? extension condition
alternate steps ?
13
? Tie Requirements to Use Case 7
By tying requirements to use cases, we introduce
the context in which the requirement is being
applied, removing ambiguity. UC-CL1(Intake
FNOL) 1. CSR clicks Enter New Claim button 2.
CSR verifies coverage 2.1 SuD returns option
menu 3. CSR selects enter new claimant 3.1
... Referenced requirements REQ-CL4 Coverage
Verification SuD will provide a search capability
on new claim entry to check/verify whether risk
is covered under existing policy. If not covered,
SuD prints denial letter.
14
? Functional vs. Non-Functional Requirements

• Functional requirements specify a function the
  system must be able to perform
• Describes a specific behavior The system shall
  display a summary of all policies in force within
  a user-defined period.
• Functional requirements include
• Business Rules
• Transaction modifications
• Administrative functions
• Authorization
• External interfaces
• Reporting

15
? Functional vs. Non-Functional Requirements

• Non-functional requirements are statements of how
  the system must behave, i.e., it is a constraint
  put upon system behavior.
• Non-functional requirements specify all remaining
  requirements not covered by the functional
  requirements The system shall display report
  results within 30 seconds...
• Non-functional requirements include
• Performance
• Response time
• Throughput
• Capacity
• Maintainability, etc.

16
? Gathering Requirements

• Review use cases to identify processes impacted
  by the system under development.
• Assemble cross-departmental groups of
  stakeholders within a given process, including
  stakeholders from input and output processes.
• Use guides to solicit requirements and use a
  knowledgeable moderator.
• Record requirements in a uniform manner and gain
  agreement.
• Record open issues or points of contention.
• Move on!

17
? Gathering Requirements

• Provide alternative venues for gathering
  requirements
• Blogs
• Wikispaces
• Dedicated email addresses
• Distribute documented requirements to
  stakeholders for validation and comment
• Finalize requirements
• Match requirements to use cases
• Use consistent structure when writing a
  requirement The system shall

18
? Gathering Requirements

• Using a requirements gathering software tool

19
? Critical Points
A single requirement may be associated with
multiple use cases multiple requirements may be
associated with a single use case. Dont get
caught up in too much detail capture the essence
of the workflow and let the requirements drive
the details. Be consistent in the use of
terminology. Organizing the effort is 80 of the
battle. Using the appropriate software tool will
save time, money, frustration. Requirements are
voluminous delegation to appropriate staff
members for validation is key.
20
? Resources
Cockburn, Alistair. (2000). Writing effective use
cases. Robertson, Suzanne and James C. Robertson.
(2006). Mastering the requirements process (2nd
Edition). The Journal of Insurance Operations.
21
? Case Study