权限需求文档的编写要素
本章聚焦：从用户故事、角色定义、权限粒度、例外规则四要素出发，建立一套可复用的权限需求编写规范。你将带走一份可直接导入 Axure 的 权限需求文档模板 和对应的交互验证策略。
1. 用户场景：权限需求表达的常见痛点
产品经理在编写权限需求时，经常遇到以下困境：
- 描述模糊：“管理员可以看到所有数据，普通用户只能看到部分”——“部分”是多少？按什么规则切分？
- 角色遗漏：只定义了“管理员”和“普通用户”，但忽略了“审计员”、“超级管理员”、“临时访客”等边界角色。
- 粒度不一致：页面级用表格说明，操作级用文字描述，数据级完全没提——开发拿到需求后反复追问细节。
- 例外场景缺失：正常流程写得很细，但“用户主动申请临时权限”、“节假日自动提升审批额度”等例外规则全部缺失。
典型用户故事片段（来自一线产品经理反馈）：
“作为一个销售主管，我希望只能查看本人及下属的客户详情，但不能修改下属的客户信息，以便在保障数据隐私的同时完成团队管理。”——这段描述包含了角色、权限边界和业务目标，但缺少了“如果下属转岗，历史数据是否保留”的例外规则。
“作为一个销售主管，我希望只能查看本人及下属的客户详情，但不能修改下属的客户信息，以便在保障数据隐私的同时完成团队管理。”——这段描述包含了角色、权限边界和业务目标，但缺少了“如果下属转岗，历史数据是否保留”的例外规则。
2. 业务问题：需求表述混乱导致的连锁反应
权限需求表达不规范，会引发一系列连锁效应：
| 问题环节 | 典型表现 | 直接后果 |
|---|---|---|
| 需求评审 | 角色定义不全，开发质疑“这个角色是否存在” | 评审延期，至少浪费 1 次迭代会 |
| UI 设计 | 权限粒度不明确，设计稿反复修改按钮显隐 | 设计返工 2~3 轮 |
| 开发实现 | 数据级权限未描述，开发按“全部可见”实现 | 上线后数据泄露，紧急 hotfix |
| 测试验证 | 例外规则缺失，测试用例遗漏边界场景 | 线上出现权限绕过漏洞 |
关键数据：根据行业调研，权限相关需求缺陷中，43% 源于需求文档中角色与权限粒度的表述不完整，27% 源于例外规则未编写。这两项合计占权限 Bug 的 70%。
3. 需求拆解：权限需求的四要素
要编写一份高质量的权限需求文档，必须拆解为四个核心要素：用户故事、角色定义、权限粒度、例外规则。四者之间的关系如下：
四要素协作逻辑：用户故事驱动角色定义 → 角色定义锚定权限粒度 → 权限粒度划定控制边界 → 例外规则兜底异常场景。四者闭环，缺一不可。
4. 方案表达：四要素的标准化写法
4.1 用户故事（User Story）
采用标准模板：“作为一个 <角色>，我希望 <功能/权限>，以便 <业务价值>”。每个用户故事必须包含明确的权限诉求。
| 用户故事 ID | 角色 | 权限诉求 | 业务价值 |
|---|---|---|---|
| US-PERM-001 | 销售主管 | 查看本人及下属的客户详情，不可编辑下属客户信息 | 保障数据隐私同时完成团队管理 |
| US-PERM-002 | 财务审计员 | 查看全公司报销单，但不可修改、不可删除 | 满足审计合规要求 |
| US-PERM-003 | 系统管理员 | 创建/禁用/删除用户，并可临时提升任意用户权限 | 保障系统运维灵活性 |
4.2 角色定义（Role Definition）
角色定义需包含：角色名称、所属部门、职责范围、权限边界、角色层级关系。
| 角色名称 | 所属部门 | 职责范围 | 权限边界 | 上级角色 |
|---|---|---|---|---|
| 普通销售 | 销售部 | 管理本人客户 | 不可查看他人客户 | 销售主管 |
| 销售主管 | 销售部 | 管理本人及下属客户 | 不可修改下属客户信息 | 销售总监 |
| 销售总监 | 销售部 | 查看全部客户 | 不可修改，不可导出 | 系统管理员 |
| 财务审计员 | 财务部 | 全量报销单只读 | 不可编辑、不可删除 | — |
4.3 权限粒度（Permission Granularity）
权限粒度分为三个层级，每个层级对应不同的 Axure 交互验证策略：
| 粒度层级 | 控制对象 | Axure 验证方式 | 典型需求示例 |
|---|---|---|---|
| 页面级 | 整个页面/功能模块 | 动态面板切换显隐；页面跳转权限拦截 | “普通用户不显示‘系统设置’菜单入口” |
| 操作级 | 按钮、链接、表单提交 | 元件启用/禁用状态；点击事件拦截并提示 | “审计员不可点击‘删除报销单’按钮” |
| 数据级 | 数据行、字段值、列表范围 | 中继器数据过滤；动态面板展示不同数据视图 | “销售主管只能看到下属的客户列表” |
粒度判定原则：
- 页面级：按角色区分功能入口，属于“有没有”的问题。
- 操作级：在页面内区分可操作元素，属于“能不能”的问题。
- 数据级：在相同页面内展示不同数据范围，属于“看多少”的问题。
三者可以组合使用，例如：销售主管“有”客户管理页面（页面级），“能”点击查看详情（操作级），但“只能”看到下属客户（数据级）。
- 页面级：按角色区分功能入口，属于“有没有”的问题。
- 操作级：在页面内区分可操作元素，属于“能不能”的问题。
- 数据级：在相同页面内展示不同数据范围，属于“看多少”的问题。
三者可以组合使用，例如：销售主管“有”客户管理页面（页面级），“能”点击查看详情（操作级），但“只能”看到下属客户（数据级）。
4.4 例外规则（Exception Rules）
例外规则用于覆盖正常流程之外的边界场景，是权限需求中最容易被遗漏的部分。
| 例外类型 | 触发条件 | 处理方式 | 是否需审批 |
|---|---|---|---|
| 临时授权 | 员工请假，需代管客户 | 主管可申请临时提升某人为“代理销售”，有效期 7 天 | 是（上级审批） |
| 紧急 bypass | 系统故障，需紧急操作 | 超级管理员可临时开启“运维模式”，绕过常规权限检查 | 是（事后审计） |
| 节假日策略 | 法定节假日 | 财务审批额度自动提升 50%，假期结束后恢复 | 否（系统自动） |
| 跨部门共享 | 项目协作，需跨部门查看数据 | 创建“项目共享视图”，指定可见角色与数据范围 | 是（双方部门负责人审批） |
5. 指标验证：文档质量的量化标准
权限需求文档是否合格，可用以下指标衡量：
| 指标名称 | 定义 | 达标标准 |
|---|---|---|
| 完整率 | 已编写的权限条目 ÷ 预期应编写的权限条目 × 100% | ≥ 95% |
| 歧义率 | 评审中标记为“表述模糊”的条目 ÷ 总条目 × 100% | ≤ 5% |
| 可测试率 | 可直接转化为测试用例的条目 ÷ 总条目 × 100% | ≥ 90% |
| 例外覆盖率 | 已编写的例外规则数 ÷ 识别的例外场景总数 × 100% | ≥ 80% |
常见陷阱：不要将“指标验证”理解为“文档写完后再检查”。正确的做法是在编写过程中逐条自检，例如每写完一个用户故事，立即标记对应的角色、粒度、例外是否完备。
6. 验收标准：文档评审通过条件
权限需求文档通过评审，需同时满足以下条件：
- 角色体系完整：所有用户故事中出现的角色，均在“角色定义”中有明确描述。
- 粒度层级清晰：每条权限需求都标注了所属的粒度层级（页面级 / 操作级 / 数据级）。
- 例外规则完备：至少覆盖临时授权、紧急 bypass、节假日策略、跨部门共享四类中的两类以上。
- 可交互验证：文档中的权限规则可直接映射为 Axure 交互用例（显隐、禁用、数据过滤、拦截提示等）。
- 无歧义表述：不出现“部分”、“可能”、“大概”、“合适”等模糊词汇。
7. 交付物模板：权限需求文档标准模板
以下模板可直接复制到你的需求文档中，或在 Axure 中创建对应的富文本说明页：
# 权限需求文档模板
## 1. 用户故事清单
| ID | 角色 | 权限诉求 | 业务价值 | 关联角色 |
|----|------|---------|---------|---------|
| | | | | |
## 2. 角色定义表
| 角色名称 | 所属部门 | 职责范围 | 权限边界 | 上级角色 | 备注 |
|---------|---------|---------|---------|---------|------|
| | | | | | |
## 3. 权限粒度矩阵
| 功能模块 | 页面级权限 | 操作级权限 | 数据级权限 | 粒度说明 |
|---------|-----------|-----------|-----------|---------|
| | | | | |
## 4. 例外规则清单
| 例外类型 | 触发条件 | 处理方式 | 审批流程 | 有效期 |
|---------|---------|---------|---------|-------|
| | | | | |
## 5. Axure 交互映射
| 权限规则 | 页面 | 元件 | 交互类型 | 动态面板状态 | 条件判断 |
|---------|------|------|---------|-------------|---------|
| | | | | | |
模板使用要点：
1. 在 Axure 中为每个功能模块创建独立的“权限规则说明”页面，将上表嵌入说明页。
2. 每个角色对应一套动态面板状态组合，在全局变量中维护当前角色。
3. 例外规则单独录入“例外规则库”页面，并在原型中设置对应的条件判断分支。
4. 模板中的“Axure 交互映射”部分，是连接需求文档与原型验证的核心桥梁，务必逐条填写。
1. 在 Axure 中为每个功能模块创建独立的“权限规则说明”页面，将上表嵌入说明页。
2. 每个角色对应一套动态面板状态组合，在全局变量中维护当前角色。
3. 例外规则单独录入“例外规则库”页面，并在原型中设置对应的条件判断分支。
4. 模板中的“Axure 交互映射”部分，是连接需求文档与原型验证的核心桥梁，务必逐条填写。