📚 课程目录第4章业务需求分析

4. 业务需求分析

在端到端精算模型项目中，需求分析不是“把条款抄进文档”，而是一次业务语言到模型语言的翻译工程。产品条款决定“赔什么、怎么赔”，监管要求决定“必须怎么算、留多少”，业务目标决定“算给谁看、支持什么决策”。三者往往口径不同、颗粒度不同，甚至存在张力。精算模型需求分析的核心任务，就是把这些异构输入统一为可验证、可实现、可追溯的模型规格。

核心原理：需求分析的本质是建立“业务规则—精算假设—模型参数—输出指标”的四层映射。任何一条无法映射到参数或输出指标的业务描述，都是需求缺口；任何一条没有业务来源的模型参数，都是假设风险。

一、三类输入的拆解与对齐

产品条款、监管要求和业务目标需要分别拆解，再对齐到同一张需求矩阵中。

产品条款：提取保险责任、给付条件、免责条款、等待期、现金价值规则、红利分配机制、退保与减保规则。重点识别“条件触发型”责任，例如重疾确诊即赔、身故按已交保费与现金价值较大者给付。
监管要求：识别准备金评估方法、折现率曲线、发生率表、费用假设上限、资本要求、披露口径。监管要求通常具有强制性和版本时效性，必须记录文号与生效日期。
业务目标：明确模型服务于定价、评估、价值分析还是经营预测，输出是利润、内含价值、偿付能力还是新业务价值。业务目标决定模型颗粒度和运行频率。

三类输入对齐后，形成需求条目。每条需求应包含：需求编号、来源、业务描述、模型影响、优先级、验收标准。下表给出一个简化的需求矩阵示例。

需求编号	来源	业务描述	模型影响	验收标准
R-001	产品条款	重疾确诊按基本保额给付	重疾给付函数、状态转移	确诊状态下给付金额等于保额
R-002	监管要求	准备金按最优估计加风险边际	折现率、风险边际参数	准备金结果可分解为最优估计与边际
R-003	业务目标	支持季度新业务价值报告	输出指标、运行频率	季度可输出VNB及敏感性结果
R-004	产品条款	犹豫期内退保全额退还	退保状态与现金流	犹豫期退保现金流等于已交保费

二、从业务规则到模型参数的转化流程

转化流程建议按以下步骤推进，每一步都留下可追溯记录。

规则抽取：从条款和监管文件中抽取原子规则，避免复合句。例如“等待期内确诊返还已交保费并终止合同”应拆为等待期判断、返还金额、合同终止三个原子规则。
状态建模：将原子规则映射为状态与转移。保险精算模型常用状态包括有效、等待期、确诊、身故、退保、失效、满期。
参数化：把金额、比例、期限、曲线转化为参数。参数需标注来源、单位、取值范围和更新频率。
输出定义：明确每个输出指标的计算口径、时间维度和聚合层级。
验收设计：为每条需求设计可执行的验收用例，包括正常场景、边界场景和异常场景。

以下是一个参数配置片段的示例，展示如何把条款规则落为可执行配置。

{
  "product_code": "CI_2024_A",
  "waiting_period_days": 90,
  "benefit": {
    "critical_illness": {
      "type": "sum_assured",
      "amount": "basic_sum_assured",
      "terminate_contract": true
    },
    "death": {
      "type": "max",
      "items": ["paid_premium", "cash_value"]
    }
  },
  "surrender": {
    "cooling_off_days": 15,
    "refund": "paid_premium"
  }
}

三、典型场景：重疾险模型需求转化

假设某重疾险产品条款规定：等待期90天，等待期内确诊返还已交保费；等待期后确诊按基本保额给付并终止合同；身故按已交保费与现金价值较大者给付。监管要求准备金采用最优估计加风险边际，业务目标为支持季度新业务价值报告。

转化时，模型需求应明确：状态集合包含有效、等待期、重疾、身故、退保、满期；转移概率需区分等待期内和等待期后；给付函数需区分重疾给付和身故给付；输出指标需包含准备金、VNB和敏感性结果。此时，条款中的“较大者”必须转化为模型中的比较函数，而不是口头描述。

四、常见误区与复盘要点

误区一：把条款原文直接当需求。条款是法律语言，模型需要的是可执行规则。例如“确诊即赔”必须明确确诊定义、给付金额、是否终止合同。
误区二：忽略监管版本时效。折现率曲线、发生率表、资本要求都有生效日期，需求文档必须记录版本，否则模型结果无法审计。
误区三：业务目标与模型颗粒度不匹配。若业务只需要季度VNB，却把模型做到逐单逐月，会造成过度开发和运行成本浪费。
误区四：验收标准缺失。没有验收标准的需求无法判断模型是否正确，最终只能靠“看起来差不多”交付。

复盘建议：需求评审时，让产品、精算、IT、合规四方共同确认需求矩阵。重点检查三类问题：是否有业务规则未映射到参数；是否有参数无业务来源；是否有输出指标无验收用例。需求分析的质量，直接决定后续建模、测试和上线的返工成本。

把条款、监管和业务目标转化为精算模型需求，关键不是写出一份漂亮的文档，而是建立一条可追溯、可验证、可维护的映射链。当每条业务规则都能找到对应的状态、参数和输出指标，模型才真正具备落地能力。