第4章 需求层次分析：功能需求、非功能需求、体验需求、约束条件

4.1 需求层次模型概述

产品需求不是单一维度的愿望清单，而是由多个层次构成的有机体。每个层次回答不同的问题，对应不同的验证方式，并在 PRD 与原型设计中承担不同角色。缺乏层次分析的需求文档，往往在开发阶段暴露大量歧义，导致返工。

四个层次不是孤立存在的：功能需求是骨架，非功能需求是肌肉，体验需求是皮肤，约束条件是包裹所有组织的边界。下面通过一张结构图直观展示它们之间的递进与制约关系。

4.2 功能需求：系统的“必须做”

功能需求描述系统在特定场景下必须提供的具体能力。它直接回答业务问题，是 PRD 中最基础、最容易被 stakeholders 感知的部分。

• 业务功能——用户通过系统完成的业务操作，如“创建工单”、“审批流程”。
• 数据功能——数据的创建、存储、查询、导出，如“导出月度报表为 Excel”。
• 接口功能——系统与外部模块或第三方服务的交互，如“对接支付网关”。

4.3 非功能需求：系统的“做得好”

非功能需求定义系统在运行时的质量属性。它不改变功能行为，但决定用户是否愿意持续使用。在原型设计阶段，非功能需求直接影响技术选型与架构方案。

4.4 体验需求：用户的“感觉好”

体验需求关注用户在与系统交互过程中的主观感受与完成效率。它介于功能需求与 UI 设计之间，是 PRD 中容易被“原型美化”替代、但实则必须独立定义的一层。

• 易用性——新用户在没有培训的情况下能否完成核心任务？
• 效率——熟练用户完成重复操作需要几步？是否有快捷键或批量能力？
• 情感化——空状态、错误提示、加载动画是否让用户感到被理解而非被指责？

验收方式： 体验需求不适合用“我觉得不好看”来评审。应使用可用性测试（如 SUS 评分）、任务完成率、单任务操作时长等量化指标进行验证。

4.5 约束条件：不可逾越的边界

约束条件不是需求本身，而是需求实现过程中必须遵守的限制。它通常来自业务、技术或法规层面，在需求拆解阶段必须明确记录，否则会导致方案被推翻。

4.6 从用户场景到需求拆解实战

下面以一个真实场景为例，演示如何从用户访谈出发，经过需求层次分析，最终输出可验收的 PRD 条目。

用户场景： 某物流公司的调度员每天需要手动分配 200+ 运单，当前使用 Excel 管理，容易漏单、错分，希望通过系统实现智能调度。

需求拆解步骤：

1. 用户访谈——发现调度员最痛的是“高峰期运单堆积时凭记忆分配”，核心诉求是“系统自动推荐最优路线”。
2. 业务问题定义——运单分配效率低、人工错配率约 8%，目标是将分配时间缩短 60%，错配率降至 1% 以下。
3. 功能需求——运单批量导入、智能路线推荐、调度结果一键下发。
4. 非功能需求——推荐引擎响应 <3s，支持 500 单并发导入。
5. 体验需求——调度员可在 2 次点击内完成人工修正，推荐结果附带原因说明。
6. 约束条件——必须使用现有地图 API，服务器不可上公有云（公司政策）。

验收标准模板：

验收标准清单（以“智能路线推荐”为例）：
- 功能：上传 200 单后，系统在 3s 内返回推荐路线，准确率 ≥ 95%
- 非功能：推荐接口 P99 响应 ≤ 3s，CPU 峰值 < 70%
- 体验：调度员修改推荐结果的操作路径 ≤ 2 次点击
- 约束：仅使用高德地图 API，不依赖其他地图服务

交付物模板：需求层次检查清单（可在 PRD 中直接使用）：

## 需求层次检查清单（模板）

### 功能需求
- [ ] 每个功能是否对应一个具体用户场景？
- [ ] 是否有重复或重叠的功能？
- [ ] 异常流程（空值、超时、失败）是否已定义？

### 非功能需求
- [ ] 是否有明确的性能指标（响应时间、并发量）？
- [ ] 安全要求是否写入（加密、认证、审计）？
- [ ] 可维护性要求（日志、配置、监控）是否覆盖？

### 体验需求
- [ ] 是否定义了任务完成率/操作步数阈值？
- [ ] 空状态、错误态、加载态是否有设计要求？
- [ ] 是否考虑了键盘操作、屏幕阅读器等无障碍场景？

### 约束条件
- [ ] 技术栈、框架版本是否已确认？
- [ ] 预算、时间、人力上限是否书面明确？
- [ ] 法规/合规要求（GDPR、等保等）是否已对标？