第3章 需求分类与标签：功能类/非功能类/体验类/合规类
适用场景
- 需求条目已完成初步描述和优先级排序，进入精炼(Sprint Refinement)阶段。
- 需要为需求分配责任人、开发团队或测试资源。
- 需求库需要建立可检索、可聚合的结构化元数据。
- 跨职能团队（产品、开发、测试、合规）需就需求影响范围达成一致。
前置条件
- 已产出第2章《结构化需求描述模板》中定义的需求描述卡片（包含唯一ID、标题、用户故事/行为描述）。
- 已确定组织级需求分类标准（本文档遵循四类体系）。
- 已建立或确定标签编码规则（例如：前缀+层级）。
操作步骤
- 阅读原始描述：通读需求卡片全文，理解其核心变更意图。
- 判断第一分类：根据下表“四类需求分界条件”将需求归入功能类 / 非功能类 / 体验类 / 合规类之一（单选）。
- 分配责任边界：基于分类结果指定主要负责角色（见责任边界部分）。
- 打标签（可多选）：从预设标签体系中选取1-3个标签，覆盖业务域、技术栈、用户角色、优先级维度。
- 填写分类记录：将分类结果、标签、责任人写入需求入库清单（输入输出物）。
四类需求分界条件表
| 分类 |
核心判别问句 |
典型举例 |
责任角色 |
| 功能类(F) |
用户能做一件具体的事？直接改变系统状态？ |
“增加导出CSV按钮” |
产品经理 / 后端开发 |
| 非功能类(NF) |
系统表现如何？可测量(性能/可用性/安全性)？ |
“API响应时间 ≤ 200ms” |
技术负责人 / SRE |
| 体验类(UX) |
用户主观感受？界面/交互/易用性？ |
“统一所有页面的错误提示风格” |
UX设计师 |
| 合规类(C) |
法规/行业标准/合同要求？不实现有法律风险？ |
“GDPR数据删除请求接口” |
法务 / 安全团队 |
标签体系建立原则
- 层级：标签建议分两级（域:子域），例如
支付:退款流程。
- 唯一性：同一级标签不能语义重叠。
- 可扩展：标签库预留每周新增5%的容量，避免硬编码。
- 标签示例（非穷举）：
业务域: 支付 | 用户管理 | 报表
技术栈: 移动端 | Web | API
用户角色: 管理员 | 普通用户 | 访客
优先级标签: P0 | P1 | P2
分类与标签流程SVG
输入输出物
| 类型 | 名称 | 格式/位置 | 责任人 |
|---|
| 输入 | 需求描述卡片 | Jira / Confluence / 需求库 | 需求提出方 |
| 输出 | 已分类&打标签的需求条目 | 同需求库，附加分类元数据 | 需求分析师 / PO |
| 输出 | 标签库更新日志 | 共享文档 / 代码仓库(JSON) | 需求管理委员会 |
责任边界
- 需求分析师：负责执行分类和打标签动作，对第一分类的准确性负主要责任。
- 技术负责人：对非功能类需求的确认有一票否决权；协助技术标签准确性。
- 合规专家：对合规类需求有一票判定权；其他分类不得标注为合规。
- 产品负责人(PO)：在争议分类（如功能 vs 体验）时拥有最终仲裁权。
记录材料
- 需求入库清单（表格）：至少包含列——需求ID、标题、分类(F/NF/UX/C)、标签、分配责任人、分类日期、确认人。
- 标签字典：记录每个标签的名称、层级、创建日期、使用频率。
- 分类仲裁纪要：仅当出现分类争议时记录，保存至项目知识库。
异常处理
常见误分类场景及对策：
- 模糊边界（功能 vs 体验）：如果需求同时包含功能按钮和视觉调整，按核心意图归类；若意图不清，列为功能类并附加体验标签。
- 合规类遗漏：每条需求增加“是否需要合规审查”布尔字段，强制触发分类判断。
- 标签冲突（同名不同义）：立即停用冲突标签，由标签管理委员会重新定义，并更新所有相关需求记录。
验收标准
- 需求库中所有已入库条目均携带 分类字段，无空值。
- 随机抽取10条需求，由另一名分析师复核，分类一致率 ≥ 90%。
- 标签体系内无同名标签，每个标签在需求库中至少关联1条需求。
- 合规类需求均带有法务审批时间戳，否则视为无效分类。