Terminology used in P&C Insurance


Quote ID Quote Number
Quote Premium Premium offered in the quote document
Quote Issue Date Quote issuance date
Quotation Status Status of the quote
Issuance Type Quote is new or renewed
Policy ID Policy Number
Coverage ID Coverage Number
Policy Issuance Date Policy Issue Date
Policy Expiration Date Policy Expiration Date
Policy Effective Date Policy Effective Date
Endorsement ID Policy Endorsement Number
Transaction Date Policy Transaction Date
Endorsement Type Endorsement Type ( Add coverage, delete coverage, Cancel etc.)
Postal Code - Riskitem Insured vehicle Postal Code
Country Country of risk location
State State where the risk is located
Policy Tenure ( in Years ) Duration of the policy
Gross Written Premium Total premium written and assumed by insurer before deductions. When a company closes a contract to provide insurance against loss, the revenues (premiums) expected to be received over the life of the contract are called gross premiums written.
Net Written Premium Insurance companies often purchase reinsurance to protect themselves against the risk of a loss above a certain threshold; the cost of reinsurance is deducted from gross premiums written to arrive at "net premiums written".
Net Earned Premium That portion of a policy’s premium that applies to the expired portion of the policy. Although insurance premiums are often paid in advance, the insurers typically ‘earn’ the premium at an even rate throughout the policy term.
Coverage Type Type of coverage being applied
Currency Code/ID Policy or Coverage currency
Sum Insured Sum Insured amount at Policy and Coverage level ( Indicates the value of the vehicle to paid in case of total loss )
Deductible Type Policy deductible amount in case of loss or Excess amount
Sum Insured with Combined Single Limit Across Risk Items A policy could have multiple coverages or risk units and respective liability limits /sum insured set for each coverage/risk unit. Combined Single Limit is the single dollar limit that applies to any combination of damage liability claims instead of split limits or as a maximum limit to otherwise applicable split limits where separate dollar amounts apply to each coverage/risk unit.
Payment Method Premium Payment method ( office, branch, online etc. )
Discount Premium discount percentage offered
Commission Comission amount on the policy
Bonus Amount Bonus amount on the policy
Branch Policy issued branch
Service Policy Service as in the policy document
Pay Plan Premium payment plan ( monthly, quarterly, annual etc. )
Third Party Service Third Party Services utilized
Third Party Services Premium Third Party Services Premium amount
Reinsurance Indicator Policy indicator for any reinsurance contract
Reinsurer Name Resinsurer
PERCENTAGE OF AMOUNT ALLOCATED FOR REINSURANCE Chubb's share of reinsurance contract
Acquisition Costs Costs incurred by Chubb in order to acquire/sell a policy
Underwriting Expense Costs and expenditures associated with underwriting activity 
Policy Fee Flat fee to offset any expense incurred for issuing or registering the policy
Installment Fee Installment fee charged for the policy
Issuance Type Policy indicator for new or renewal
Major Class Name The type of insurance coverage (ex. workers compensation, bodily injury, employment practice).
Other Load Percentage Accounts for risks that are specific or unique to the insured for uncertainty that is not already accounted for in the standard insurance rates.
Producer Type Type of Producer (Agent, Broker, Bank etc.)
Producer Type Description Description of the type pf producer
Producer ID or number to uniquely identify a producer
Producer Location ( Country, State, City, Postal Code ) Producer Location information
channel Channel (Branch, Office, Online etc.)
Territory Poducer's territory name , region
SALES PERSON Producer Account or Sales Rep
Claim ID Claim number
Claim Status Claim status - Open, Processing, Closed, Closed without payment etc.
Net Paid Loss Loss amount paid
Loss Claim Amount Estimate Reserve amount set aside for the claim
Salvage amount Salvage amount determined for the loss
Recovery Subrogation Amount Subrogration amount for the claim
Incurred Losses Total loss paid for the claim
ALLOCATED LOSS ADJUSTMENT EXPENSES Expenses that are assignable to specific claims.
ULDF Incurred Loss Development Factor
UNALLOCATED LOSS ADJUSTMENT EXPENSES Expenses those are general in nature, which cannot be assigned to a particular claim
Deductible Claim deductible amount
RiskLocation ID Loss Location reported
LOSS  DESCRIPTION Loss Type information
Cause of Loss Cause of Loss
Claim Occurance Date Date the incident occurred
FIRST NOTICE OF LOSS DATE Date the incident was reported to Chubb
Claim Registered Date Date the incident was registered to Chubb
Claim Transaction Date Claim Transaction time
GAAP Reporting Year - Month Accounting year - month
Underwriting YYYY-MM Underwriting year - month
Claim Transaction Type Description Claim description
Payment Date Date of Loss payment made to customer
Adjuster Adjuster assigned to the claim - Individual, Company
Total Loss Claims total loss indicator ( Y/N )
Currency ID Claim currency
Customer ID ID to uniquely identify a driver
Gender Driver's gender or Name Insured in case of SME and Res
Age Driver's age or Name Insured in case of SME and Res
Occupation Driver's Occupation
Marital Status Driver's marital status or Name Insured in case of SME and Res
Country Driver's Country or Name Insured in case of SME and Res
State Driver's state or Name Insured in case of SME and Res
City Driver's City or Name Insured in case of SME and Res
Postal Code - Insured Driver's Postal Code or Name Insured in case of SME and Res
Prior Loss History Driver's Prior Loss information
Group Sales office group information
Zone Sales office zone information
Region Sales Office region information
Sales Office Sales office number
Branch Sales Office branch information
Sales Point Sales office point information
Country Code MY - Malaysia, SG - Singapore, ID - Indonesia
Claim Type Type of claim.
PAYMENT DATE Date Claim Settlement Offer authorized
Franchise Type FP=Franchise Panel, FA-Franchise Authorized,F=Franchise Holder
Appraiser Type ADJ = External Adjuster, INJ = Internal Adjuster (use adjuster module), INS = Inhouse Surveyor (use insurer module), Blank = None
Desktop Assessment Y=Lablel as desktop assessment
Claim Handler Name Claim handler name
Rate ID Mexico Specific - Premium rates offered to customers in Quote and Policy. Premium rates are revised on periodic basis by local Actuarial team.
Sub-branch Producer sub-branch information
Agent Name Producer or Agent Name
Account Manager Sales team executive or account manager
Contract Type  Type of Policy contract (Comprehensive, Limited etc. )
Operational Expense General operational expenses incurred by Chubb during quotation and policy registration process. This could be monetary amounts or % of Written Premium.
Policy Source Type Type of Policy source ( Personal, Fleet, Fleet-Bulk etc. ) 
Compensation Plan Compensation plan provided to each producer - This could be code like "gold", "platinum", "silver" etc.
Surveyor Fee Fees paid to the surveyor for a given claim
Adjuster Fee Fees paid to the adjuster for a given claim
ADJUSTER ARRIVAL DATE Date adjuster arrives to work the claim
PACKAGE TYPE ABA has 301 types of "packages" (can be grouped in 60 high level groups)
Coverage Name Name of the coverage
ENDORSEMENT EFFECTIVE DATE Date when the endorsement is in effect
ENDORSEMENT END DATE Date when the endorsement ends
LINE OF BUSINESS Line of Business e.g. SME, Residential, Auto
Municipality Municipality where the risk is located
Policy Status Status of the policy
THIRD PARTY SERVICES INDICATOR Indicator showing if third party services is present.
Claims Count Count of the number of claims
Indicator for Auto (0) or P&C (1) Indicator to identify the Line of business
Policy Count Count of the number of policies
Address Address of the risk location
BUSINESS UNIT   Business Unit
CLAIM CLOSED DATE Date of closing the claim
CLAIM CLOSED INDICATOR Indicator describing if the claim is closed
CLAIMANT  ID Unique ID identifying a claimant
CLAIMANT  NAME Name of the Claimant
COVERAGE PERIOD IN DAYS This field contains the coverage period
COVERAGE CLASSIFICATION Breakdown of specific coverages being offered
ENDORSEMENT  CAUSE  DESCRIPTION Description of the specific Endorsement
ENDORSEMENT CAUSE Reason for Endorsement e.g. ABA has 65 different endorsement causes
INCURRED LOSS AMOUNT NET OF DEDUCTION Incurred Loss amount excluding the amount which was deducted.
INSURED  NAME Name of the insured
POLICY DAYS COVERED TILL DATE This field calculates the number of days the policy has been in force
RECORD EFFECTIVE DATE Record effective date
PRODUCT CLASSIFICATION MIX of Product names and Coverages. ABA has 23 type of classes (BRIO, ABASIF, THEFT) 
PRODUCT NAME The specific product name that is being offered i.e home, auto, business owners etc
PRODUCT ORIGIN There are different types 1. Channel, 2. Intermediary and 3 The actual Salesman
PRODUCT TYPE EXAMPLE - PACKAGE or FLEXIBLE
ACE SHARE Share of Risk retained by ACE
ACQUISITION COST RATIO Ratio of Acquisition costs to Net Earned Premium
ADJUSTER SHIPMENT DATE Date claim assigned to an adjuster
ADJUSTMENT DOWN AMOUNT Adjustment to reserves 
ADJUSTMENT UP AMOUNT Adjustment to reserves
AGGREGATED SUM INSURED AMOUNT The maximum dollar amount limit that insurance company will pay to the insurer in a given policy period to settle claims. 
AGGREGATED SUM INSURED INDICATOR Indicator for Aggregated Sum Insured 
ALLOCATION  TYPE Allocation type for Reinsurance
APPLICATION  NUMBER This is very specific to ABA where each policy registration might have front end application information associated and business process management (BPM) information added. Not sure if this is applicable to all countries and systems.
AVERAGE EXPENSE PER CLAIM Average amount of expenses incurred to investigate and settle losses.
AVERAGE PAID PER CLAIM Average amount of settled losses per claim. 
BOOKING DELAY A metric that tells how long it takes to issue a policy from the inception/effective date time of a given policy.
BUSINESS  PROCESS  MANAGEMENT ABA system (Business Process Management System)
CALCULATION  TYPE ABA uses this field to show how premium is earned or refunded in cancellation (pro-rata, direct, short term)
CANCELLATION RATIO  Ratio of no. of cancelled policies during the time period to no. of in force policy at the start of the time period. 
CAPTION  MCC  TYPE Used for PeopleSoft reporting in CIPL datamart
CATASTROPHE  CODE / CATASTROPHE  DESCRIPTION / CATASTROPHE  ID The code, description and ID of the catastrophe
CLAIM  CLOSED  WITH  PAY Indicator describing if the claim is settled after payment.
CLAIM  TRANSACTION  TYPE Transaction type for the claim movements
CLAIM CLOSED WITH PAY Indicator showing if the the claim was closed with payment
CLAIM NOTES The notes taken while recording the claim
COMBINED RATIO The Sum of Loss Ratio, Acquisition Ratio & UW Expense Ratio used to help measure profitability.
CUSTOMER  SERVICE  OFFICE Where the quote/policy is serviced 
CUSTOMER  TYPE Customer type could be individual, SME etc.
CYCLE TIME Cycle times are used to measure the rate at which claims are processed
DEFERRED ACQUISITION COSTS   For a policy, acquisition costs are usually expensed evenly, with the amount to be expensed in future periods recorded as Deferred Acquisition Costs in the balance sheet
DIRECT ASSUMED CEDED CODE PCW codes indicating if the business is direct, ceded, retroceded, global treaty, multinational, direct placement etc.
FINANCIAL  LINE  OF  BUSINESS Financial Line of Business
FRAUD FLAG Fraud Flag Y or N
GEOGRAPHIC LOCATION   risk Location
HIT RATIO Ratio of number of issued policies to number of new quotes
IBNR   Incurred But Not Reported factor used for calculating Ultimate Losses
ICE PAYMENT AMOUNT State Tax in claims activity. 
INITIAL NET PREMIUM  Original premium on a policy when issued
INSURANCE  LIMIT  TYPE Aggregate limits, indemnity limits - how the claims are totalled and paid. In Mexico (ABA) are MaxLiabLimit, 1st Loss and Normal.  1st loss is when we pay the loss amount up to the limit on the policy regardless of the actual exposure (applicable for Loss  of money or belongings when these fluctuate widely), Normal is when we pay up to the limit of the policy but at the time of the claim, if we determine that the insured property had a higher value than reported it is deemed underinsured and therefore we adjust the indemnity amount down.
 
