制定需求表达规范，核心是把“一条需求要回答哪些问题”固化成必填字段、表达模板和写作规则，再用评审卡点和样例库保证执行。落地顺序为：界定适用范围与需求类型、设计字段与模板、写清表达规则与正反例、明确角色分工与评审卡点、选真实需求试点修订、纳入评审与版本维护。规范的价值在于让提出者、分析者、开发和测试对同一条需求读到相同信息，字段数量控制在能支撑评审和后续设计的最小集合。
要点总览（TL;DR）
- 制定需求表达规范按六步推进：界定适用范围与需求类型、设计字段与模板、写清表达规则与正反例、明确角色分工与评审卡点、选真实需求试点修订、发布前逐项检查。
- 字段设计以支撑评审和后续设计为目标，必填项取最小集合，初次制定控制在六到八个，运行一个迭代后再评估是否增补。
- 表达规则要写成两位评审者独立判断能得出一致结论的条款，每条配合格例、不合格例和修改说明，规则数量控制在十到十五条。
- 规范只管表达形式，需求内容是否成立、优先级如何排序归需求分析与澄清环节，规范只要求这些结论被记录在对应字段中。
- 规范发布后需要版本记录和样例库维护，用试点中的真实正反例做培训，失效信号出现时先检查字段是否过多、规则是否可判断。
规范先定边界：覆盖哪些需求类型与表达层级
规范制定的第一步是划定边界，回答“管哪些需求、管到哪一层”。范围不清时，规范容易写成覆盖所有文档的通用写作要求，执行者无法判断自己手上的需求是否适用。建议先列一份需求类型清单，再为每类需求标注表达颗粒度。
按常见分层，业务需求描述组织希望达成的业务目标与范围；用户需求描述特定角色在特定场景下要完成的任务；系统需求描述系统应提供的行为、数据与约束。团队规模较小时可以只覆盖用户需求和系统需求，业务目标放在项目立项材料中说明。分层的目的在于让不同层级的需求承担不同的表达任务，避免一条需求同时承载业务目标、交互细节和技术约束。
需要明确的是，规范约束的是表达形式：信息是否齐全、描述是否可验证、术语是否统一。需求内容是否成立、优先级如何排序、业务价值多大，属于需求分析与澄清环节的判断，规范只要求这些判断的结论被记录在对应字段中。把内容判断写进表达规范，会让规范变成评审意见汇编，难以维护。
表达层级建议固定为三层：一句话摘要用于列表和看板展示；结构化条目承载背景、描述、验收条件等完整信息；验收条件作为可测试的判定依据单独列出。三层之间是细化关系，摘要由结构化条目提炼，验收条件从描述中拆出。
范围清单可以按下表填写，作为规范正文的第一部分：
| 需求类型 | 是否纳入规范 | 表达颗粒度 | 负责编写角色 | 备注 |
|---|---|---|---|---|
| 业务需求 | 部分纳入 | 目标、范围、成功指标 | 业务负责人 | 仅记录目标与范围，不展开功能细节 |
| 用户需求 | 纳入 | 角色、场景、任务、验收条件 | 需求分析者 | 规范重点覆盖对象 |
| 系统需求 | 纳入 | 行为、输入输出、约束、异常处理 | 需求分析者与开发代表 | 技术约束由开发补充 |
| 变更需求 | 纳入 | 变更点、影响范围、回归验收 | 需求提出者 | 沿用原需求字段并标注变更 |
这张清单的完成标志是：团队任意成员拿到一条需求，能对照清单判断它属于哪类、应写到什么程度、由谁负责补齐。
字段与模板：一条需求要写清哪些信息
字段设计的依据是“这条信息支撑哪项判断”。支撑评审决策、支撑开发设计、支撑测试验证的信息设为必填；仅对部分需求有意义的信息设为选填。每增加一个必填字段，都应能回答它服务于哪项评审或哪次交接，否则容易造成填写负担和形式化填写。
下表给出一套可直接套用的字段表：
| 字段 | 填写要求 | 必填/选填 | 示例 |
|---|---|---|---|
| 需求标识 | 系统生成的唯一编号，便于追溯 | 必填 | REQ-2024-0137 |
| 标题 | 主体+动作+对象，一句话说清诉求 | 必填 | 支持按订单状态筛选待发货订单 |
| 来源 | 提出人、提出渠道、关联的客户或业务场景 | 必填 | 客服团队，2024年3月客户反馈汇总 |
| 背景与目标 | 当前做法的问题、期望达成的结果 | 必填 | 客服需逐页翻找订单，平均处理时长8分钟，目标降至3分钟以内 |
| 描述 | 角色、场景、操作流程、输入输出 | 必填 | 客服在订单列表选择状态为“待发货”，系统返回匹配订单并按时间倒序排列 |
| 验收条件 | 可观察、可测试的判定条目，逐条编号 | 必填 | 选择状态后3秒内返回结果；无匹配订单时显示空状态提示 |
| 优先级 | 按团队统一口径标注，附判断理由 | 必填 | 高：影响客服日均处理量 |
| 关联项 | 关联需求、缺陷、设计文档或项目任务 | 选填 | 关联设计稿 DOC-88 |
| 状态 | 草稿、待评审、已确认、开发中、已验收 | 必填 | 待评审 |
必填与选填的划分可以遵循三条依据：评审时需要据此做取舍的字段必填，如背景与目标、优先级；下游设计或测试需要直接引用的字段必填，如描述、验收条件；只在特定类型需求中出现的信息选填，如关联项、外部依赖说明。团队初次制定规范时，必填字段控制在六到八个，运行一个迭代后再评估是否增补。
模板采用固定结构加可裁剪段落的方式。固定结构包括标题、背景与目标、描述、验收条件四部分，所有需求都必须具备；可裁剪部分包括技术约束、数据迁移说明、兼容性要求，按需求类型决定是否保留。模板中每个字段下方保留一行填写提示，写明“写什么、写到什么程度”，减少填写时的猜测。
规范文档本身也需要承载方式。ONES Wiki 支持使用模板库一键创建制式化文档，页面组可关联项目，需求与文档互相对应，适合放置规范正文、字段说明和样例库；页面版本记录支持随时查看与回滚，规范修订后可以对照历史版本说明变化。规范正文与需求条目分开放置，规范管写法，条目管内容。
表达规则怎么写：句式、粒度与正反例
表达规则要写成能判断合格与否的条款。判断方法是：两位评审者独立阅读同一条需求，对是否违反某条规则得出相同结论。做不到这一点的规则，应改写为更具体的条件，或从规范中删除。
标题句式规则：标题包含动作和对象，必要时补充条件，避免使用“优化”“完善”“支持一下”这类无法判断完成状态的词。描述句式规则：以角色为主语，写清触发场景、操作和系统响应，一句描述一个行为。粒度规则：一条需求只表达一个可独立验收的诉求，包含多个可分别验收的行为时拆分为多条。术语规则：同一概念在全文中使用同一名称，首次出现时给出定义；量词、时间单位、状态名称统一，例如统一使用“3秒内”“工作日”“待发货”等固定表述。
每条规则配一个合格例、一个不合格例和修改说明，规则才具备可训练性：
| 规则 | 不合格例 | 问题 | 合格例 |
|---|---|---|---|
| 标题含动作与对象 | 订单模块优化 | 无法判断优化什么、完成标志是什么 | 支持按订单状态筛选待发货订单 |
| 一条需求一个可验收诉求 | 支持订单筛选、导出和批量改状态 | 三个行为可分别验收，混在一条中难以排期和测试 | 拆为三条需求，各自附验收条件 |
| 描述写清触发与响应 | 系统要快一点 | 无场景、无判定标准 | 客服选择状态后，系统在3秒内返回匹配订单 |
| 术语统一 | 文中混用“工单”“任务单”“单据” | 读者无法确认是否指同一对象 | 全文统一为“工单”，首次出现处给出定义 |
规则条目建议按“规则名称、适用对象、判断条件、正例、反例、修改说明”六列组织，形成一份可逐条核对的清单。规则数量控制在十到十五条，覆盖标题、描述、验收条件、术语四类即可，过多会让评审变成逐条对照的机械检查。
角色分工与评审卡点：谁写、谁审、何时拦截
规则需要有人执行、有时点检查。角色分工按“谁对哪类信息负责”划分：需求提出者负责来源、背景与目标，说明问题从哪来、期望什么结果；需求分析者负责描述与验收条件的完整性和可验证性；评审者负责判断信息是否足以支撑决策；开发代表确认技术约束与可行性信息已记录；测试代表确认验收条件可测试。每个角色只对自己负责的字段签字，避免责任分散。
评审卡点设在三个位置。进入评审前，由需求分析者做形式检查，字段缺失或标题不合规的需求退回补充，不进入评审会议；评审中，评审者按规则清单核对表达质量，内容判断与形式判断分开记录；变更时，变更需求沿用原字段并标注变更点与影响范围，重新经过形式检查。退回条件写具体，例如“验收条件少于一条”“标题含无法判断的动词”“描述未写触发场景”，避免“写得不清楚”这类无法执行的退回理由。
| 角色 | 负责字段 | 检查时点 | 交付物 |
|---|---|---|---|
| 需求提出者 | 来源、背景与目标 | 提交前 | 背景说明与目标描述 |
| 需求分析者 | 标题、描述、验收条件 | 进入评审前 | 形式检查记录 |
| 评审者 | 整体表达质量 | 评审中 | 评审意见与结论 |
| 开发代表 | 技术约束、关联项 | 评审中及设计前 | 约束说明 |
| 测试代表 | 验收条件 | 评审中 | 可测试性确认 |
评审记录需要留存可追溯的证据：形式检查结果、评审结论、退回原因、修改前后对照。这些记录既是规范执行的凭证，也是后续修订规范的输入。需求条目与评审状态在管理工具中流转时，字段和状态可以直接承载这些证据；ONES Wiki 支持为不同角色配置读写权限，规范正文、样例库与评审记录可以按角色控制编辑范围，减少规范被随意改动的情况。
试点与修订：用真实需求验证规范
规范初稿完成后，先在一个真实项目或一个需求批次中试用，再全面发布。试点范围建议选一个迭代内的全部新增需求，数量在十到二十条之间，覆盖至少两类需求类型，确保字段和规则在真实填写中暴露问题。
试点期间按问题类型记录，便于定位修订对象：字段歧义，指同一字段不同人理解不同，例如“背景与目标”有人写问题、有人写方案；规则无法判断，指评审时对是否合格产生分歧；填写成本过高，指某字段填写耗时明显超过其支撑的判断价值。每条问题记录需求编号、涉及字段或规则、分歧描述、处理建议。
修订依据看两条：该问题是否在试点中重复出现，以及修订后是否能让判断更明确。重复出现且影响评审效率的问题优先修订；只出现一次且属于个别需求特殊性的问题，记入样例库而非改规则。每次修订记录版本号、修订日期、变更条目和原因，规范正文保留变更记录表，读者能查到某条规则何时因何调整。
发布后安排一次集中培训，用试点中的真实正反例讲解规则，比逐条宣读条文更有效。样例库持续维护：每次评审中发现典型的不合格写法，脱敏后补入反例；典型合格写法补入正例。样例库按字段和规则分类，新成员入职时先读样例再写需求。ONES Wiki 的页面模板库可以承载规范模板与样例文档，页面版本记录支持查看和回滚，样例库更新后历史版本仍可追溯。
完成检查：规范可用的判断标准
规范发布前逐项核对下表，全部通过再进入执行。检查的目的是确认规范能被使用，而非文档篇幅是否完整。
| 检查项 | 通过标准 | 检查方式 |
|---|---|---|
| 字段说明完整 | 每个必填字段都有填写要求和一个示例 | 逐字段对照字段表 |
| 规则可判断 | 每条规则配正反例，两位评审者独立判断结论一致 | 抽三条需求试判 |
| 角色与卡点明确 | 每个卡点有指定角色和退回条件 | 核对角色职责表 |
| 试点已验证 | 至少一个批次的需求按规范填写并完成评审 | 查看试点问题记录 |
| 版本维护有安排 | 明确修订发起人、记录方式和样例库维护人 | 查看变更记录表 |
| 模板可直接使用 | 空白模板含填写提示，新建需求时无需另找说明 | 实际创建一条测试需求 |
规范失效通常有可观察的信号：需求条目中必填字段长期为空或填写“待补充”；评审意见集中在表达问题而非内容判断；新成员不知道规范存在，按个人习惯编写；评审退回靠口头沟通，没有记录。出现这些信号时，先检查字段是否过多、规则是否无法判断，再决定精简字段还是补充样例，避免用增加检查次数的方式解决规范本身的问题。
规范达到可用状态的标志是：一条新需求提交后，形式检查能在几分钟内完成，评审会上讨论的是需求内容是否成立，表达问题在进入评审前已经解决。
常见问题
团队规模小，需求表达规范可以只覆盖部分需求类型吗？
可以。规范的范围按团队实际需要划定，不必一开始覆盖所有需求类型。常见做法是只纳入用户需求和系统需求，业务目标放在项目立项材料中说明；变更需求沿用原需求字段并标注变更点即可。
判断依据是团队是否真的会按这类需求做评审和交接。某类需求长期不进入评审流程，把它写进规范只会增加文档负担。范围清单里对暂不纳入的类型写明原因和后续评估时点，比直接省略更清楚。
必填字段定多了，团队填写负担重，怎么精简？
逐个字段追问它支撑哪项评审判断或哪次交接。答不上来的字段改为选填，或从字段表中删除。初次制定时必填字段控制在六到八个，运行一个迭代后统计哪些字段长期为空、哪些字段在评审中从未被引用，据此做减法。
另一种情况是字段本身有价值但填写成本高，例如技术约束。这类字段可以改为由开发代表在评审中补充，不要求需求提出者填写，把填写责任放到掌握信息的人身上。
评审时对某条需求是否合格有分歧，说明规范哪里有问题？
先定位分歧属于哪类问题。如果是对同一规则的理解不同，说明规则写得不够具体，需要补充判断条件或换用更明确的表述；如果规则本身清楚但需求处于边界情况，说明样例库缺少这类案例，应把该需求脱敏后补入正例或反例。
处理顺序是先改规则、再补样例。规则无法通过改写变得可判断时，考虑删除该条规则，避免评审变成逐条争论。分歧记录本身也是修订规范的输入，保留下来比口头讨论更有用。
规范发布后没人用，从哪些信号判断需要修订？
可观察的信号包括：必填字段长期为空或填写“待补充”；评审意见集中在表达问题而非内容判断；新成员按个人习惯编写需求；退回靠口头沟通没有记录。出现这些信号时，先检查字段是否过多、规则是否无法判断，再决定精简字段还是补充样例。
用增加检查次数的方式解决规范本身的问题，通常会让填写和评审都更慢。修订后记录版本号、变更条目和原因，让团队能查到某条规则何时因何调整。
规范正文、字段说明和样例库放在哪里比较合适？
三者分开放置、互相引用：规范正文管写法，字段说明解释每个字段写什么、写到什么程度，样例库按字段和规则分类存放正反例。规范正文与需求条目也分开，规范约束表达形式，条目承载具体内容。
承载方式上，可以使用支持模板库和版本记录的文档工具。ONES Wiki 支持使用模板库一键创建制式化文档，页面组可关联项目，需求与文档互相对应；页面版本记录支持随时查看与回滚，规范修订后能对照历史版本说明变化。规范正文、样例库与评审记录还可以按角色配置读写权限，减少规范被随意改动的情况。
