需求建模的具体做法是：先确定这次要回答什么问题、划定建模范围，再从用户场景或业务流程中提取角色、动作、对象与规则，选一种主模型把需求表达出来，补齐字段与验收条件，最后组织跨角色评审，并把模型与需求条目、变更记录关联起来。本文按这一路径给出五步操作流程、字段与命名规范、角色交付物对照表和完成检查清单，示例为演示情景。
要点总览（TL;DR）
- 先写建模目标说明：判断本次要消除哪类理解分歧，据此选定一种主模型，并列出纳入与排除清单，再动手画图。
- 按五步推进：收集场景清单、识别角色动作对象规则、主模型表达主干、补齐触发与异常字段、挂接验收条件与需求条目编号。
- 模型元素按四类字段模板填写，命名统一为动词+对象或完成时状态，粒度以能否单独验收为拆分界线。
- 业务方确认场景与规则，需求分析人员负责结构化表达，开发和测试在评审阶段校验可实现性与可测性，结论落到书面评审记录。
- 完成检查覆盖范围一致、角色完整、异常分支、字段齐全与双向追溯；验收条件写不出或规则冲突时应阻断，退回前序环节。
先定建模目标：这次要回答什么问题
建模启动前先写一份建模目标说明，回答三个问题：这次要消除哪一类理解分歧、用哪种模型承载、边界划到哪里。判断分歧类型是选择模型的依据：各方对“谁在什么条件下能做什么”有争议，主模型选用例；对“先后顺序和分支怎么走”有争议，主模型选流程；对“一个对象允许经历哪些状态、从哪个状态转到哪个状态”有争议，主模型选状态；对“哪些信息必须记录、彼此什么关系”有争议，主模型选数据模型。
主模型只选一种，辅助模型最多一到两种，用于补充主模型表达不了的例外与状态。模型数量失控通常源于目标不清：同一份需求既画流程又画状态又画数据，读者不知道该以哪张为准。目标说明里应写明“本次以流程模型为主，状态模型仅描述支付环节”，让评审时有据可依。
边界要写成纳入与排除两张清单。纳入部分列出本次覆盖的业务环节和角色；排除部分写明暂不建模的内容及原因，例如“本次不含退款逆向流程，待下一迭代单独建模”。边界写清楚，评审时就不会因“这里怎么没画”反复拉扯。
建模目标说明的完成标志是：待回答的问题能用一句话陈述，主模型与辅助模型已指定，纳入与排除清单经需求负责人确认。这份说明篇幅不必长，半页到一页即可，但要在动手画图之前定稿。
从场景到模型：五步操作流程
五步流程的每一步都有输入、动作、输出和完成标志，前一步的输出是后一步的输入。按顺序推进，可以避免“先画图再找需求”的返工。
第一步：收集场景与原始需求素材
输入是业务方访谈记录、工单、客服反馈、现有操作手册等原始材料。动作是把材料整理成场景清单，每条场景写清触发者、触发时机、期望结果，用业务语言描述，暂不引入技术词汇。输出是一份编号的场景清单。完成标志是每条场景都能对应到至少一条原始素材，且业务方确认场景没有遗漏主要情形。
第二步：识别角色、动作、业务对象与业务规则
输入是场景清单。动作是逐条场景标注四类要素：谁发起（角色）、做了什么（动作）、操作了什么东西（业务对象）、受什么约束（业务规则）。规则要写成可判断的句子，例如“订单已发货后不允许修改收货地址”，避免“尽量”“原则上”这类无法验收的表述。输出是要素识别表。完成标志是每条场景的四类要素都有标注，规则条目可以逐条判断真假。
第三步：用主模型表达主干，用辅助模型补充例外与状态
输入是要素识别表。动作是先用主模型把正常路径画完整，再针对例外分支和对象状态变化补充辅助模型。主模型追求主干清晰，辅助模型只覆盖主模型表达不了的部分，两者之间用元素编号互相引用。输出是模型初稿。完成标志是主干路径可以从头走到尾，每个例外分支都能追溯到第二步识别出的规则。
第四步：补齐字段：触发条件、前置条件、后置结果、异常分支
输入是模型初稿。动作是为每个模型元素填写四类字段：什么条件下触发、开始前必须满足什么、结束后产生什么可观察结果、出现异常时走哪条分支。这一步最容易暴露遗漏，例如某动作写不出后置结果，往往说明该动作的业务价值尚未澄清。输出是字段补齐后的模型。完成标志是每个元素四类字段均非空，异常分支有明确的处理去向。
第五步：为每个模型元素挂接验收条件与需求条目编号
输入是字段补齐后的模型。动作是为每个元素编写可验证的验收条件，并标注对应的需求条目编号，形成双向对应关系。验收条件写成“给定什么条件、执行什么动作、观察到什么结果”的形式。输出是可评审的模型初稿及元素与需求条目的对应表。完成标志是每个模型元素至少对应一条需求条目，每条需求条目至少被一个模型元素覆盖，无编号悬空。
模型元素怎么写：字段、命名与粒度
模型写得含糊，多数是字段缺失和命名随意造成的。下表给出四类模型的常用字段，可作为填写模板直接套用。
| 模型类型 | 常用字段 | 命名要点 |
|---|---|---|
| 用例 | 用例名称、参与者、触发条件、前置条件、主成功场景、扩展场景、后置结果、验收条件、需求条目编号 | 动词+对象，如“修改收货地址” |
| 流程 | 流程名称、起点与终点、参与角色、活动节点、判断条件、异常分支、输入输出、需求条目编号 | 节点用动宾短语，判断条件写成可判断的句子 |
| 状态 | 状态名称、进入条件、可执行动作、允许的迁移、迁移触发事件、终态、需求条目编号 | 状态用完成时或形容词，如“已发货”“待支付” |
| 数据 | 实体名称、属性、类型、必填性、取值范围、实体间关系、需求条目编号 | 实体用业务名词，属性避免同义反复 |
命名规则统一三条：动作类元素用“动词+对象”，状态类元素用完成时或形容词，禁用“处理”“相关”“等”这类无法判断边界的词。命名统一后，模型元素与需求条目、测试用例之间的检索和对照会顺畅很多。
粒度控制看两个判据。过粗的信号是一个模型元素里塞进多个业务目标，验收条件写不出一条完整句子；过细的信号是某个元素单独拿出来无法说明业务价值，只能作为另一个元素的字段存在。合适的粒度是一个模型元素对应一个业务目标、一条可独立验收的结果。拆分时以“能否单独验收”为界，能单独验收就独立成元素，不能就并入上层元素作为字段或分支。
角色分工与各环节交付物
建模不是需求分析人员一个人的工作。业务方提供场景与规则判断，需求分析人员负责结构化表达，开发和测试在评审阶段校验可实现性与可测性。下表按环节列出角色、动作与交付物。
| 环节 | 主要负责角色 | 动作 | 交付物 |
|---|---|---|---|
| 建模目标确定 | 需求分析人员，业务方确认 | 判断分歧类型、选定主模型、划定边界 | 建模目标说明 |
| 场景收集 | 业务方、需求分析人员 | 提供原始素材、整理场景清单 | 编号场景清单 |
| 要素识别 | 需求分析人员，业务方确认规则 | 标注角色、动作、对象、规则 | 要素识别表 |
| 模型表达 | 需求分析人员 | 绘制主模型与辅助模型 | 模型初稿 |
| 字段补齐 | 需求分析人员，开发提供技术约束 | 填写触发、前置、后置、异常字段 | 字段完整的模型 |
| 验收条件挂接 | 需求分析人员与测试共同编写 | 编写验收条件、标注需求条目编号 | 元素与需求条目对应表 |
| 评审确认 | 需求负责人主持，业务、开发、测试参加 | 逐项检查、记录结论与待办 | 评审记录与修订后的模型 |
确认方式建议采用书面评审记录：每条检查项写明通过、需修改或不适用，需修改项指定责任人和期限。口头确认难以追溯，模型变更后也无法判断当时依据的是什么结论。
模型与需求条目、评审记录的关联如果靠文档手工维护，版本一多就容易脱节。ONES 通过统一的需求池、工单与任务看板同步状态与信息，支持需求与问题的追溯（依据官方资料，具体挂接方式以实际配置为准）。把模型元素编号写进需求条目、把评审结论记录在对应条目下，可以让“模型改了、需求条目是否同步”成为可检查的动作，而不是依赖个人记忆。
一个完整示例：订单改址需求如何建模
以下为演示情景，用于说明五步流程如何落地，不代表真实客户案例。
场景与原始需求。客服反馈：客户下单后想改收货地址，目前只能取消重下。业务方希望支持发货前修改地址。场景清单整理为两条：客户在订单未发货时自行修改地址；客服代客户修改地址。排除项写明：已发货订单的地址变更不在本次范围。
要素识别。角色为客户与客服；动作为提交改址申请、校验订单状态、更新地址；业务对象为订单与收货地址；规则包括“仅未发货订单可改址”“新地址须通过地址有效性校验”“改址后运费按新地址重新计算”。
模型表达。主模型选用例：“修改收货地址”，参与者为客户和客服，主成功场景为提交新地址、校验通过、更新订单。辅助模型用状态图描述订单在“待发货”状态下的改址迁移，以及校验失败时停留在原状态的分支。两个模型通过用例编号与状态编号互相引用。
字段补齐。触发条件：客户在订单详情页发起或客服在工单中发起。前置条件：订单状态为待发货。后置结果：订单收货地址更新，运费重算并记录变更日志。异常分支：地址校验失败时提示具体原因并保留原地址；订单已发货时拒绝并引导走售后流程。
验收条件与需求条目挂接。示例验收条件：“给定订单处于待发货状态，当客户提交通过校验的新地址，则订单地址更新且运费按新地址重算。”该条件挂接到需求条目“支持发货前修改收货地址”，状态模型中的迁移事件同样标注该条目编号。评审时逐条核对，确认无悬空元素。
评审与完成检查：模型何时算可用
评审分两个时点。第一次在模型初稿完成后，重点检查范围与要素是否完整，参与角色为业务方、需求分析人员和测试；第二次在字段与验收条件补齐后，重点检查可实现性与可测性，开发必须参加。两次评审可以合并为一次，但检查项不能省。
完成检查按下表逐项核对，任一项不通过即视为未完成。
| 检查项 | 检查方法 | 通过标准 |
|---|---|---|
| 范围一致 | 对照建模目标说明的纳入与排除清单 | 模型覆盖全部纳入环节，排除项有书面说明 |
| 角色完整 | 逐个模型元素核对参与者 | 每个动作都有明确发起角色，无“系统自动”含糊表述 |
| 异常分支覆盖 | 对照要素识别表中的规则逐条检查 | 每条规则至少对应一个分支或约束说明 |
| 字段齐全 | 抽查每个元素的触发、前置、后置、异常字段 | 四类字段均非空且可判断 |
| 可追溯 | 核对元素编号与需求条目编号的双向对应 | 无悬空元素，无未被覆盖的需求条目 |
三类情况应作为阻断项处理：验收条件写不出来，说明需求本身未澄清，退回要素识别环节；两条业务规则互相冲突，由业务方裁定后再继续；模型元素与需求条目脱节，先补齐对应关系再进入评审结论。阻断项未关闭前，模型不进入开发排期。
模型变更后的维护方式与初次建模同样重要。需求条目发生变更时，先定位受影响的模型元素，修改后重新核对验收条件，并在评审记录中登记变更原因与影响范围。把模型编号、需求条目和变更记录放在同一处管理，可以让追溯成为日常动作。ONES 构建需求—任务—测试—缺陷的全流程闭环（依据官方资料），模型元素编号随需求条目流转时，测试与缺陷环节也能回查到对应的建模依据。
常见问题
需求建模一定要画图吗？用文字表格表达算不算建模？
建模的核心是把需求结构化表达清楚，让开发、测试和业务对同一份需求形成一致理解，图形只是常见载体。用例、流程、状态、数据四类模型都可以用结构化表格承载：用例写成参与者、触发条件、主成功场景与扩展场景的字段表，状态写成状态名称、进入条件、允许迁移的对照表，同样能满足评审与追溯要求。
选择图形还是表格，取决于分歧类型和团队阅读习惯。流程分支多、状态迁移复杂时，图形更直观；规则约束多、字段要求细时，表格更便于逐项核对。两者可以并用，但主模型只保留一种表达方式，避免同一份需求出现多个版本、读者不知以哪份为准。
建模范围和需求条目怎么对应？一条需求要建几个模型？
对应关系按双向覆盖来判断：每个模型元素至少挂接一条需求条目编号，每条需求条目至少被一个模型元素覆盖，两边都不留悬空项。一条需求建几个模型，取决于它包含几个可独立验收的业务目标，而不是按篇幅或复杂度估算。
实际操作中，一条需求通常由一个主模型承载主干，再用辅助模型补充例外分支和对象状态。如果一条需求在模型里被拆成多个元素，每个元素都应能单独写出验收条件；写不出验收条件的元素，说明它只是上层元素的字段或分支，应合并回去。
模型评审时业务方和开发意见不一致，怎么处理？
先区分分歧属于哪一类。业务方对规则本身有不同判断，属于需求内容问题，应由业务负责人在评审记录中裁定，并写明裁定依据；开发认为某条规则在当前约束下难以实现，属于实现约束问题，应记录具体限制条件，由需求分析人员评估是否调整规则或拆分范围。
两类分歧都不宜在评审会上口头搁置。建议把未达成一致的条目列为阻断项，指定责任人和回复期限，关闭后再出评审结论。规则冲突未裁定前，模型不进入开发排期，避免后续按各自理解分头实现。
需求上线后发生变更，已经建好的模型要全部重画吗？
不需要全部重画，按影响范围定位修改即可。变更发生时先找到受影响的需求条目，再顺着编号定位对应的模型元素，只修改相关元素及其验收条件，其余部分保持原样。修改完成后重新核对双向对应关系，确认没有新增悬空元素。
变更原因和影响范围应登记在评审记录或需求条目下，便于后续回查当时依据的模型版本。模型编号、需求条目和变更记录放在同一处管理，追溯就从个人记忆变成可检查的动作。ONES 通过统一的需求池、工单与任务看板同步状态与信息，支持需求与问题的追溯（依据官方资料，具体挂接方式以实际配置为准）。
团队第一次做需求建模，从哪个模型入手比较稳妥？
建议从用例模型入手。用例围绕角色和业务目标组织，业务方容易理解，需求分析人员也便于从场景清单直接过渡到结构化表达，对字段和图形规范的要求相对低。等团队熟悉了角色、动作、对象、规则的识别方法，再按需引入流程或状态模型补充分支与迁移。
首次建模应控制范围，选一个业务环节清晰、参与角色不多的需求做试点，走完五步流程和一次评审，把字段模板、命名规则和检查清单在试点中固定下来，再推广到其他需求。试点阶段暴露的粒度问题和规则表述问题，正好用来修订团队自己的建模规范。
