第2章：权限需求分析——用户故事地图、角色-权限矩阵、场景卡片

2.1 业务背景与痛点

在协同办公类SaaS产品中，权限模块往往是后期返工率最高的部分。开发团队经常遇到以下问题：

• 需求遗漏：早期只定义了“管理员”和“普通用户”，上线后才发现缺少“项目审计员”角色。
• 边界模糊：产品说“编辑者可以删除自己的文档”，开发理解成“编辑者可以删除所有文档”。
• 测试困难：没有明确的权限矩阵，测试用例只能靠猜测，导致线上出现越权操作。

这些问题的根源在于：权限需求没有被结构化表达。本章将用三种互补的工具——用户故事地图、角色-权限矩阵、场景卡片——来系统化地捕获、组织、验证权限需求。

2.2 用户故事地图：建立权限的“用户视角”

用户故事地图不是简单的用户故事列表，而是按用户活动和任务步骤组织的二维结构。它帮助团队在全局视角下发现不同角色的权限差异。

2.2.1 识别角色与活动

以一个知识库系统为例，我们通过用户调研识别出以下角色和核心活动：

2.2.2 构建用户故事地图

将上述任务按“用户访问产品的完整旅程”从左到右排列，形成一条“时间线”或“流程线”。每个角色对应的任务卡片放在对应活动下方：

1. 第一层（用户活动）：进入系统 → 查找内容 → 阅读/互动 → 管理内容 → 退出系统
2. 第二层（具体任务）：在每个活动下，用卡片列出各角色的具体任务，并用颜色标记直接标注权限差异。例如，在“管理内容”活动下，“删除文档”卡片只有超级管理员和空间管理员拥有，编辑者只能“归档”，查看者看不到该卡片。
3. 输出产物：一张物理或数字化的故事墙，让所有干系人对“谁在什么情况下能做什么”达成共识。

2.3 角色-权限矩阵：把模糊需求变成“可执行合约”

用户故事地图产出的还是相对松散的结构，下一步需要将其转化为精确的二维表格——行是功能/资源，列是角色，单元格用 ✓ / ✗ / 条件 标识权限。

2.3.1 从故事地图中提取矩阵元素

将用户故事地图中的每个任务卡片映射为矩阵中的一行“权限对象”，每个角色映射为一列。例如：

2.3.2 矩阵的分类与分层

在实际项目中，一个完整的权限矩阵可能包含数十甚至上百行。建议按功能模块对矩阵进行分组：

• 空间管理模块：创建、删除、修改空间属性、空间成员管理。
• 文档管理模块：创建、编辑、删除、移动、复制、分享、导出文档。
• 系统设置模块：角色管理、日志审计、全局策略配置。

分组后的矩阵更容易阅读，也便于在Axure中按模块设计原型页面。

2.4 场景卡片：为原型设计提供“行为用例”

矩阵是静态的，但用户的操作是动态的。场景卡片用于描述一个具体用户在一个具体情境下，为完成一个目标所经历的操作路径。

2.4.1 标准场景卡片结构

每张卡片包含以下字段，直接支撑Axure原型的交互逻辑：

2.4.2 从矩阵导出场景卡片

矩阵中的每个 ✓ 或 条件 都可以衍生出至少一个场景卡片。特别地，对权限边界（即“什么情况下不能做”）也需要创建卡片：

• 正常场景：空间管理员成功邀请新成员（矩阵中 ✓）。
• 异常场景：查看者尝试点击“删除文档”按钮，按钮为灰色不可点击，并悬浮提示“您没有权限执行此操作”。
• 边界场景：编辑者尝试删除自己已归档的文档，系统提示“已归档文档需联系空间管理员删除”。

2.5 三者的联动关系（SVG）

下面的SVG展示了用户故事地图、角色-权限矩阵、场景卡片在整个权限需求分析流程中的协作关系，以及它们如何共同输送给后续的原型设计环节。

2.6 验收标准：如何确认需求分析到位？

在进入Axure原型设计之前，请用以下清单验证本章的工作成果：

• 完整性：用户故事地图至少覆盖了所有识别出的角色和核心活动，且每个活动下的任务都标注了权限状态。
• 精确性：角色-权限矩阵的每个单元格都有明确的值（✓ / ✗ / 条件），没有空单元格或模糊表述。
• 可测试性：场景卡片覆盖了所有“✓”对应的正常场景，以及至少50%的“✗”对应的异常/边界场景。
• 一致性：三种工具之间没有相互矛盾的需求（例如：矩阵中编辑者可删除自己文档，但卡片中未描述前置条件）。