第2章 业务场景与权限需求分析：多租户、组织层级、岗位角色、数据隔离等典型需求萃取方法

2.1 边界定义

权限需求分析的上游是业务场景，下游是权限模型设计。本章边界为：从产品PRD/业务描述中，系统化萃取出与权限相关的结构化需求，不涉及具体权限实现技术。萃取结果应覆盖四个核心维度：

• 多租户：租户识别、租户间资源隔离粒度、跨租户协作场景。
• 组织层级：企业组织树深度、汇报关系、虚拟组织（项目组/临时团队）。
• 岗位角色：岗位职责、角色继承、权限聚合与分离。
• 数据隔离：行级/列级/字段级数据可见性、数据范围边界。

2.2 分层模型

需求萃取过程遵循三层递进结构，从模糊业务描述到精确权限元数据：

2.3 组件职责

• 需求分析师：主持场景层访谈，识别“谁做什么、看到什么数据”的潜在权限点。
• 架构师：在分析层判断多租户模式（独立库/共享库）、组织模型适配性（固定深度/动态层次）。
• 产品经理：在模型层确认角色与岗位的映射关系，避免业务逻辑与权限逻辑耦合。

2.4 数据流 / 控制流 / 信任链路

需求萃取阶段的数据流以业务描述→结构化文档方向流动，控制流依赖三次确认机制：

1. 第一轮（L1→L2）：需求分析师输出权限用例，由产品经理确认场景覆盖度。
2. 第二轮（L2→L3）：架构师输出原子操作与数据范围，由技术负责人评审隔离可行性。
3. 第三轮（L3→最终）：权限模型拓扑由业务方与研发联合签收。

信任链路建立原则：权限需求不可绕过业务方直接给技术方案，每一层级转换须附带变更追溯标识（需求ID+版本号）。

【权限场景卡】
场景ID: S001
参与者: 区域经理
操作: 查看本地区销售额报表
数据范围: 只包含本区域门店（排除总部、其他区域）
约束: 不可导出，不可打印

2.5 选型权衡

2.6 风险点

• 风险1·覆盖遗漏：权限用例只覆盖主流场景，遗漏异常权限请求（如临时跨组织查看）。
  缓解措施：在L1阶段专门设计“异常权限用例研讨会”。
• 风险2·隔离过度：多租户选择数据库级隔离导致运维成本暴增。
  缓解措施：通过租户规模增长曲线预估，预留行级隔离的扩展路径。
• 风险3·角色爆炸：每个岗位定义独立角色，导致数百个角色难以维护。
  缓解措施：萃取时引入“角色继承”概念，区分基础角色与扩展角色。
• 风险4·数据边界模糊：部门与项目组数据可见范围交叉，导致权限冲突。
  缓解措施：定义数据域优先级规则（组织维度>项目维度）。

2.7 落地步骤

1. Step 1：召开场景访谈会，收集30~50个权限用例，填入“权限场景卡”。
2. Step 2：聚类分析，将用例按多租户、组织、岗位、数据隔离四个主题分类。
3. Step 3：输出《权限需求规格说明书V1.0》，包含原子操作清单、数据范围定义表。
4. Step 4：与业务方举办确认会，逐项过审，记录变更需求。
5. Step 5：锁定V1.0版本，签字归档；同时建立需求变更流程。

2.8 验收标准

验收通过条件需同时满足：

• 每个业务场景均已映射到至少一条权限用例（覆盖率100%）。
• 原子操作数量不超过预估值上限（≤50个），否则需合并或分拆。
• 数据隔离策略无歧义，每个数据域都有明确的归属条件描述。
• 所有风险项均记录在册并分配缓解措施责任人。