项目范围说明书模板：空白表格与填写规范

2026年11月7日

项目范围说明书模板以一张可复制的空白表为核心，覆盖项目与产品范围描述、可交付成果、验收标准、除外责任、假设与制约、范围变更入口六类字段。填写时先写清“做什么、交付什么、凭什么验收”，再补边界与前提，最后指定变更与确认责任人。本文提供空白表格、逐字段填写规范、必填与裁剪规则，以及一份完整示例。

Table of Contents

要点总览（TL;DR）

模板以一张空白表为核心，覆盖项目基本信息、范围描述与可交付成果、验收标准与除外责任、假设制约与变更入口、确认五个区域。
填写顺序是先写清做什么、交付什么、凭什么验收，再补边界与前提，最后指定变更受理人与确认人。
项目目标、项目范围描述、可交付成果清单、验收标准、除外责任、范围变更入口六项构成最小可用集，小项目可据此裁剪其余字段。
可交付成果与验收标准用编号一一对应，评审时逐对检查，交付时按编号确认。
评审确认后形成基线，后续调整通过变更入口提出，更新版本号并保留变更记录。

可复制空白模板：项目范围说明书表格

下面这张表可以直接复制到 Word、Excel 或在线文档中。表头分为五个区域，按“基本信息—范围与交付—验收与边界—前提与变更—确认”的顺序排列，填写时从上往下推进即可。表格采用“字段—填写内容—责任人/备注”的行结构，便于多人协作时各自认领字段。

区域	字段	填写内容	责任人/备注
一、项目基本信息	项目名称
	项目编号
	编制人 / 编制日期
	版本号
二、范围描述与可交付成果	项目目标
	产品范围描述（交付物具备什么特征）
	项目范围描述（要做哪些工作）
	主要可交付成果清单
三、验收标准与除外责任	验收标准（逐项对应可交付成果）
	除外责任（明确不做什么）
	验收方式与确认人
四、假设、制约与变更入口	假设条件
	制约条件
	范围变更入口（提出方式与受理人）
五、确认	发起人 / 客户确认签字
五、确认	项目经理确认签字

复制使用时，建议保留“区域”列作为分组提示，正式归档时可隐藏该列。可交付成果清单和验收标准两行如果内容较多，可以拆成独立子表，用编号一一对应，例如 D1 对应 A1。变更入口一行只写“怎么提、交给谁”，具体审批流程放在变更管理文档中，避免范围说明书承担流程手册的职责。

字段说明：每个字段写什么、写到什么颗粒度

同一份模板，不同人填写的结果差异往往来自颗粒度不统一。下面逐字段给出填写要求和常见写法，核心原则是：范围描述写到可验收，可交付成果与验收标准成对出现，边界与前提分开表达。

字段	写什么	颗粒度要求	常见写法示例
项目目标	项目要达成的业务结果	一句话，可判断是否达成	“上线客户自助开票功能，覆盖80%开票申请”
产品范围描述	最终交付物具备的特征与功能	按功能模块或特性列出，不写实现方式	“支持按订单批量开票、发票下载、红冲申请”
项目范围描述	为产出交付物需要完成的工作	写到工作包级别，能对应到责任团队	“需求调研、接口开发、联调测试、上线培训”
可交付成果清单	需要提交并验收的实物或文档	逐项编号，每项可单独验收	D1 开票功能、D2 接口文档、D3 培训材料
验收标准	每项交付成果的通过条件	与交付成果编号一一对应，写可检查的条件	A1：批量开票成功率≥99%，抽检50单无差错
除外责任	明确不在本次范围内的事项	写读者容易误以为包含的内容	“不含财务系统改造、不含历史发票迁移”
假设条件	成立才能按计划推进的前提	写“若……不成立则……”的影响	“假设财务接口在开发前提供，否则联调顺延”
制约条件	不可协商的限制	写清来源与影响范围	“受预算限制，本期只做PC端”
范围变更入口	变更如何提出、由谁受理	写渠道和受理角色，不写审批细节	“通过变更申请单提交，由项目经理初审”

