第2章：权限需求的用户场景分析

2.1 识别需要权限的角色

权限需求的起点是明确“谁”需要“什么”权限。角色是权限分配的最小单元，一个用户可能属于一个或多个角色。识别角色时，要避免直接以岗位名称替代角色，应当基于用户在特定场景下的行为集合来定义。

核心角色类型清单：

2.2 用户场景描述模板

场景描述是连接角色与权限的桥梁。一套标准化的场景模板，能够确保需求方、产品经理、开发、测试对“谁在什么情况下做什么”达成一致。

推荐的结构化场景模板：

场景名称：[动词+目标，如“导出月度销售报表”]
触发条件：[时间/事件/用户主动操作]
前置条件：[用户必须已登录/拥有某个基础角色]
参与角色：[场景中涉及的所有角色，用“主要”、“辅助”标注]
场景流程：
  1. [主要角色] 发起操作
  2. [系统] 验证当前角色是否具备该操作的权限
  3. [主要角色] 填写/选择必要参数
  4. [系统] 执行并返回结果
后置条件：[数据状态变化/日志记录/通知发送]
异常流程：
  - 权限不足时：返回无权限提示，不暴露数据
  - 数据不存在时：返回空结果，不报错

2.3 场景与权限的对应关系

每个用户场景都会映射到一组权限点。一个场景可能涉及多个权限点（查看、新建、修改、删除），同一个权限点也可能被多个场景复用。下图展示了从场景到权限的典型映射链路。

场景与权限的对应关系表：

2.4 从场景描述到权限定义的常见问题

• 角色混淆：将“岗位”直接当作“角色”。例如“客服主管”在审核退款场景中是主管角色，但在查看团队考勤场景中可能是“管理员”角色。必须按场景独立定义角色。
• 权限颗粒度太粗：只定义“客服-读权限、主管-写权限”，无法区分“退款申请创建”和“退款审批更新”。应拆分为原子权限点。
• 遗漏异常场景：只写正常流程，未写“权限不足时”、 “操作被拒绝时”的体验要求，导致开发阶段反复沟通。
• 场景重复覆盖：多个场景描述同一操作，但用了不同的场景名称，导致权限点重复定义。