项目范围说明书要把“做什么、交付什么、怎样算验收、什么不做、依据什么前提”写成一份前后自洽的文档。下面以假设的“示例项目”为背景，给出一份完整填写范例，并逐项解释填写依据、常见写法和可迁移到其他项目的规律。文中数据与时间均为演示设定，读者可对照替换为自己项目的真实口径。
要点总览（TL;DR）
- 示例以假设的“设备巡检管理系统”项目为背景，完整填写产品范围描述、主要可交付成果、验收标准、除外责任、假设与制约条件五个核心字段。
- 填写顺序建议先定产品范围与除外责任框定边界，再列可交付成果并逐条对应验收标准，最后用假设条件反查范围缺口。
- 可交付成果应写到能单独评审或签收的粒度，验收标准要指向可检查的证据，除外责任需逐条排除容易被默认包含的事项。
- 示例中的工期、预算、培训人次等均为演示设定，迁移到实际项目时应替换为自身真实口径，并补充行业合规等未覆盖内容。
- 交付范围分解、执行任务拆解与范围变更审批属于相邻主题，本文不展开；示例不构成对具体工具功能、版本或价格的确认。
这份示例要解决什么问题
很多团队知道范围说明书要写，却卡在“写到什么程度算够”。写得太粗，后续分解和验收没有依据；写得太细，又容易把任务拆解混进范围文档。这份示例的目标，是把一份填好的范围说明书完整呈现出来，让读者看到每个字段填到什么粒度、字段之间如何互相呼应。
示例采用假设情景：某制造企业要建设一套“设备巡检管理系统”，由内部信息化团队牵头，外部供应商参与部分开发。项目周期设定为16周，预算与人员数量按演示需要设定。选择这个背景，是因为它同时包含软件交付、硬件对接和流程改造，能覆盖范围说明书里较容易出问题的几类字段。示例不对应任何真实客户，也不代表任何实测效果。
读者对象是项目经理、产品负责人和参与范围评审的业务方。阅读方式建议是先看完整示例，形成整体印象，再看逐项解释，最后用可迁移规律对照自己的项目。示例展示的是范围说明书的填写方式，交付范围如何进一步分解为工作包、执行任务如何拆解到人、范围变更如何审批，属于相邻主题，本文不展开。
完整示例：一份填好的项目范围说明书
以下为示例项目范围说明书的完整填写内容，按常用字段顺序排列。各字段之间保持自洽：除外责任里排除的内容，不出现在可交付成果清单中；验收标准只针对已列出的可交付成果；假设条件支撑了工期和验收口径的成立。
一、项目与产品范围描述
项目名称：设备巡检管理系统建设项目（示例）。项目目标：在16周内建成一套覆盖三个厂区、约600台设备的巡检管理系统，替代现行纸质巡检记录方式，使巡检计划下发、执行记录和异常上报在系统内完成。产品范围描述：系统包含巡检计划管理、移动端巡检执行、异常上报与闭环、巡检记录查询与统计四个功能域，并与现有设备台账系统通过接口同步设备基础信息。产品范围描述界定的是最终交付物的功能边界，项目目标界定的是这次建设要达成的业务结果，两者分开写，避免把目标当成功能清单。
二、主要可交付成果
- 需求规格说明书一份，含四个功能域的用例说明和接口约定，通过业务方与供应商联合评审。
- 系统设计文档一份，含数据库设计、接口设计和移动端适配方案。
- 可运行的巡检管理系统一套，部署在测试环境与生产环境各一套。
- 与设备台账系统的数据同步接口一个，完成联调并留存联调记录。
- 移动端巡检应用一个，支持安卓主流版本，覆盖计划接收、扫码巡检、拍照上传、异常提交四类操作。
- 用户操作手册一份与两轮共60人次的用户培训。
- 上线切换方案与试运行报告各一份，试运行期设定为两周。
三、验收标准与质量要求
| 可交付成果 | 验收标准 |
|---|---|
| 需求规格说明书 | 四个功能域用例齐全，评审意见全部关闭并留有记录 |
| 巡检管理系统 | 四个功能域的功能用例执行通过率达到约定比例；关键操作响应时间在演示环境下不超过设定阈值 |
| 数据同步接口 | 设备基础信息同步准确，联调记录完整，异常场景有处理说明 |
| 移动端应用 | 四类核心操作在指定安卓版本上可完成，拍照上传成功并可在系统内查看 |
| 培训与手册 | 培训按计划完成，参训人员签到记录齐全，手册内容与系统实际功能一致 |
| 试运行 | 试运行期内巡检记录在系统内完整留存，异常上报形成闭环记录 |
质量要求补充：系统需满足企业既有的信息安全规范，账号权限按厂区与角色划分；所有交付文档使用统一模板并纳入版本管理。
四、除外责任
- 不包含设备硬件的采购、安装与维修，设备侧传感器数据接入不在本次范围。
- 不包含与除设备台账系统之外的其他业务系统集成。
- 不包含巡检制度的重新设计与业务流程再造，系统按现行制度配置。
- 不包含上线后超过三个月的问题修复与运维服务，该部分另行约定。
- 不包含历史纸质巡检记录的批量电子化录入。
五、假设条件与制约条件
假设条件：设备台账系统在项目期内提供可用的接口文档与测试环境；三个厂区的移动网络覆盖满足移动端使用要求；业务方能在约定时间内完成需求确认与验收评审；供应商开发人员按约定投入。制约条件：项目总工期16周不可顺延；预算总额固定；系统须部署在企业既有服务器环境内；上线时间需避开生产高峰期，只能安排在设定的窗口期。
逐项解释：每处为什么这样填
示例只是结果，真正需要理解的是每个字段背后的判断。下面按字段说明填写依据、常见写法和容易出错的地方。
产品范围与项目目标为什么要分开写
项目目标回答“这次建设要达成什么业务结果”，产品范围描述回答“交付的系统包含哪些功能”。示例中目标写成“替代纸质记录、覆盖三个厂区”，产品范围写成四个功能域加一个接口，两者层级不同。常见错误是把目标写成功能清单，或者把功能描述写成“提升巡检效率”这类无法验收的表述。判断方法很简单：目标句子里出现的是业务结果，范围句子里出现的是可交付的产品构成。
可交付成果写到什么粒度才算可验收
可交付成果应当是能够被单独检查、评审或签收的产物。示例中“需求规格说明书”“数据同步接口”“移动端应用”都满足这一点，而“完成需求调研”“推进接口开发”属于活动，不是可交付成果。常见错误是把阶段任务当成成果，导致验收时找不到对应物。一个实用的检验方式是：每个可交付成果后面能否直接挂上一条验收标准，挂不上就说明粒度或表述有问题。
验收标准怎样写成可测量的表述
验收标准要能被第三方按同一口径判断通过与否。示例中采用“用例齐全、评审意见关闭并留有记录”“联调记录完整”“签到记录齐全”等表述，指向可检查的证据。常见错误是写“系统运行稳定”“用户满意”，这类表述无法判定。涉及性能指标时，应同时写明测试环境和测量方式，否则数字本身没有意义。示例中的响应时间阈值属于演示设定，实际项目应结合自身环境确定。
除外责任为什么必须显式写出
范围争议多数发生在“以为包含、其实没约定”的地带。示例把硬件采购、其他系统集成、制度再造、运维服务、历史数据录入逐条排除，每一条都对应一个容易被默认包含的事项。常见错误是只写“不包含其他内容”这类笼统表述，等于没有排除。写法上，除外责任应与可交付成果清单对照检查：清单里没有的、又容易被相关方误认为包含的，就应当写进除外责任。
假设与制约条件从哪里来
假设条件是“目前不成立但假定会成立”的前提，制约条件是“已经确定、不能改变”的限制。示例中接口文档可用、网络覆盖满足要求属于假设；工期、预算、部署环境、上线窗口属于制约。来源通常是立项材料、合同条款、环境评估和相关方访谈。常见错误是把制约条件写成假设条件，或者只写一条“按计划推进”。假设条件一旦不成立，应触发范围或计划的重新评估，这一点在填写时就应让相关方知晓。
可迁移规律：换一个项目怎么填
示例的价值在于规律，而不在于文字本身。换一个项目时，可以按下面的顺序和规则填写，减少返工。
- 先定边界，再列成果。先写产品范围描述和除外责任，把“做什么”和“不做什么”同时框定，再列可交付成果。顺序反过来，成果清单容易越列越多。
- 一条成果对一条验收标准。可交付成果清单确定后，逐条补验收标准，出现挂不上标准的成果，要么补标准，要么把它降为活动。
- 除外责任与假设条件联动检查。每条假设条件都问一句：如果不成立，哪些内容会落到范围之外或需要追加？答案应体现在除外责任或风险说明中。
- 用目标反查范围。写完产品范围后回看项目目标，确认每个功能域都服务于目标，目标中提到的业务结果都有对应交付物支撑。
- 为后续分解留接口。可交付成果的粒度应能直接作为范围分解的输入，分解成工作包时不需要重新定义成果边界。
不同规模的项目，字段可以增减，但结构不宜省略。小型项目可以把多个可交付成果合并描述，验收标准写得更简短；跨组织项目则应把假设条件、除外责任写得更细，因为相关方越多，默认假设越容易分歧。填写完成后，建议组织一次范围评审，让业务方、开发方和验收方在同一份文档上确认，评审意见关闭后再进入分解阶段。
范围说明书作为项目文档，需要被评审、留痕并在后续阶段被反复引用。ONES 支持在项目下管理需求范围、研发任务等内容，项目计划可按目标、交付物或项目阶段等维度建立工作分解结构，并支持设置计划与里程碑基线、对比版本细节追溯变更。将评审通过的范围说明书与对应的工作分解结构放在同一项目空间中管理，可以让文档确认结果和后续计划保持对应关系。这些能力适用于采用瀑布方式管理的项目场景，具体使用方式应结合团队现有的文档与计划管理习惯确定。
适用边界：示例不能直接照搬的地方
这份示例是演示情景，直接照搬会带来两类问题：一是示例中的假设条件与读者项目不符，二是示例未覆盖的结构在特定项目中必须补充。
先看假设条件。示例假定设备台账系统能提供接口文档和测试环境、三个厂区网络覆盖满足要求、业务方能按时完成确认。如果实际项目中接口方配合程度不确定，就应把接口可用性从假设条件提升为风险项，并在除外责任中明确接口不可用时的处理方式。如果项目涉及多个外部供应商，还应补充供应商之间的交付界面约定。示例中的16周工期、两周试运行、60人次培训都是演示设定，迁移时应替换为自身项目的真实口径，不能把示例数字当作参考基准。
再看结构补充。示例覆盖的是范围说明书的核心字段，适用于交付物边界相对清晰的项目。对于探索性强、需求在过程中逐步明确的项目，产品范围描述可能需要改为分阶段描述，并在每个阶段结束时重新确认范围。对于受监管行业，验收标准还需对齐行业规范与合规要求，这部分内容示例未涉及，需要读者自行补充。
最后划清主题边界。本文展示的是范围说明书的填写方式；交付范围如何进一步分解为工作包、执行任务如何拆解并分配到团队、范围变更如何提出与批准，分别属于范围分解、任务拆解和变更管理主题，本文不展开。示例中提到的工具能力仅用于说明文档与计划的对应管理，不构成对任何具体工具功能、版本或价格的确认，读者选型时应以实际产品资料为准。
常见问题
项目范围说明书和需求规格说明书有什么区别，示例里为什么两者都出现了？
范围说明书界定项目要交付什么、验收边界在哪里、哪些内容不做，需求规格说明书则详细描述每个功能的具体行为。示例中把需求规格说明书列为一项可交付成果，是因为它是在范围边界确定之后才产出的详细文档。实际项目中，范围说明书先定边界，需求规格说明书再在边界内展开细节，两者层级不同，不宜互相替代。
如果项目采用敏捷方式、需求在过程中逐步明确，这份示例还能用吗？
可以使用，但需要调整产品范围描述的写法。示例采用一次性描述完整功能域的方式，适合边界相对清晰的项目。敏捷项目中，产品范围描述可以改为分阶段描述，每个阶段结束时重新确认下一阶段的范围，并把除外责任和假设条件随阶段更新。可交付成果和验收标准的写法仍然适用，只是颗粒度可以按迭代或增量来组织。
除外责任写多少条合适，写少了会有什么后果？
除外责任没有固定条数，判断标准是：清单里没有的、又容易被相关方误认为包含的事项，就应当写进去。写少了，范围争议往往在验收阶段才暴露，届时追加工作会直接影响工期和成本。示例中逐条排除硬件采购、其他系统集成、制度再造、运维服务和历史数据录入，每一条都对应一个常见的默认假设。填写时可以对照可交付成果清单逐项反问“相关方会不会以为这个也包含”，答案如果是“可能会”，就补一条除外责任。
假设条件不成立时应该怎么处理，范围说明书需要重写吗？
假设条件不成立时，应触发范围或计划的重新评估，而不是简单地在文档里改一句话。具体做法是：先判断该假设影响哪些可交付成果和验收标准，再评估是否需要调整范围、工期或资源，最后按变更管理流程确认。范围说明书本身需要更新版本并留痕，让相关方看到变化依据。示例中接口文档可用、网络覆盖满足要求等假设，一旦不成立，就应把对应内容从假设条件提升为风险项，并在除外责任中明确处理方式。
范围说明书评审通过后，后续工作分解和任务拆解应该怎么衔接？
评审通过的范围说明书是后续分解的输入。可交付成果清单应当能直接作为工作分解的起点，分解成工作包时不需要重新定义成果边界。示例中每条可交付成果都挂了验收标准，分解时可以按成果逐项展开，避免遗漏。任务拆解到人、排期和资源分配属于执行层面的工作，与范围说明书保持对应关系即可，不必把任务清单写进范围文档。ONES 支持在项目下管理需求范围与研发任务，项目计划可按目标、交付物或项目阶段等维度建立工作分解结构，并支持设置计划与里程碑基线、对比版本细节追溯变更，适合将评审通过的范围说明书与后续计划放在同一项目空间中对应管理。