IS  CO  INSURED Indicator showing if the coinsurance is applicable
ISR PAYMENT AMOUNT Federal Tax in claims activity
ISSUANCE AND LEGAL FEES Issuance and legal fees
LOSS EXPENSE WAGES Expense wages related to claim activity .
LOSS EXPENSES Expenses related to claim activity.
LOSS OUT STANDING   Business to confirm - Losses that have been reported to the insurer but are still in the process of settlement.
MCC  CODE MCC
NET EARNED EXPOSURE SUMINSURED   Exposure is the potential for losses. This is also the measure of the rating units or premium base of a risk. Earned exposure are the Exposure Units actually exposed to loss during the period in question.
NET EARNED EXPOSURE UNITSOFRISK   Exposure is the potential for losses. This is also the measure of the rating units or premium base of a risk. Earned exposure are the Exposure Units actually exposed to loss during the period in question.
OTHER REVENUE   Revenue other than premium related to cover of risk. Examples of ‘Other Revenue’ are given below:
a. Late Payment Fees
b. Extra charges levied for premiums paid in instalments
c. Third Party Services
POLICY ITEM COUNT Count of items covered by a policy
POLICY RISKITEM   Risks/Items covered in a Policy
POLICY TRANSACTION TYPE   Type of Policy Transaction
RANGE  FROM  ARGENTINA  DOLLARS Sum Insured Band
RANGE  FROM  US  DOLLARS Sum Insured Band
RANGE  TO  ARGENTINA  DOLLARS Sum Insured Band
RANGE  TO  US  DOLLARS Sum Insured Band
RCC  CODE Reinsurance Contract Code
REASON  FOR  CANCELLATION Reason for cancellation of Policy
REINSURANCE  CONTRACT Type of Reinsurance contract
REINSURANCE COMMISION   Reinsurance commission
REPORT  MCC  CAPTIONS Used for PeopleSoft reporting in CIPL datamart
REPORTED CLAIM AMOUNT   Incurred Loss amount
RETENTION RATIO Ratio of No of issued policies to No of Policies available to Renew during the specific time period.
RISK  ITEM  DESCRIPTION Description about the risk which is covered by the policy
RISK  ITEM  ID Unique identifier for the risk Item
RISK  ITEM  NAME Name of the Risk which is covered by the policy
RISK  ITEM  STATUS Status of the risk item
SALVAGE AMOUNT BASE PRICE  Base price of item to be sold as salvage. Aids in setting first estimate
SOURCE  COVERAGE  KEY Coverage Key in local source systems
SOURCE  COVERAGE  NAME Coverage name in local source systems
SUB INDUSTRY TYPE Further breakdown of the type of the business
SUBTOTAL PAYMENT   
SUBTOTAL SALVAGE   
SURCHARGE AMOUNT surcharge applied to a policy or coverage
TAX ALLOCATION   Tax allocated
TAXES Financial charge or other levy imposed upon a taxpayer (CHUBB as a legal entity) by a state or the functional equivalent of a state such that failure to pay, evasion of, or resistance to collection, is punishable by law.
TOTAL PAYMENT  Total payment made to settle the claim
ULTIMATE LOSS RATIO Ratio of ultimate losses to Net Earned Premium
ULTIMATE LOSSES   Ultimate losses are the sum of Incurred Losses along with Incurred But not reported losses. 
UNDERWRITING EXPENSE RATIO Ratio of underwriting expenses to Net Earned Premium
UNDERWRITING OFFICE Underwriting Office working on a policy
VAT AMOUNT WITHHOLD Value Added Tax withold in claims activity.
VAT PAYMENT AMOUNT Value Added Tax in claims activity.
VAT SALVAGE AMOUNT   Value Added Tax related to claim activity .
XLEVENT  ID / XLEVENT  NAME XL Reinsurance is a method whereby an insurer pays the amount of each claim for each risk up to a limit determined in advance and the reinsurer pays the amount of the claim above that limit up to a specific sum 
XLEVENT  TYPE Type of the XL event
Sub Line Fire, Machinery breakage, Glass, etc.
Annual Aggregate Limit Applies when multiple locations are involved
Annual Revenue Business to confirm - Total annual revenue of the risk item in case of SME
Coverages count Count of the number of coverages
Department Area
Direct Supervisor Direct Supervisor of the user who raises premiums & claims on the system
Frequency of payment Frequency of Premium payment - Monthly, Yearly etc.
Frequency of payment group ABA has about 10 groups
Is ACE the lead? Is Ace the lead for Reinsurance
Losses in Last 5 Years Total paid loss in last 5 years
Max Acceptable Limit
Max Deductible Business to confirm - How is this different from deductible ?
Min Deductible For Risk Control
Origination ABA system (Business Process Management System)
Prior Carrier Prior carrier of insurance
Regional Manager Regional manager of the branch
Reinsurer type ABA has 2 levels: Broker and Reinsurer
VAT original amount Value added tax
Zone Manager Business to confirm - Zone manager in the branch
User Number/ID ID of the CHUBB emplyee creating the record
Premium Related Services Premium for "servicios conexos" (Third party services)
Coverage Base Premium Business to confirm - Base premium of the coverage upon which the reinsurance premium is based 
Policy Base Premium Business to confirm - Base premium of the policy upon which the reinsurance premium is based 
Premium_without_TPS Premium without Third Party Services
Security Measures Indicator showing if security measures are present or not
INDUSTRY ID / INDUSTRY TYPE / INDUSTRY TYPE KEY primary business activity code
NAICS Classification used for segregating Industry Type
Primary Occupation Industry where the risk Item is in operation. Based on Country-Specific Occupation Database
Percentage of discount from Sum Insured with Combined Single Limit  Percentage of discount from the Combined Single Limit
offer Authorized Date The date  loss payment to claimant was authorized
Reinsurance Recovery Amount Reinsurance amount recovered from reinsurer for each accepted claim. 
Claim Recovery Amount Amount recovered from the Claimant or litigant in case excess loss amount is paid. This could happen in case of fraud or the loss payment assessed was erroneous.
Claim Transaction Adjustment Amount Adjustments to claim reserves, expenses, payments. These adjustments could be positive or negative. ABA - importemto
Policy Type Type of policy. In case of Auto to determine if policy is for Individual, Family, Commercial, Fleet, Bulk and non-bulk etc. Bulk and Non-bulk policies are specific to ABA. Logic to identify a bulk or non-bulk policy is in SAS process. Logic is as follows:

