## 2 RICE评估方法总览
### 适用场景
RICE评估方法适用于以下场景：
- **权限模型选型**：在多个RBAC权限方案中比较优先级时，使用RICE统一量化每个方案的投入产出比。
- **权限功能迭代排序**：当权限功能需求列表过长（通常超过20项），需要依据评估分值确定开发顺序。
- **安全合规改进排期**：针对审计报告中发现的权限风险项，通过RICE分值确定修复紧迫度。
- **多部门权限需求仲裁**：跨部门提出权限需求冲突时，RICE评分可作为客观决策依据。
> **不适用场景**：仅涉及单一角色、无明显风险差异、或已由法规确定硬性要求的功能需求（如GDPR必需项），无需RICE评估。
### 前置条件
| 条件 | 说明 | 负责人 |
|------|------|--------|
| RBAC等级已确定 | 至少完成第1章的RBAC等级划分（简单、通用、高级） | 架构师 |
| 角色清单 | 包含所有待评估角色的编号、名称、权限集合 | 权限管理员 |
| 安全基线文档 | 包含当前系统的安全策略、合规要求、历史风险记录 | 安全管理员 |
| 评估团队 | 至少包含1名权限架构师、1名业务代表、1名安全工程师 | 项目经理 |
| 评分工具 | RICE评分表（Excel/在线表单）、打分规则文件 | 架构师 |
### 操作步骤
#### 步骤1：确定评估目标与范围
明确本次RICE评估针对的是**新权限模型引入**还是**现有模型优化**。填写评估范围表。
#### 步骤2：拆解待评估功能项
将需求拆解为可独立打分的**功能单元**。每个功能单元应符合5W1H原则：Who（谁）、What（什么权限）、Why（为什么）、Where（哪个系统/模块）、When（何时需要）、How（如何实现）。
#### 步骤3：每项逐一进行RICE打分
对每个功能单元，分别评估四个维度的分值与权重。
#### 步骤4：加权计算并生成优先级
使用公式：`RICE总分 = (R × I × C) / E`，将结果四舍五入保留两位小数。
#### 步骤5：结果排序与归档
按RICE总分降序排列，输出优先级列表。将原始评分表、计算过程、最终排序归档。
> **常见误区**：切忌先定排序再反推分值——这会导致RICE评估形同虚设。所有打分必须在排序前独立完成，且打分数值不可修改。
### 输入输出物
| 类型 | 名称 | 格式 | 示例 |
|------|------|------|------|
| 输入 | RBAC角色清单 | Excel / CSV | `role_2025_v2.1.xlsx` |
| 输入 | 待评估功能项列表 | Excel / 需求管理工具 | `requirements_masterlist_v1.2.xlsx` |
| 输入 | 安全基线文档 | PDF / Markdown | `security_baseline_v3.0.pdf` |
| 输出 | RICE评分表 | Excel | `RICE_scoring_v1.0.xlsx` |
| 输出 | 优先级排序清单 | Excel / HTML | `RICE_priority_ranking_v1.0.html` |
| 输出 | 评估报告 | PDF | `RICE_assessment_report_v1.0.pdf` |
### 责任边界
| 角色 | 职责 | 确认权限 |
|------|------|----------|
| 权限架构师 | 主导评估流程、审核评分一致性、输出最终排序 | 批准分值调整 |
| 业务代表 | 提供业务维度信息、评估范围和影响分值 | 否决不合业务逻辑的评分 |
| 安全工程师 | 评估安全影响、信心水平、检查合规性 | 否决不符合安全基线的评分 |
| 项目经理 | 分配评估资源、设定时间节点、监督流程合规 | 决定是否重新评估 |
### 记录材料
- **RICE评分表**：包含每个功能单元的R、I、C、E原始分、加权分、RICE总分、评分人、评分日期。
- **评分理由说明**：对于分值存在分歧或分值异常的条目，需记录简要理由。
- **评分人签字表**：所有参与评估的人员签字确认，表示认可最终结果。
- **变更记录**：当需求变更、角色变更、或评估错误被修正时，记录变更原因、变更内容、变更时间、变更人。
### 异常处理
| 异常情况 | 处理方式 | 负责人 |
|----------|----------|--------|
| 评分人之间存在重大分歧 | 组织仲裁会议，由架构师、安全工程师、业务代表三方投票，2/3通过即生效 | 项目经理 |
| 某个功能项无法确定范围 | 返回需求提出方，补充5W1H信息，待明确后补评分 | 业务代表 |
| 信心分数普遍偏低（<2） | 延长评估准备期，收集更多数据后再重新评估 | 安全工程师 |
| 评分表数值出现明显矛盾 | 由架构师核查原始数据，确认是否笔误或计算错误，修正后重新计算 | 权限架构师 |
> 所有异常处理记录必须留存归档，作为评估报告附件。
### 验收标准
1. **完整性**：所有待评估功能项均已评分，无遗漏条目。
2. **一致性**：同一逻辑类别的功能项，R、I、C、E分值无自相矛盾之处。
3. **可追溯性**：评分表可从原始需求、角色清单、安全基线等输入物逐项追溯。
4. **正确性**：RICE总分计算公式无误，排序结果无逻辑错误。
5. **合规性**：评估流程符合《权限管理与评估规范》相关要求。
---
### SVG框架图：RICE四维评分流程概览
---
### RICE四维评分标准速查表
| 维度 | 英文 | 权重 | 1分 | 2分 | 3分 | 4分 | 5分 |
|------|------|------|------|------|------|------|------|
| R - 范围 | Reach | 1x | 1个角色 | 2-3个角色 | 4-6个角色 | 7-10个角色 | ≥11个角色 |
| I - 影响 | Impact | 2x | 无风险变化 | 低风险降低 | 中风险降低 | 高风险降低 | 关键风险消除 |
| C - 信心 | Confidence | 1x | 完全不确定 | 有些不确定 | 中等把握 | 比较确定 | 几乎确定 |
| E - 努力 | Effort | 倒数（1/E） | ≥30人天 | 20-29人天 | 10-19人天 | 5-9人天 | ≤4人天 |
> **加权说明**：影响（I）是安全评估的核心维度，建议赋以2倍权重；努力（E）取自然倒数，即工作量越大，RICE总分越低，符合“低投入高回报”的排序逻辑。
### 输出结果形式
RICE评估完成后，输出以下三种形式的结果：
- **RICE分值列表**：每个功能单元对应一个RICE总分，保留两位小数。格式：`[功能ID] - [RICE总分] - [排序序号]`
- **优先级分组**：按分值区间分为三组——高优先级（≥3.5分）、中优先级（1.5-3.49分）、低优先级（<1.5分）
- **排序清单**：将所有功能项按RICE总分从高到低排列，标注每组数量，形成可交付的开发排序清单