第4章 权限需求文档的结构化拆解：用户故事、权限规则表、异常分支
4.1 业务背景与用户场景
权限模块常因需求描述模糊导致开发误解：产品经理仅写“管理员可查看所有数据”，开发则自行解释为“所有页面可见，未限制列级权限”。结果上线后出现数据泄露，返工成本高昂。本章聚焦于如何通过结构化拆解，将模糊的权限需求转化为可验证、可测试的文档。
典型用户场景（以企业CMS系统为例）：
- 场景A：内容编辑员只能编辑自己创建的文章，不能查看他人草稿；
- 场景B：部门主管可查看本部门所有人员的提交记录，但不能删除；
- 场景C：系统管理员拥有全平台权限，但需在操作日志中记录每一次修改。
4.2 用户访谈与问题定位
通过访谈实际用户（编辑、主管、审计）发现三个核心痛点：
- 权限颗粒度不明确：“能看”不等于“能复制”、“能导出”；
- 异常行为漏处理：当用户被撤销权限后，已打开的页面是否应立即锁定？
- 规则边界模糊：“查看本部门数据”如何定义跨部门项目时成员的区域？
✏️ 需求拆解要点：在用户访谈后，需将每一条口述需求映射到至少三个维度——角色、资源、操作。缺少任一维度即为无效需求。
4.3 结构化拆解：三要素框架
将一条权限需求拆解为三个组成部分，每个部分对应独立的文档模块：
| 要素 | 示例 | 对应文档结构 |
|---|---|---|
| 1. 用户故事 | 作为内容编辑员，我希望只能编辑自己发布的文章，以避免误操作他人内容。 | 需求编号 + 故事卡片 |
| 2. 权限规则表 | 角色: 编辑 | 资源: 文章(article) | 操作: create/update/delete_own | 条件: creatorId==userId | 表结构：角色、资源、操作、约束、生效时机 |
| 3. 异常分支 | 当编辑被停用后，已打开的编辑页面提交时返回401，并给出“权限已变更，请刷新”提示。 | 异常场景编号 + 预期行为 |
4.4 用户故事编写规范
用户故事应遵循「角色 – 目标 – 理由」标准模板，并附加验收条件（AC）。示例如下：
US-001：查看个人文章列表
角色：内容编辑员
目标：我希望在左侧菜单点击“我的文章”后，只看到我本人创建的文章（不含草稿状态）
理由：避免被其他编辑员的草稿干扰，提升工作效率
验收条件：
AC1：列表只显示 creator_id == 当前用户ID 的文章
AC2：列表不包含状态为“草稿”但 creator_id == 当前用户ID 的文章（此条由规则表另行定义）
AC3：如果当前用户是管理员，则列表显示全部文章4.5 权限规则表设计模板
权限规则表是结构化的核心产出，采用行列交叉定义。以下为CMS系统简化版规则表：
| 资源 | 操作 | 编辑员 | 主管 | 管理员 |
|---|---|---|---|---|
| 文章(article) | create | ✓ | ✓ | ✓ |
| 文章(article) | read | 只读自己 | 本部门 | 全部 |
| 文章(article) | update | 自己创建 | 本部门 | 全部 |
| 文章(article) | delete | ✗ | ✗ | 全部 |
每条规则需额外附加约束条件（如：只能操作状态≠“已发布”的文章）和生效时机（如：资源加载时、提交时）。
4.6 异常分支清单
权限模块的异常分支常被遗漏，导致原型验证时无法覆盖边界。以下为必须考虑的异常类别：
- 角色变更：用户角色在操作过程中被修改（如从编辑降为只读）；
- 资源状态变化：用户打开编辑页面后，该资源被管理员锁定或删除；
- 权限过期：临时授权有时间限制，超时后仍执行写操作；
- 并发冲突：同一角色由多个管理员同时编辑权限配置。
🚨 常见陷阱：不要将异常分支写成“系统报错”——必须明确错误码、前端提示文案、后续操作（如是否刷新页面、是否弹窗）。否则开发会将其留空，导致用户体验断裂。
4.7 交付物模板汇总
本章对应的交付物包含以下三个模板，可直接用于原型阶段的评审：
- 用户故事卡片（包含ID、角色、目标、理由、验收条件列表）
- 权限规则矩阵（Excel/表格形式，含角色×资源×操作，以及约束条件）
- 异常分支检查表（按优先级列出异常场景、预期前端行为、后端返回规格）
4.8 结构化拆解流程总图
下图展示了从原始需求到三要素产出的完整流程：
📋 验收标准（本章交付物通过条件）
- 每个角色至少关联3个操作（增/删/改/查/导出/审批等）；
- 权限规则表中每个单元格要么是“✓”、“✗”，要么是具体的约束条件（不能空缺）；
- 异常分支清单不少于5条，且每个异常都写明了前端反馈内容与HTTP状态码/错误码；
- 用户故事中的验收条件已转化为规则表中的明确行或列入异常分支。
4.9 本章指标验证方法
建议使用需求覆盖矩阵来验证拆解是否完整：
需求覆盖矩阵（示例）
需求编号 | 是否包含用户故事 | 是否映射规则表行 | 是否覆盖异常分支
US-001 | ✓ | 3行（read/create/update） | 新增2条异常
US-002 | ✓ | 2行（read） | 1条异常
... | ... | ... | ...覆盖率要求：所有初级权限需求（用户访谈记录）至少对应一条规则表行，100% 关联。异常分支覆盖率不低于 80%，否则返工补充。