范围描述与可交付成果的关系需要特别说明：范围描述回答“做哪些工作”，可交付成果回答“交出什么东西”，验收标准回答“凭什么算通过”。三者应能顺着读下来，如果某条范围描述找不到对应的交付成果，说明它可能是日常运营工作，不宜写进本项目范围。

除外责任与假设制约容易混淆。除外责任是“确定不做”的内容，用来防止范围蔓延；假设条件是“假定成立”的前提，用来暴露风险；制约条件是“不能突破”的限制，通常来自合同、预算或法规。填写时把三者分开放，评审时才能分别讨论。

必填与选填：哪些字段不能空

模板字段齐全不等于每个项目都要全部填写。必填字段决定这份说明书能否作为验收依据，选填字段用于补充管理信息。缺省处理的原则是：必填字段空缺视为说明书未完成，选填字段空缺需在评审记录中说明原因。

字段	必填/选填	理由
项目名称、编制人、版本号	必填	标识文档身份，版本号支撑后续变更追溯
项目目标	必填	判断范围是否合理的基准
项目范围描述	必填	说明书的核心内容
可交付成果清单	必填	验收的对象
验收标准	必填	没有验收标准，交付成果无法确认完成
除外责任	必填	边界不清是范围蔓延的主要来源
范围变更入口	必填	保证变更有人接、有渠道提
产品范围描述	选填	产品型项目建议填写；内部流程改进类项目可并入项目范围描述
假设条件、制约条件	选填	无明确前提时可空，但需在评审中确认确无遗漏
验收方式与确认人	选填	合同已约定验收方式时可引用合同条款
项目编号	选填	组织有编号体系时填写

小项目可以按以下规则裁剪：周期在两周以内、参与人数不超过五人的任务型项目，可将产品范围描述并入项目范围描述，假设与制约合并为一行“前提与限制”，验收标准简化为一张检查清单。裁剪后仍需保留项目目标、范围描述、可交付成果、验收标准、除外责任和变更入口六项，这六项构成范围说明书的最小可用集。

字段空缺的风险需要提前说明：验收标准空缺，交付时容易陷入“做完了但不算完成”的争议；除外责任空缺，相关方会默认所有相邻需求都在范围内；变更入口空缺，变更会以口头方式进入，导致范围与计划脱节。评审时发现空缺，应记录为待补事项并指定补填责任人，而不是直接通过。

填写示例：一份完整的范围说明书样例

以下示例为演示情景，用于说明各字段的实际写法，不对应真实项目。示例项目为某公司“客户自助开票功能”一期建设，采用瀑布方式推进，周期十周。

字段	填写内容
项目名称	客户自助开票功能一期
项目编号	PRJ-2024-031
编制人 / 日期	项目经理李某 / 2024-03-05
版本号	V1.0
项目目标	上线客户自助开票功能，使80%的开票申请由客户在线完成，减少人工开票工单
产品范围描述	支持按订单批量开票、发票下载、红冲申请三项功能，覆盖PC端客户门户
项目范围描述	需求调研与确认、开票接口开发、门户页面开发、联调测试、上线部署、客服培训
可交付成果清单	D1 开票功能（含批量开票、下载、红冲）；D2 接口文档；D3 测试报告；D4 客服操作手册与培训记录
验收标准	A1（对应D1）：批量开票成功率≥99%，抽检50笔订单无金额差错；A2（对应D2）：接口文档覆盖全部字段并通过开发方评审；A3（对应D3）：测试用例通过率100%，遗留缺陷均为低级别；A4（对应D4）：客服完成培训并通过操作考核
除外责任	不含财务系统改造；不含历史发票数据迁移；不含移动端开票；不含发票邮寄功能
验收方式与确认人	由业务部门负责人组织验收，按A1—A4逐项确认并签字
假设条件	假设财务系统接口在开发启动前提供；若延迟，联调与上线时间相应顺延
制约条件	受本期预算限制，仅覆盖PC端；上线时间受财务月结窗口限制，须在月结前一周完成
范围变更入口	通过变更申请单提交至项目经理，由项目经理初审后提交项目发起人决策
确认签字	发起人：王某；项目经理：李某