if upcase(claveid) in ('XO','BK')
 or (rlob = 'Agn' and alob = 'Mod') /*underwriter class is 'Special'*/
 or (rlob = 'Agn' and alob = 'Carr')  /*underwriter class is 'Highway'*/
 then policy_bulk = 1;
  else policy_bulk = 0;
Surveyor Fee Fees paid to the surveyor for a given claim
Adjuster Fee Fees paid to the adjuster for a given claim
Loss Location ID Reported location where loss occurred. Usually in case of Auto, the loss location is different from risk location (location where vehicle is garaged).
Discount Type Structure of the discount in source system: $ or %
Deductible Policy deductible amount in case of loss or Excess amount
Deductible Type Type of Policy deductible: $ or %
Claim Deductible Claim deductible amount idetermined during settlement.
Claim Deductible Type Type of claim deductible: % or $
TPS Retension Share Portion of the TPS Premium retained by Chubb
Claim Reinsurnace Outstanding Balance Claims Reinsurance reserve outstanding balance amount
Brokerage Fee Fee paid to broker for each policy sold. This is in addition to commision amount.

Metrics used by P&C Insurance


# Metric Business Definition
1 Net Earned Premium "Net Earned Premium" - It's the portion of a policy’s premium that applies to the expired portion of the policy and calculated at an even rate throughout the policy term. 
2 Net Written Premium Total premium written after re-insurance cost.
3 Gross Written Premium Gross Written Premium - Total premium written by insurer before deductions
4 Technical Earned Premium Earned premium before any underwriting deviations ( discounts or surcharges ).
5 Technical Written Premium Written premium before any underwriting deviations ( discounts or surcharges ).
6 Net Earned Exposure Earned Exposure is the portion of a policy’s expoure, calculated in days, that applies to the expired portion of the policy and calculated at an even rate throughout the policy term until policy expires or cancelled. In case of Auto the primary unit of exposure is the  insured vehicle.
7 Average Earned Premium Earned Premium / Earned Exposures
8 Quoted Premium Total premium quoted in the document while issuing the quote.
9 Issued Premium Total Premium of registered policy irrespective of whether policy is new or renewal.
10 New Premium Total Net Written Premium of new policies registered
11 Renew Premium Total Net Written Premium of renewed policies
12 Sum Insured
 The total value of the vehicle
