需求表达规范解决的是“需求写成什么样”的一致性问题：同一类需求，无论谁提交、谁评审，都应遵循相同的载体、字段和书写约定。本文围绕用户故事、用例、业务流程和验收条件四类载体，说明规范应包含的内容框架、载体选择原则、分步编写方法、角色分工、改写示例与完成检查，帮助团队制定一份可直接投入使用的规范文档。
要点总览（TL;DR）
- 需求表达规范由三层构成：载体选择规则、字段与格式约定、评审与维护机制，三层齐备才能约束实际提交。
- 载体按需求要回答的核心问题选择：用户价值用用户故事，角色与系统交互用用例，跨角色交接用业务流程，完成标准统一用验收条件。
- 编写规范按五步推进：盘点高频问题、定义字段、规定格式与术语、写正反示例、形成模板并接入提交入口。
- 落地时明确需求提出者、分析者、开发与测试代表、评审组织者和规范维护人的职责，评审设在进入开发排期之前。
- 发布前用范围、字段、示例、评审机制、维护责任、模板与试点计划逐项核对，试点一个迭代后做第一次修订。
需求表达规范先定什么：载体、字段与书写约定
一份需求表达规范应包含三层内容：第一层规定什么类型的需求用什么载体表达；第二层规定每类载体的必填字段、选填字段和书写格式；第三层规定评审口径、维护责任和变更方式。三层缺一不可——只有载体没有字段，写出来的内容仍然参差不齐；只有字段没有评审口径，规范无法约束实际提交。
规范开头需要写清适用范围。例如“适用于本产品线的功能需求与业务规则需求，覆盖从需求提出到进入开发排期前的表达环节”，同时写明不适用范围，如系统架构设计、界面视觉稿、运营活动文案等由其他文档承载的内容。范围写得越具体，后续争议越少。
规范的内容框架可按以下清单组织：
- 目的与适用范围：规范约束哪些需求类型、在哪个环节生效、由谁执行。
- 载体选择规则：需求类型与表达载体的对应关系及判断依据。
- 字段定义：每类载体的必填字段、选填字段、字段含义与填写要求。
- 书写格式与命名约定：标题格式、编号规则、术语用法、状态标识。
- 示例：每类载体至少一个正例和一个反例。
- 评审与维护：评审角色、评审时点、规范维护人和变更记录方式。
- 模板与入口：模板文件位置，以及需求提交时必须使用的入口。
框架确定后，建议先选一类高频需求试点，例如团队中数量最多的功能需求，把这一类写透再扩展，避免规范一次覆盖全部需求类型却每类都写得含糊。
按需求类型选择表达方式：用户故事、用例、流程与验收条件
不同需求适合不同载体，判断依据是需求要回答的核心问题：回答“谁要什么价值”用用户故事，回答“角色与系统如何交互”用用例，回答“跨角色如何顺序交接”用业务流程，回答“怎样算做完”用验收条件。四类载体可以组合使用，验收条件作为共同补充，附着在其他载体之后。
| 需求类型 | 推荐载体 | 适用场景 | 需配套内容 |
|---|---|---|---|
| 面向用户的功能需求 | 用户故事 | 需求以用户价值和使用场景为主，粒度适合一个迭代内交付 | 验收条件、优先级 |
| 角色与系统的交互需求 | 用例 | 存在多个角色、多条操作路径，需要描述主流程与异常分支 | 前置条件、异常分支、验收条件 |
| 跨部门或跨系统的流程需求 | 业务流程 | 涉及多个角色或环节的顺序、交接与状态变化 | 流程节点说明、角色职责、异常处理 |
| 规则与约束类需求 | 业务规则说明 | 计算规则、校验规则、权限规则等需要精确表述的内容 | 规则示例、边界条件、验收条件 |
| 各类需求的完成标准 | 验收条件 | 所有需要验证的需求 | 与所属载体关联 |
用户故事通常写成“作为某角色，我希望完成某动作，以便获得某价值”的句式，它擅长表达意图，但本身不包含完成标准，因此必须配套验收条件，否则开发与测试对“做完”的理解容易分歧。用例适合交互路径较复杂的场景，需要写清前置条件、主流程步骤、异常分支和结束状态；步骤按角色动作与系统响应交替描述，避免把界面细节混入流程。业务流程适合跨角色、跨环节的需求，重点写清每个节点的责任人、输入、输出和交接条件，以及异常时的回退路径。
选择载体时还要考虑团队的实际使用成本：用例的编写成本高于用户故事，适合交互复杂、返工代价高的需求；简单功能强行套用例模板，会产出大量形式化内容。规范中应给出判断口径，例如“涉及三个及以上角色或两条以上异常分支的需求使用用例，其余使用用户故事加验收条件”。
规范正文怎么写：字段、格式与示例的编写步骤
编写规范本身是一个有输入、有动作、有输出的过程，建议按以下五步推进，每步完成后留下可检查的产物。
第一步：盘点现有需求文档，归纳高频问题。输入是近三到六个月的需求文档、评审记录和缺陷记录；动作是抽样阅读并归类问题，例如“缺少验收条件”“角色描述模糊”“流程缺少异常分支”“同一概念多种叫法”；输出是一份问题清单，按出现频次排序。这份清单决定规范优先约束哪些字段。
第二步：为每类载体定义必填字段与选填字段。输入是第一步的问题清单和载体选择规则；动作是逐类列出字段，必填字段对应高频问题，选填字段留给复杂场景。以用户故事为例，必填字段可包括：故事标题、角色、目标动作、业务价值、验收条件、优先级、提出人；选填字段包括：关联流程、依赖需求、原型链接。输出是一张字段表，每个字段写明含义和填写要求。
第三步：规定书写格式与命名约定。动作包括：统一标题格式（如“模块名-动作-对象”）、统一编号规则、统一术语表（同一概念只用一个词）、规定状态标识（草稿、待评审、已确认、已变更）。输出是格式约定章节和术语表。术语表看似琐碎，却是减少评审来回的有效手段。
第四步：为每类载体各写一个正例与一个反例。正例取自团队真实需求并改写，反例取自常见错误写法，两者并排展示，并注明反例的问题所在和修改理由。输出是示例章节。示例比字段说明更能让新成员理解规范要求。
第五步：形成模板文件并纳入需求提交入口。动作是把字段表转化为可填写的模板（文档模板或需求条目字段配置），放到团队统一的位置，并规定需求提交时必须使用模板。输出是模板文件、存放位置说明和提交入口说明。模板上线后，规范正文与模板保持同步更新。
角色分工与交付物：谁写、谁审、谁维护
规范落地需要明确每个环节由谁负责、产出什么。常见分工如下，团队可根据规模调整角色名称，但职责边界应保持清晰。
| 角色 | 在表达环节的职责 | 主要交付物 |
|---|---|---|
| 需求提出者 | 按模板提交原始需求，说明业务背景、目标角色和期望结果 | 需求初稿、业务背景说明 |
| 需求分析者 | 选择表达载体，补全字段，编写用户故事或用例，组织验收条件 | 规范化的需求条目、验收条件 |
| 开发代表 | 评审需求的可实现性与字段完整性，提出澄清问题 | 评审意见、技术约束说明 |
| 测试代表 | 评审验收条件是否可验证、是否覆盖异常场景 | 验收条件补充意见、测试要点 |
| 评审组织者 | 安排评审时点，记录结论与待办 | 评审记录、需求状态更新 |
| 规范维护人 | 维护规范正文、模板与术语表，处理变更建议 | 规范版本、变更记录 |
评审时点建议设在需求进入开发排期之前，评审对象是规范化后的需求条目而非原始描述。评审结论分为通过、有条件通过和退回补充三类，退回时需指明缺失的字段或不可验证的验收条件。规范维护人建议由需求分析团队中的固定成员担任，变更记录写明变更日期、变更内容、影响范围和生效时间，避免规范在多次口头修改后失去权威性。
当需求条目、验收条件和评审状态需要在同一处流转时，可以借助研发管理工具承载：需求提出者在系统中提交条目，需求分析者按模板字段补全并关联验收条件，开发和测试在评审环节直接对条目发表意见，状态随评审结论更新。ONES 支持需求工作项的自定义字段、验收条件记录与评审状态流转，适合把上述分工固定到系统流程中，减少规范与执行两张皮的情况。
示例：一条需求从原始描述到规范表达的改写
以下为演示情景，用于说明改写方法，不代表真实项目。
原始描述：“希望系统能导出报表，方便领导看数据，最好快一点。”
这条描述存在几个典型问题：角色模糊（“领导”具体指哪类使用者）、目标动作不完整（导出什么范围、什么格式的数据）、价值表述空泛（“方便看数据”无法验证）、缺少完成标准（“快一点”没有口径）、没有说明异常情况（数据为空或量很大时如何处理）。
按规范改写后的用户故事：
- 标题：报表模块-导出-月度销售汇总
- 角色：区域销售经理
- 目标动作：按选定的月份和区域导出销售汇总报表
- 业务价值：用于月度经营复盘，替代当前手工汇总
- 优先级：高
- 关联流程：月度经营复盘流程
配套验收条件：
- 选择月份和区域后，可导出包含销售额、订单数、退货数三项指标的汇总文件。
- 导出文件格式为表格文件，列名与报表页面一致。
- 所选范围内无数据时，导出文件包含表头并提示“无数据”。
- 数据量在十万行以内时，导出在三十秒内完成；超出时给出进度提示。
流程说明补充：区域销售经理发起导出，系统生成文件后通知发起人下载；财务复核环节使用同一份导出文件，若发现口径差异，由需求分析者确认指标定义后更新报表规则。
改写前后对照：角色从“领导”明确为区域销售经理；动作从“导出报表”细化为按月份和区域导出指定指标；价值从“方便看数据”落到“替代手工汇总、用于月度复盘”；完成标准从“快一点”变为可验证的格式、内容和时间要求；新增了无数据和超大数据量两个异常场景的处理约定。改写的核心是把无法验证的表述替换为可检查的字段和条件，而非增加篇幅。
完成检查：规范是否可用的核对项
规范写完后，用以下清单逐项核对，全部通过再正式发布。
- 范围明确：规范写清了适用的需求类型、生效环节和不适用范围。
- 载体规则可判断：给出载体选择的判断口径，团队成员面对一条新需求能独立选出载体。
- 字段完整：每类载体的必填字段、选填字段均有定义，字段含义无歧义。
- 格式一致：标题、编号、术语、状态标识的约定统一，术语表已建立。
- 示例覆盖主要载体：用户故事、用例、业务流程、验收条件均有正例和反例，反例注明问题所在。
- 验收条件可验证：示例中的验收条件能由测试人员直接判断通过与否。
- 评审机制明确：评审角色、评审时点、结论分类和退回规则已写入规范。
- 维护责任到人：规范维护人、变更记录方式和版本更新节奏已确定。
- 模板可用：模板文件已放入统一位置，需求提交入口已关联模板。
- 试点与扩展有计划：明确先试点的需求类型、试点周期、反馈收集方式和后续扩展的载体范围。
核对中发现的问题应回到对应章节修订，而不是在检查清单上打勾了事。试点运行一个迭代后，收集需求分析者和评审者的实际使用反馈，重点看哪些字段经常被跳过、哪些示例被反复引用，据此做第一次修订，再逐步扩展到其他需求类型。
常见问题
团队需求数量不多，还需要写完整的表达规范吗？
需求数量少时，规范可以精简，但不宜省略。可以先只覆盖一类高频需求，把载体选择、必填字段和验收条件写清楚，评审与维护机制用一两段说明即可。精简版规范同样要写清适用范围，避免后续需求类型增多时反复补规则。等需求量和参与角色增加，再按正文的框架逐步扩展字段与示例。
用户故事和用例可以同时用在同一需求上吗？
可以，但要有主次。常见做法是以用户故事表达需求意图和价值，再用用例描述其中交互复杂的那部分路径，验收条件附着在两者之后。需要避免的是同一需求在两处重复描述同一内容，导致修改时只改了一处。规范中可约定：用户故事负责“为什么做、给谁做”，用例负责“怎么交互、异常怎么处理”，两者通过需求编号关联。
验收条件写到什么程度算可验证？
判断标准是测试人员能否不追问就给出通过或不通过的结论。可验证的验收条件通常包含具体对象、操作、预期结果和必要的边界条件，例如数据范围、格式、时间要求或异常提示。像“体验流畅”“尽量快”这类表述需要换成可观察的口径。若某项要求暂时无法量化，应写明由谁在什么时点确认，而不是留空。
规范发布后，团队成员仍按老习惯提交需求怎么办？
先检查提交入口是否真的接入了模板：如果模板只是放在文档库里，提交时仍可自由填写，规范就很难生效。把必填字段配置到需求提交入口，评审时以字段完整性作为退回依据，执行会明显改善。同时保留一段过渡期，对退回的需求给出具体补充指引，而不是只标注“不合规”。试点一个迭代后，根据被跳过最多的字段调整模板，减少形式化填写。
规范应该多久修订一次？
建议设定固定节奏与触发条件相结合的方式：固定节奏可以按季度检查一次，触发条件是出现新的需求类型、评审中反复出现同类争议，或模板字段被大面积跳过。每次修订记录变更日期、内容、影响范围和生效时间，并同步更新模板与示例。修订幅度较大时，先在小范围试用再全面推行。