这份示例中，可交付成果与验收标准通过编号对应，评审时可以逐对检查。除外责任列出了四个容易被默认包含的事项，假设条件写明了不成立时的后果，制约条件标明了来源。变更入口只写到“谁受理、谁决策”，具体审批表单和评审会议安排放在变更管理文档中。

调整与维护：模板裁剪、评审与版本更新

模板的价值在于长期使用，而不是填完一次就归档。项目启动时完成初稿，评审确认后形成基线，执行过程中按变更记录更新版本，这三个动作决定了范围说明书能否持续作为验收依据。

按项目规模裁剪时，可以参考以下操作清单：

两周以内的任务型项目：保留六项最小字段，假设与制约合并为一行，验收标准用检查清单代替表格。
一至三个月的常规项目：使用完整模板，产品范围描述与项目范围描述分列，验收标准逐项编号。
跨部门或合同型项目：在完整模板基础上增加验收方式与确认人、合同引用条款，除外责任逐条与合同范围对照。
采用迭代方式交付的项目：范围说明书按发布批次编写，每批次一份，整体范围用产品范围描述承载。

评审与确认的动作包括：项目经理完成初稿后，组织发起人、业务负责人和技术负责人进行范围评审，重点检查范围描述与可交付成果是否对应、验收标准是否可检查、除外责任是否覆盖争议点；评审意见逐条记录并修订，修订后由发起人和项目经理签字确认，形成V1.0基线。此后任何范围调整都通过变更入口提出，批准后更新版本号并在文档中保留变更记录。

版本维护建议采用“版本号+变更摘要+日期”的记录方式，例如V1.1记录“新增红冲申请功能，验收标准增加A5”。范围说明书与范围分解、变更管理的衔接边界是：范围说明书定义“做什么、交付什么、凭什么验收”，工作分解结构把可交付成果拆成可执行的工作包，变更管理负责审批与记录变更。三者引用同一套交付成果编号，避免各文档口径不一致。

当范围说明书需要在多人之间流转评审时，文档的版本留存和权限控制会直接影响维护成本。ONES Wiki 支持使用模板库一键创建文档，成员可以在线添加注释和评论，文档实时同步并记录所有页面版本，支持随时查看与回滚，也可以为不同角色配置读写权限。将范围说明书放在这类协作空间中，评审意见、确认记录和历史版本可以留在同一页面下，项目经理更新版本时不必另行维护多份副本。具体功能以实际开通的版本与配置为准。

常见问题

项目范围说明书和需求文档有什么区别，能不能互相替代？

两者回答的问题不同。需求文档描述用户和业务需要什么，颗粒度到功能点与业务规则；范围说明书描述本次项目做哪些工作、交出哪些成果、凭什么验收，颗粒度到可交付成果与验收条件。范围说明书可以引用需求文档的编号，但需要把需求收敛成可验收的交付项。实践中常见做法是先有需求文档，再据此编写范围说明书，两者编号互相引用。

项目已经启动，范围说明书还没写，补写时要注意什么？

补写时先与发起人和业务负责人确认当前实际在做的内容，把已完成和计划中的工作整理成可交付成果清单，再倒推验收标准。对已经口头承诺但未写入的事项，逐条判断是纳入范围还是列为除外责任，并在评审中确认。补写完成的版本仍要签字确认，作为后续变更的基准，避免补写文档变成事后追认。

除外责任写多少条合适，写少了会有什么问题？

除外责任按“容易被误认为包含”的事项来写，通常列三到六条即可，重点是相邻系统改造、历史数据迁移、其他终端适配、后续运维这类边界事项。写少了，相关方会默认相邻需求都在范围内，执行中不断追加；写多了则显得推诿，评审时难以通过。判断标准是：如果某事项在启动会上被问过“这个做不做”，就值得写进除外责任。

范围说明书放在哪里维护，多人评审时怎么避免版本混乱？

建议放在团队共用的文档空间中，按项目建立页面，评审意见、确认记录和历史版本留在同一页面下。ONES Wiki 支持使用模板库一键创建文档，成员可以在线添加注释和评论，文档实时同步并记录所有页面版本，支持随时查看与回滚，也可以为不同角色配置读写权限。这样项目经理更新版本时不必另行维护多份副本。具体功能以实际开通的版本与配置为准。