13 Gross Paid Loss The total paid loss before any deductions
14 Net Paid Loss The amount of paid losses net of deductibles, salvage and subrogration.
15 Net Incurred Loss The total amount of paid claims plus case reserves. 
16 Incurred Losses Capped ( ~ $50K) Claims with incurred losses below approximately $50,000 (USD).
17 Incurred Losses Capped ( ~ $25K) Claims with incurred losses below approximately $25,000 (USD).
18 Ultimate Loss Ultimate losses are the sum of Incurred Losses along with Incurred But not reported losses (IBNR).
19 ALAE Allocated Loss Adjustment Expenses -  Expenses are specific to each claim
20 ULAE Unallocated Loss Adjustment Expenses - Expenses those are general in nature, which cannot be assigned to a particular claim. 
21 Frequency The number of claims directly related to the number of exposures, thus claim incidence is expressed in terms of frequency per exposure.
22 Severity Average loss per claim.  Currently calculated based on Incurred Losses.
23 Pure Premium The amount included in the rate per exposure unit required to pay for losses.  It is usually calculated by dividing expected losses by earned exposure units.
24 Opex Operational Expenses are general administrative expenses incurred by the business like expenses related to marketing, office costs etc.
25 Commission Commisions paid to producer/agent
26 Bonus Bonus amount awarded to producer/agent
27 Policy Fee Flat fee to offset any expense incurred for issuing or registering the policy
28 Installment Fee Installment fee charged for the policy
29 Third Party Services Premium Third Party Services Premium associated with Policy / Coverage.
30 Combined Ratio (COR) The combined ratio (%) is calculated by taking the sum of incurred losses and expenses and then dividing them by earned premium. 
31 Claim Count Number of Claims in a given exposure period
32 Quote Count Number of Quote in a given exposure period
33 Issue Count Number of policies issued in a given period

