第1章：权限需求在PRD中的定位：PRD核心模块、边界与常见类型

权限需求不是PRD里的“附属品”或“安全补丁”。在一次真实的B端产品升级中，业务方要求“部门主管能看到下属的业绩”，开发团队按字面意思开发了全量数据面板。上线后，HR投诉数据泄露，财务拒绝签收，产品经理被迫连夜补权限文档——原因是PRD没有定义“谁能看什么数据”这一核心边界。

权限需求在PRD中的正确定位应该是“业务规则的数据护栏”。它决定了用户在该场景下能做什么（功能权限）、能看到什么（数据权限）、需要谁同意（审批权限）。脱离了权限描述的业务流程，在交付时几乎必然出现“功能可用但不可用”的窘境。

1.1 PRD核心模块：权限需求是业务逻辑的“开关层”

标准的PRD通常包含用户故事、业务流程、字段定义、异常处理等模块。权限需求在这些模块中扮演“条件门禁”的角色：它不改变业务流程的主路径，但决定了主路径上的每一个节点“谁可以触发”“谁可以查看”“谁可以修改”。

1.2 权限需求与其他需求的边界

权限需求经常与功能需求、数据需求、安全需求混淆。区分它们的边界是结构化描述的第一步：

需求类型	典型描述	是否属于权限需求
功能需求	用户可以在导出页面选择日期范围并点击“导出Excel”	否。功能需求描述“做什么”，权限需求描述“谁可以做”。
数据需求	导出文件包含订单号、金额、下单时间	否。数据需求指“输出内容”，权限需求指“谁能看到这些内容”。
权限需求	只有角色“财务主管”可以看到导出按钮；导出数据中，普通财务人员只能看到金额≤5万元的订单	是。明确描述了访问主体与客体之间的条件约束。
安全需求	导出文件必须加密传输，日志保留90天	否。安全需求侧重“防护与审计”，与业务操作权限是正交关系。

1.3 权限需求的常见类型：功能/数据/审批

在PRD中进行结构化描述时，权限需求应分为三类，每类的描述模板和关注点各不相同：

1. 功能权限：控制用户是否可以看到或操作某个功能入口/按钮。典型例子如“角色A能看到【删除】按钮，角色B看不到”。

   结构化字段示例：功能入口 / 操作名称 / 允许角色列表 / 条件表达式（如：仅当订单状态=已取消时显示）

2. 数据权限：控制用户可以看到哪些数据行或数据列。典型例子如“销售经理可以看到下属全部客户，销售代表只能看到自己负责的客户”。

   结构化字段示例：数据对象（如：客户表） / 行过滤规则（如：owner = 当前用户） / 列可见性规则（如：手机号仅对主管可见）

3. 审批权限：控制某个操作是否需要他人同意，以及由谁来审批。典型例子如“订单金额超过10万元时需要总监审批”。

   结构化字段示例：触发条件（如：金额 > 100000） / 审批人定义 / 会签/或签规则 / 超时处理

下图展示了三类权限在业务场景中的协同关系：功能权限控制“门”（能否看到页面/按钮），数据权限控制“货架上的商品”（能看到哪些数据），审批权限控制“高价商品的购买需要店长同意”。

1.4 在PRD中结构化描述权限需求的方法

为了后续RICE评估和团队对齐，权限需求在PRD中不应以自然语言段落散落，而应使用标准化的字段表格进行定义。以下是一个可直接复用的权限定义模板：

权限条目ID: PERM-2025-001
业务场景: 销售代表查看客户列表
功能权限: 角色["销售代表","销售经理"] 可访问 /customer/list 页面
数据权限: 
  - 行规则: customer.owner_id = 当前用户.id  OR  customer.team_id IN (当前用户所在团队)
  - 列规则: 手机号仅对角色["销售经理"]可见；其余列所有角色可见
审批权限: 无（仅查看操作不触发审批）
备注: 如果客户被标记为“VIP”，则对销售代表隐藏该客户，仅经理可见