Pega RPA

tremendous manual steps makes stress on the overall system , especially during the CAT claims

most of the times customer think - in FNOL the FE system is tied back to the BE system,

but that is not the case there may be manual intervention to complete the FNOL

institutionalized the claims processing - so it can reduce the burden on employees

knee jerk reaction for insurance customers is that they need to buy a new PAS or claims system.

But this is not transformation (they do not bring that value now), because most of these software’s are just data recording machines

After the first roll out they believe that the turnaround time has not increased, new products cannot be introduced, and existing systems are broken

Pega RPA wants to take the transformations process and breaks it down into steps

it seems as per the speaker, most insurance clients are doing the RPA right now,  as it is low hanging fruit, but it is one more element is the data integration strategy

Robot and EPA is not a silver bullet but it is a great first step to start

life insurance companies generally do not retire the legacy systems until the insured customers have not been paid out or the insured customers have not collected their benefits

key is the robotic automation strategy should definitely blend in with transformation strategy

IT is the guardian angel to make sure that they provide the tools which will enable the operations to handle and control the robotics process automation

RPA is strategy to use tactical tools of a broader strategy, doing RPA is a cost-benefit analysis

Robots is the buffer between the user and underlying system (mostly legacy)




Design Process

Design Principles

The Principle of Operational Need – Design must be a response to individual or social requirements which can be met by technology or culture.

The Principle of Physical Realizability – Design objectives must be goods or services which are physically realizable.

The Principle of (Economic) Worthwhileness – The goods/services being designed must have use to the consumer that equals or exceeds the costs of production.

The Principle of Resource (Financial) Feasibility – The operations of designing, producing, and distributing the good(s) must be financially supportable.

The Principle of Optimality – The choice of design concept must be optimal among the available alternatives; the selection of a manifestation of the chosen design must be optimal among all permissible manifestations.

The Principle of Design Criterion – Optimality must be established relative to a design criterion which represents the designer’s compromise among possible conflicting value judgments that include those of the consumer, the producer, the distributor, and his own.

The Principle of Design Morphology – Design is a progression from the abstract to the concrete.

The Principle of Design Process – Design is an interactive problem-solving process.

The Principle of Subproblems – In attending to the solution of a design problem, there is uncovered a substratum or subproblems; the solution of the original problem is dependent on the solutions of the subproblems.

The Principle of Reduction of Uncertainty – Design is a processing of information that results in a transition from uncertainty about the success or failure of a design toward certainty.

The Principle of Economic Worth of Evidence – Information and its processing has a cost which must be balanced by the worth of the evidence bearing on the success or failure of design (Optional).

The Principle of Basis for Decision – A design project is terminated whenever confidence in its failure is sufficient to warrant its abandonment, or is continued when confidence in an available design solution is high enough to warrant the commitment of resources necessary for the next phase.

The Principle of Minimum Commitment – In the solution of a design problem at any stage of the process, commitments which will fix future design decisions must not be made beyond what is necessary to execute the immediate solution. This will allow maximum freedom in finding solutions to subproblems at lower levels in the design.

The Principle of Communication – The design is a description of an object and a prescription for its production; therefore, it will have existence to the extent that it is expressed in the available modes of communication.

The idea

Idea/Business Need/Problem Statement

 
This week we are discussing the first step in the Design Process. That step has the goal of defining what is really needed by the business. In some cases it might just be an idea that someone has generated and needs to know if it is feasible, economical, and hopefully profitable. It may be a problem that needs to be solved within an existing product or solution.  The input for this first step can come from any one of a number of places. There may be some unique new technology (Google Glass and drones for example) that can be used for improving service for the business, or business capability that arises from a new area of risk (drone usage), or a deficiency in a current system that has been detected (Whiteboards). Each of these events can be the start of a systems design. An example of this for Erie Insurance would be “EIG needs to communicate with Agents”. That is a very broad and general requirement but it is definitely an idea. It can be modified to be more specific if the need dictates. It also can be decomposed into discrete business requirements which we will discuss next week.
 
The formal output of this step is a clear statement of need from the business standpoint or a problem statement. The statement needs to have enough detail to allow decomposition into the Business Requirements. It should not have product or compute specifications included with it. Those will be determined based on further analysis.
 
Informal outputs could be mind maps, structured hierarchies, ishikawa diagrams, unstructured documents, presentation materials, etc.
 
This step is probably the least structured of all the design steps. Even though the step itself tends to be a bit free-form, in order to properly communicate The Idea to the enterprise there needs to be some structure around what gets produced.
 
The first three engineering principles support this phase of the systems life cycle. Clearly Operational Need is the driver for the step. Physical Realizability and Economic Worthwhileness are also drivers during this period. We need to ensure that we propose building systems which have a chance of being successful. A classic example for something that would not be Physically Realizable would be finding a process to turn lead into gold.
 
The level of participation of the Engineer role in this step is varied. If it truly just an idea that needs evaluation there might not be any input from an Engineer during this step. However, typically we want to have someone with design experience evaluate the idea in order to ensure that it is something that can be done. In some cases, there could be a whole team of individuals working to identify exactly what it is we are trying to accomplish with the solution. The important thing with this step is to ensure the right people are engaged.

The Engineering Process

1.      Idea/Business Need/Problem Statement

2.       Business Requirements
3.       Functional/Non-functional Requirements
4.       High-Level Requirements/Specifications
5.       Detailed Specifications
6.       Build
7.       Test
8.       Deploy
9.       Operate
10.   Disposal

Principle of Design Process

each systems implementation needs to follow the simple design process steps outlined below:

 
1.       Idea/Business Need/Problem Statement
2.       Develop Business Requirements (BR)
3.       Decompose into Functional/Non-functional Requirements (FR/NFR)
4.       Develop High-Level Requirements/Specifications
5.       Develop Detailed Specifications
6.       Build
7.       Test
8.       Deploy
9.       Operate
10.   Disposal

Business Requriements


Business Requirements
by  Madurski, RonaldNo presence information  on 5/19/2016 3:36 PM
Category: Practices

​

Business Requirements
 
As mentioned before, the output of each step is typically the input to the next step in the process.  In this step the statement from step 1 is used to generate the Business Requirements (BR), which is the highest level of requirement. It is the statement, or statements, that describe what capabilities the business needs to have developed. The BR should not have any mention of a solution or specification of tool to address the required capability. For example, a BR of “We need to be able to send a message to individual agents” is a legitimate BR. “We need to send an e-mail via outlook to individual agents” is not a good BR. It is a possible solution that would appear in the High-Level and/or Detailed Specifications but the specificity of the type of message and the delivery agent are inappropriate for a BR. BR are used to create the use cases necessary for requirements decomposition.
 
During the Private Cloud POC we generated several BR as listed below:
 
ID
Assoc
ID
Type
Technical Assumption(s)
and/or Customer Need(s)
Functional
Requirement
BR
1.0
BR
User should be able to select from a collection of predefined system configurations.
The system shall provide predefined system configurations.
BR
2.0
BR
 
The system shall deploy servers in an automated fashion based on user requests.
BR
3.0
BR
User should be able to modify appropriate configuration parameters within limits.
The system shall allow modification of configuration parameters.
BR
4.0
BR
User should be able to request various levels of resources based on requirements (T-shirt sizes).
The system shall allow resources to be assigned by template.
BR
5.0
BR
Solution must be well documented and straightforward to deploy.
Solution must be well documented and straightforward to deploy.
BR
6.0
BR
Solution fulfills requests faster than the manual process that exists today.
Solution fulfills requests faster than the manual process that exists today.
BR
7.0
BR
 
System shall report on usage, capacity, and performance.
 
Obviously, the ID and Type of BR indicate that these are the Business Requirements. In order to trace the specifications and functional requirements back and show that the BR are being met an Association ID is created also. We have a description and then the actual requirements.
 
While it is not a part of the EPP, a very effective output from the BR step is a Concept of Operations or Conops. This document outlines the changes to IT resources, personnel, process, and security that would be affected by the design. It presents the business need at a much more detailed level and can be used to help flush out the Functional Requirements. Use Cases are a common component of the Conops, however, sometimes these are not generated until the BR are being decomposed into the FR. A Conops is similar to the HLA in EPP but is much more comprehensive.
 
If the business need affects an existing system it is effective to do some process flows. Swim Lane diagrams are easy to understand flows of processes and decisions. They are useful for depicting existing processes and the change to the process being designed to satisfy the business need. The Enterprise Architecture group has a group of individuals that does this Business Process Management (BPM) analysis on a daily basis as needed. An example of the current process for deploying servers is located here. We used these diagrams and other artifacts to more clearly define our business need into our business requirements.
 
This is the start of Design Morphology as part of the Design Process. 

Functional / Nonfunctional Requirements


Functional/Non-Functional Requirements
by  Madurski, RonaldNo presence information  on 5/27/2016 10:29 AM
Category: Practices

​

Functional/Non-functional Requirements
 
There are many ways to generate Functional Requirements (FR). One of my preferred methods is to start with a Mind Map or Structured Hierarchy. This artifact, which we introduced to illustrate the Principle of Subproblems, allows us to identify the problems and subproblems that we need solve in order to satisfy the business need. This specific example is from our On-Premise Private Cloud Proof of Concept (POC). Our Operational Need in this instance was to enhance the provisioning of servers in the Data Center. The information derived from that artifact is then used to document and track the requirements.
 
Remember the example provided last week of our Business Requirement (BR):
 
“We need to be able to send a message to individual agents”
 
This is a pretty generic, but powerful, requirement. The next step in the process is to decompose  this into Functional and Non-Functional Requirements (FR/NFR) . This is where the design starts to take shape. Continuing with the messaging BR, a possible decomposition of this BR would be that:
-          The system shall send electronic mail to agents
-          The system shall send SMS text messages to agents
-          The system shall send Voice messages to agents
-          The system shall identify agents individually
-          The system shall identify agents by agency
-          The system shall allow individuals to be associated with multiple agencies…
 
And so on until all of the use cases have been satisfied.
 
Non-functional requirements are typically somewhat generic and geared toward the “ilities” of a system. Reliability, Quality, Availability, etc… These tend to be the same from one system to another with varying degrees of implementation (e.g., 99% vs. 99.999% availability). Chuck Weindorf developed a suite of NFR which are systematically being applied to systems as time and/or needs arise.
 
The output of this step is the Requirements Document (or Requirements Traceability and Verification Matrix (RTVM) ) which will be updated throughout the process. A common form is a spreadsheet like our example and/or textual document. Mature organizations will typically have a vendor provided requirements management tool (Doors, Caliber RM, …) which makes the traceability much easier. (If you look closely you can find some mistakes in our traceability example which I had not noticed until I started writing this blog installment, these kinds of mistakes can be avoided by using a better tool). The Requirements Document can be split up into FR and NFR or combined into one document depending on the system’s needs. When we get into the Test step discussion we will see how this document can be used during testing to ensure all of our business requirements are being met.
 
The FR in this example are the items with an “Assoc ID” in the form of X.x, where X is the BR and x is the FR in order of appearance. I’ve worked with some analysts that like to use the ”x” to represent priority also but find that causes issues if the priority changes later in the process.
 
It is very common at this step to generate a conceptual solution design including high level component and logical network diagrams describing the interfaces to and from the proposed design. If a reference architecture exists the components can be associated with it to make sure nothing has been left out. 

Detailed Specifications

The Detailed Specifications are the final output of the requirements decomposition. These are the requirements that will be used to build out the infrastructure, populate the configurations, and drive the development of software where necessary.  Based on our previous example from our last discussion, one of our High Level Requirements was “The system shall send text messages to Agents”. This single high level requirement should be further decomposed into the elements which will be designed/created to fulfill the requirement:

 
FR
1.2
The system shall send text messages to Agents
FR
1.2.1
Text messages shall not exceed 140 characters
FR
1.2.2
Text messages shall be stored 120 days
FR
1.2.2.1
Text messages older than 120 days shall be archived
FR
1.2.2.1.1
Archived messages shall be retrievable
FR
1.2.2.1.2
Archived messages shall be retrieved within 15 minutes
FR
1.2.2.1.3
Archived messages shall be stored on Linear Tape File System (LTFS)
 
And so on until the system has been sufficiently described to know how it will be built. There is a whole science behind how the requirements nesting is done, which I don’t fully understand but the requirements management tools mentioned last week help to facilitate this very well. The proper nesting will prevent missed specifications and duplicate specifications as well as providing guidance for testing.
 
Even a simple system can generate hundreds of specifications. I have worked with several teams in the past where we spent multiple weeks churning these out in order to define the systems that we were going to build. It can be a painstaking process but when done properly the resulting build/test/deploy cycle can be completed with confidence that the system will meet the business need.
 
As shown in the previous step, the Detailed Specifications can have many nested layers, each of which is traceable to the layer preceding it.
 
The Detailed Specifications are the requirements which are used for testing to ensure that the system does what it was designed to do. Once the Detailed Specifications are complete the engineer participation in the process drops off significantly.
 
There are artifacts that can be useful for describing the system separate from the requirements. However, these should all be based on the requirements. Examples of these are:
-          Logical Component Diagrams
-          Physical Component Diagrams
-          Process Flow/Swim Lane Diagrams
-          Rack Elevation Diagrams
-          Network cable/port Diagrams
-          Value Stream Maps
-          Performance Metrics
-          Bill of Materials
-          TCO/ROI Analysis
-          Interface Control Document
-          Database Design Document
-          Systems Design Document
-          Systems Test Plan
-          Systems Test Cases
-          Implementation Plan
 
Most of these have some representation already in the PQR process which we get into when we start to discuss the Engineering Artifacts.
 
The Resource Feasibility principle should be a huge consideration during this step and the build step. It may become obvious earlier that there won’t be enough time, money, personnel, or other resource factor to complete the design but this time period is where that determination becomes critical.