软件项目范围说明书模板：五章骨架、三张表与评审闸口

简介：《软件项目范围说明书》是一份面向软件项目经理、需求分析人员与开发团队的项目范围定义文档，用于在立项和需求阶段明确软件意图、应用目标、作用范围、用户特点及约束条件。文件包仅含1个doc文档，约46KB，便于直接查阅、修改并纳入项目文档体系。内容按引言、任务概述、需求规定、运行环境规定和数据要求展开，覆盖编写目的、背景说明、术语与参考资料、功能与性能指标、输入输出要求、数据管理及故障处理，并列出设备、支持软件、接口与控制等运行环境要素。读者可据此梳理系统边界、识别与外部系统的联系，形成可评审的范围基线，减少需求蔓延与沟通偏差。目前已有1642人学习。

1. 验收前两周翻出这份范围说明书，性能一栏只有一句「响应时间要快」

项目验收前两周，我把半年前定稿的那份软件项目范围说明书重新调出来，翻到需求规定那一节，性能条目底下只留了一句话：响应时间要快。开发和测试围着这七个字争了四十分钟，最后靠翻聊天记录才勉强对上一个口径。这类文档真正的价值从来不在篇幅，而在能不能提前把「做到什么程度算完」这件事固定下来。手里这份 .doc 模板按引言、任务概述、需求规定、运行环境规定、数据要求五章铺开，基本覆盖了立项到验收需要交代的全部口径，适合刚接手项目、需要一份能直接往里面填的骨架的人：项目经理、需求接口人、测试负责人，以及第一次独立带完整项目的开发者。它是一张要反复翻回来的检查表，并非写完就归档的交付物。

2. 五章骨架逐节拆：从编写目的到数据采集，每一节对应什么验收物

模板给的是五章三十来个小节的空架子，空架子本身不值钱，值钱的是每一节背后到底该产出什么。这一章按原文顺序把五个章逐节过一遍，说清每节的填写对象、填写边界，以及写得含糊时会在哪个环节出问题。读完这一章，应该能对着模板判断：这一节我手上有没有料，没有的话要找谁要。

2.1 引言四件套：编写目的、背景、定义、参考资料

编写目的这一节最容易写成套话，常见写法是「本文档用于指导本项目开发」。这种句子对任何项目都成立，等于没写。合格的写法是把读者和读者要做的决策绑在一起：本文档面向开发组、测试组和甲方接口人，用于确认一期交付的功能边界、性能口径与验收判据，作为后续设计说明书和测试用例的输入源。这么写的好处是后面所有争议都能回到「这份文档当初就是给谁做决策用的」这个原点。

背景说明要落三样东西：待开发系统的正式名称、任务提出者/开发者/用户三方的对应关系、以及本系统与其他系统或机构之间的基本往来。第三样最容易被跳过，但它恰恰是后面接口章节的伏笔。如果待开发的产品是某个更大系统的一个组成部分，模板明确要求说明本产品与系统中其他组成部分的关系，并且允许用一张方框图来表达系统组成与接口位置。我的做法是：画一张不超过十个方块的关系图，每个方块标清是自研、外采还是既有系统，方块之间的连线标上交互内容的方向。这张图后面会被接口章节和数据要求章节反复引用，先画出来能省掉大量重复描述。

定义这一节列术语的定义和外文首字母缩写的原词组。别小看它，同一份文档里「用户」「账号」「订单」这类词在不同章节漂移含义，是评审阶段最常见的返工原因。我一般会维护一张两列的术语表，左列是本文档中的正式叫法，右列是「不要写成」的同义词黑名单，写进文档前先对一遍。参考资料则要列全：经核准的计划任务书或合同、上级批文、属于本项目的其他已发表文件、本文件中引用的文件和标准，每一项给出标题、文件编号、发表日期、出版单位和获取来源。少一个编号，后面追溯需求来源时就得重新找人要。

2.2 任务概述：目标、用户特点、假定与约束的量化写法

目标这一节要回答四个问题：为什么做这个软件、应用目标是什么、作用范围到哪里为止、背景材料有哪些。模板还专门提示，如果产品是独立自含的软件要说明这一点，如果是更大系统的一部分则要说明与其他组成部分的关系。这句话的实际含义是：先把「不做什么」写清楚。范围说明书的另一半价值就在排除项上，把不在一期范围内的功能、不支持的终端类型、不覆盖的地区明确列出来，比多写十条功能更有用。

用户特点这一节经常被当成客套话，写一句「用户为普通办公人员」就过去了。但模板明确说这是软件设计工作的重要约束，理由是操作人员和维护人员的教育水平、技术专长、预期使用频度，直接决定了界面复杂度、错误容忍度和帮助文档的深度。举个具体的：如果一线操作员是三班倒的车间人员，每班只上手二十分钟，那就不该设计需要记忆快捷键或理解状态机的交互；如果维护人员是甲方自己的 IT 团队，那么日志格式、配置项命名和部署脚本的规范程度就得按他们能接手维护的标准来写。这一节写扎实了，后面性能和易用性要求才有落脚点。

假定和约束是整份文档里最硬的一节，也是我在评审时最先看的一节。经费限制、开发期限只是模板给的例子，真正要写进去的是那些一旦变化就会让整个方案推倒重来的前提。我一般分三类写：时间约束（上线窗口、依赖的外部系统档期、审查周期）、资源约束（团队人数上限、可用的测试环境规格、外采组件的采购周期）、以及技术与合规约束（必须复用的既有组件、必须遵循的行业标准、数据保留年限）。这三类都要求写成可核对的数字或日期，不写「尽快」「尽量」这种量词。

表格对比一下两种写法的差别，评审时一眼能看出哪种会被打回：

2.3 需求规定六项：功能到专门要求的组织顺序

需求规定这一章是全文最厚的部分，模板把它拆成六节：功能、性能、输入输出、数据管理能力、故障处理、其它专门要求。我建议的填写顺序和模板给出的顺序不完全一致，实际操作里先写输入输出要求，再回头写功能，因为 IPO 表的三列正好对应输入、处理、输出，先把输入输出的数据类型和格式定下来，功能条目里的处理规则才不会悬空。

功能规定的写法，模板点名要求用列表方式，例如 IPO 表即输入、处理、输出表的形式，逐项定量和定性地叙述，说明输入什么量、经怎样的处理、得到什么输出，并说明软件应支持的终端数和应支持的并行操作用户数。注意最后半句：终端数和并发用户数是功能条目的组成部分，不是性能条目的专属。很多文档把它们塞进性能章，结果容量规划时找不到依据。

性能规定分三小块。精度要写输入、输出数据的精度要求，可能还包括传输过程中的精度，写法上是绝对误差或相对误差，再加上计量单位。时间特性要求模板列了四类：响应时间、更新处理时间、数据的转换和传送时间、解题时间。这四类不能混着写一句话，各自的测量条件和数据量差别很大。灵活性要求则列了五种变化场景：操作方式上的变化、运行环境的变化、同其他软件的接口的变化、精度和有效时限的变化、计划的变化或改进，并且明确要求为了提供这些灵活性而进行的专门设计部分应该加以标明。这一条常被忽略，但它决定后续架构评审时能不能解释清楚「这里为什么多了一层适配」。

输入输出要求要把数据类型、媒体、格式、数值范围、精度逐项说清，对输出还要说明必须标明的控制输出量，并举例说明硬拷贝报告（正常结果输出、状态输出、异常输出）以及图形或显示报告的描述。数据管理能力要求说清需要管理的文卷和记录个数、表和文卷的规模，并按可预见的增长对数据及其分量的存储要求作出估算。故障处理要求列可能的软件、硬件故障，以及各类故障对各项性能产生的后果和处理要求。其它专门要求覆盖安全保密、使用方便、可维护性、可补充性、易读性、可靠性、运行环境可转换性这些甲方特别在意的点。

2.4 运行环境与数据要求：设备清单、接口协议与数据元分组

运行环境规定这一章看着像填表，实际上是最容易埋隐患的地方。设备一节要列处理器型号及内存容量、外存容量与联机或脱机状态、媒体及存储格式、设备的型号及数量、输入输出设备的型号和数量、数据通信设备的型号和数量、功能键及其他专用硬件。注意它要求写型号而不是写规格档位，原因很实际：当甲方现场只有某个型号的终端设备时，软件的适配范围就被这个型号锁死了。支持软件一节列操作系统、编译或汇编程序、测试支持软件，同样要带版本口径。

接口一节说明软件同其他软件之间的接口、数据通信协议。这一节的填写标准是「对方文档里能对上」：接口的字段名、协议版本、交互频率、失败重试策略，都要和对方系统的说明书保持同一套叫法。控制一节说明控制该软件运行的方法和控制信号，并要说明这些控制信号的来源，比如是来自调度系统、来自运维手工触发，还是来自上游系统的状态位。

数据要求是整份文档的技术底稿。数据的逻辑描述要把数据分成动态数据和静态数据：静态数据是运行过程中主要作为参考、很长时间内不会变化的数据；动态数据包括所有在运行中要发生变化的数据，以及在运行中输入输出的数据。分组上模板给了五类：静态数据、动态输入数据、动态输出数据、内部生成数据、数据约定。数据约定这一项特别要盯住，它要求逐条列出对进一步扩充或使用方面的限制，包括容量、文卷、记录和数据元个数的最大值，并且强调在设计和开发中确定是临界性的限制更要明确指出。临界限制就是那些「再大一点系统就撑不住」的阈值，写进文档等于给未来的容量规划留了后悔药。

数据采集一节是很多团队直接跳过的地方，但它决定了上线后数据从哪来。模板要求的范围包括：输入数据的来源（单个操作员、数据输入站、专业的数据输入公司或它们的一个分组）、数据输入所用的媒体和硬件设备、接受者、输出数据的形式和设备、每一个数据元的合法值范围、量纲（度量单位、增量步长、零点定标）、更新和处理的频度。如果数据输入是随机的，要给出更新处理频度的平均值或其他度量方式。另外还要写清输入的承担者是用户还是开发者、预处理过程的格式与通信媒体要求，以及需要模拟转换或数字转换时的方法和转换因子。最后一小节要求说明这些数据要求对设备、软件、用户、开发单位可能产生的影响，比如是否要求用户单位增设某个机构。这一句往往是项目立项时说服甲方追加资源的唯一书面依据。

3. 三张表把范围说明书固定住：IPO 表、性能指标表、数据元字典

五章骨架解决的是「有没有写到」，三张表解决的是「写得能不能验」。这一章把模板里最费笔墨的三处落成可直接抄的表结构：功能规定对应的 IPO 表、性能规定对应的指标表、数据要求对应的数据元字典。三张表填完，文档基本就具备被测试用例反向引用的条件了。

3.1 IPO 表：输入、处理、输出三列怎么写才扛得住评审

IPO 表看起来简单，翻车点全在「处理」这一列。常见写法是「对输入数据进行校验后写入数据库」，这句话没法验证，因为没人知道校验规则是什么、失败怎么办。合格的写法是把处理拆成可观察的动作序列，每一步都带判定条件。我一般给 IPO 表加两列：编号和约束。编号用于后续需求追溯，约束列写这条功能的前置条件和并发要求。

填写时有四条经验。第一，一行只描述一件可独立验收的事，功能条目之间不要嵌套。第二，输入列要写清「谁在什么时点以什么格式给」，操作员、上游系统、定时任务这三种来源的失败处理方式完全不同。第三，处理列避免出现「进行校验」「做相应处理」这类词，凡是出现就说明规则还没想清楚。第四，输出列要写去向而不只是内容，是返回给界面、落库、还是推给下游系统，直接影响接口章节的写法。终端数和并行操作用户数建议单列成表尾备注，别混在功能行里。

3.2 性能一节：精度、时间特性、灵活性怎么给区间而不是形容词

性能条目写成形容词是范围说明书最普遍的塌方方式。模板把性能拆成精度、时间特性、灵活性三块，实际上每一块都有对应的可测写法。精度用绝对误差或相对误差表达，例如「金额计算保留两位小数，四舍五入，单笔累计误差不超过 0.01 元」；如果涉及传输，要单独说明传输过程中的精度损失是否可以接受。

时间特性是四类时间的集合，模板给的四个词——响应时间、更新处理时间、数据的转换和传送时间、解题时间——各自对应不同的测点。响应时间从用户触发到界面给出反馈；更新处理时间从数据落库到对查询可见；转换和传送时间指跨系统搬运的耗时；解题时间指批处理任务从启动到完成的墙钟时间。给数值时必须同时给测量条件，否则验收时无法复现。我惯用的句式是：在 N 并发、数据库单表 M 行、应用服务器 X 核 Y G 的条件下，某操作的响应时间 P95 不超过 Z 毫秒。

灵活性这一块容易被写成「系统应具备良好的扩展性」，模板其实给了五个具体维度：操作方式变化、运行环境变化、接口变化、精度和有效时限变化、计划变化或改进。逐条对照填写，并且对为提供灵活性而专门设计的部分加以标明，比如「为适配未来可能更换的短信通道，通知模块采用可配置的通道适配层，切换只需改配置不改代码」。标明的意义在于让评审方知道这块的复杂度是买来的灵活性，未来维护成本要算在这里。

3.3 数据元字典与采集说明：值域、量纲、更新频度的填写口径

数据元字典是数据要求章节的落地形态。模板要求对每个数据元给出名称（包括缩写和代码）、定义或物理意义、度量单位、值域、格式和类型。六项缺一项，下游的建表语句和校验规则就得靠猜。我的做法是把字典做成固定列宽的表格，一行一个数据元，分组用静态数据、动态输入、动态输出、内部生成四类标题隔开。

数据约定单独列一节，把容量、文卷、记录和数据元个数的最大值写清楚，并对临界性限制加标注。比如「单客户订单明细保留 24 个月，按年均增长 30% 估算，第 24 个月单表约 1.2 亿行，为临界限制，超过后需分区」。这句话在架构评审时的分量，比十页功能列表都重。

采集说明按模板的七个子项走一遍：来源、输入媒体与硬件、接受者、输出形式与设备、值范围、量纲、更新和处理频度。量纲这一项常被忽略步长和零点定标，对传感器类或计量类数据尤其重要，比如「温度上报单位为摄氏度，步长 0.1，零点为冰水混合物」。预处理小节要写清格式转换、通信媒体和时间要求，涉及模拟转数字的还要给转换方法和转换因子。最后的影响分析不要省，写清这些数据要求是否会导致甲方增设岗位或扩容设备，这一条在立项汇报时是硬通货。

4. 从草稿到基线：范围说明书的四道评审闸口与变更控制

模板给你的是章节，流程给你的是产出节奏。很多团队把文档一次写成、一次评审，结果评审会开成朗读会，谁都没真正看进去。我的经验是把这份范围说明书拆成两到三轮：先出约束与环境的灰稿，再出功能与数据的完整稿，每轮过一道具体闸口，闸口不过不往下走。这一章说清起草顺序、四道闸口和变更控制的收口方式。

4.1 起草顺序：为什么先写约束再写功能

按模板顺序写，会从引言一路写到数据要求，实际写起来经常卡在功能条目上，因为约束还没定，功能写到哪算合适没谱。我一般调整成三段走：第一段只写引言、任务概述和运行环境，把系统边界、三方角色、约束条件、设备和软件环境钉住；第二段写需求规定里的输入输出要求、数据管理和故障处理，把数据流和异常路径画出来；第三段回头补功能条目和性能指标，这时每条功能都能对上前两段定下的边界和约束。

这个顺序的依据很直接：约束是最硬的信息，通常已经在合同或任务书里定死，几乎不需要讨论；功能是最软的，取决于前面约束能给多少空间。先软后硬会导致功能写了一大堆，最后被一句「预算只够一半」推翻重来。第二段先走数据流也有道理，输入输出和存储规模一旦定了，功能条目里的处理规则自然就是数据流上的变换节点，IPO 表填起来会快很多。

分工上，我的做法是引言和任务概述由项目负责人主笔，需求规定由需求接口人主笔、开发负责人陪写，运行环境和数据要求由技术负责人主笔。陪写这个动作不能省，开发负责人不在场写的功能条目，落到设计阶段大概率要被重写。写的过程里每完成一节就在文档末尾的修订记录里记一笔，谁写的、什么时候、依据哪份材料，出事时能倒查。

4.2 评审闸口：反向追溯、接口对齐、可测性检查

第一道闸口是可测性。逐条过需求规定里的功能条目，问一句：这条能不能写出至少一个测试用例？写不出来的条目直接打回。写不出来通常意味着处理规则含糊，或者输出没有明确定义。这一步不需要测试人员全员参与，两三个熟悉业务的人对着 IPO 表过一遍就够，半天能过完几十条。

第二道闸口是反向追溯。从功能条目往回推，看每条功能对应任务概述里的哪个应用目标；反过来，从目标往下推，看有没有目标写了但功能里没有落点。两个方向都要走，前者揪出孤儿功能，后者揪出空头目标。孤儿功能的处理方式是砍掉或者列入二期，空头目标的处理方式是补功能或者修正目标描述。这一步在评审会上做效果最好，因为目标通常是甲方最在意的部分。

第三道闸口是接口对齐。把文档里所有涉及外部系统的条目抽出来，和对方系统的接口说明书逐字段对一遍：字段名、类型、长度、必填性、协议版本、交互频次、失败重试和幂等策略。这一步最容易发现的问题是两边的叫法不一致，本文件叫「客户编号」，对方叫「客户 ID」，字段长度一个 18 位一个 20 位。这类问题在设计阶段发现是改一行字，在联调阶段发现是改一版接口。

第四道闸口是数据量与容量估算的自洽。把数据管理能力要求和数据要求里的记录数、单条大小、保留期相乘，和运行环境里的外存容量、备份窗口对一遍。常见的不自洽是：数据要求里写单表 1 亿行，运行环境里给的存储只够放三千万行，或者备份要求 4 小时内完成但按估算磁盘吞吐需要 9 小时。这一道过了，上线前的容量扩容就不会变成临时采购。

4.3 变更控制与版本基线：范围蔓延怎么在第 0 天就卡住

范围说明书签字之后就应该形成基线，但现实中总有「顺便加一个小功能」的请求。我的处理方式是把变更分成两类：影响约束的变更和只影响功能的变更。前者一律回到假定和约束那一节重写，工期、资源、依赖只要有一条变化，文档版本号就往上走一位并重新评审；后者走变更申请单，评估工作量和接口影响，评估通过后追加进功能表并标注变更编号，不重新评审全文。

文档里要留一张修订记录表，列日期、版本、变更内容、变更依据、批准人。变更依据那一列不要写「甲方口头提出」，要么补一份邮件确认，要么写清会议纪要编号。这条规矩看着死板，实际是保护双方：开发方后来解释为什么延期时，这份记录比任何口头承诺都管用。范围蔓延很少以「再加十个功能」的形式出现，多数是评审会上顺口一提的「这个也一起做了吧」，当时不拦，三个月后就是一笔糊涂账。

5. 避坑：五条血泪经验，每条都在真实项目里翻过车

模板的章节是固定的，坑的位置也相对固定。下面五条是我在不同项目里反复见到的塌方点，按现象、原因、解决三段写，能对号入座的就提前改掉。

5.1 范围与约束里的三个塌方点

现象一：评审会上没人反对，开发到一半说做不了。原因基本都在假定和约束这一节写软了，比如「开发周期约三个月」「需要一定的服务器资源」。软话在评审时不会触发任何人的警觉，等到资源真的不够，才发现当初没人承诺过具体数字。解决办法是把每一类约束都换成可核对的数字或日期，特别是依赖外部系统的部分，要写清对方提供数据的时间点、格式和频率，并注明「若对方延迟，本系统上线时间顺延」这类联动条款。

现象二：接口对不上，联调时两边各改一版。现象表现是本文件写「通过接口交互数据」，对方文档写「通过消息队列推送」，谁都没错但谁也接不上。原因在于接口一节只写了交互意图，没写字段级约定。解决办法是把接口拆成字段清单表，每个字段给名称、类型、长度、必填性、取值范围，再加一段交互时序说明：谁先发、超时多久、失败重试几次、重试是否幂等。这张表要和对方系统的说明书同步评审，双方签字。

现象三：术语漂移，同一份文档里「用户」有三个意思。现象是评审时两个人对同一条功能的理解完全不同，一个理解为登录账号，一个理解为客户。原因是定义一节空着，或者只写了几个缩写没写业务术语。解决办法是维护术语表并和数据元字典同源，同一个概念在全文只用一个叫法，其他叫法进黑名单。这项工作量很小，但收益极高，尤其是多人分段撰写的时候。

5.2 性能与数据里的两个隐性坑

现象四：性能指标验收时争议不休，双方各拿一份测试报告。原因是指标只写了数值没写测量条件，同一句「响应时间不超过 1 秒」，在 10 并发和 200 并发下测出来的结论完全相反。解决办法是把测量条件写进指标本身：并发数、数据量、硬件配置、测量工具和采样方式，四样缺一不可。更进一步，把测点和取值方式也写清，比如「取 P95 而非平均值」，避免用平均值掩盖长尾。

现象五：数据量估算差一个数量级，上线当天存储打满。原因是估算只算了当前记录数，没算增长率和索引、日志、备份的额外占用。解决办法是按模板要求做可预见增长的估算，写清年增长率、保留期限和单条记录的平均字节数，并对临界限制单独标注。我的习惯是在数据约定里加一行「本表在第 24 个月达到容量临界点，届时需做归档或分区」，让这条结论成为后续架构决策的输入，而不是上线前才被发现的意外。

提示：这五条里，前三条改起来几乎不花时间，后两条要在评审阶段就拉上测试和运维一起过，越晚发现成本越高。

6. 进阶：把 .doc 变成可检索的基线，给范围条目加一道自动检查

模板终究是 Word 文档，人工翻查效率低，评审时也很难保证每一节都真被看过。我后来的做法是每次定稿前把 .doc 转成纯文本跑一遍机械检查，专门抓两类问题：章节缺失和条目未量化。这一步不替代人工评审，但能把最基础的低级错误挡在评审会之前。

转换这一步有坑。.doc 是老二进制格式，直接喂给 pandoc 会报错，得先转成 .docx 再转 markdown。命令行环境里用办公套件的无头模式转换最省事：

# 老格式先转 docx，避免 pandoc 直接读二进制 .doc 报错 soffice --headless --convert-to docx 软件项目范围说明书.doc # 再转成 markdown，保留标题层级，便于按章节检索 pandoc 软件项目范围说明书.docx -t markdown -o scope.md # 快速看章节结构是否符合模板五章 grep -n "^#" scope.md

第一条命令依赖本机装了办公套件并配好 PATH，转出来的文件名默认同名换后缀。第二条命令里-t markdown保留标题层级，转换后中文章节标题会带#前缀，正好用来做结构检查。第三条命令的输出应该能看到引言、任务概述、需求规定、运行环境、数据要求五个一级标题，缺哪个一眼就能看出来。

结构对了之后，再跑一段几十行的检查脚本，抓未量化的性能条目和空章节：

import re from pathlib import Path text = Path("scope.md").read_text(encoding="utf-8") # 模板五大章，缺任一章直接报出来 required = ["引言", "任务概述", "需求规定", "运行环境", "数据要求"] for sec in required: if not re.search(rf"^#+\s*.*{sec}", text, re.M): print(f"[缺失章节] {sec}") # 性能类关键词所在行若不含任何数字，大概率是形容词堆砌 keywords = ["响应时间", "处理时间", "传送时间", "解题时间", "并发"] for lineno, line in enumerate(text.splitlines(), 1): if any(k in line for k in keywords) and not re.search(r"\d", line): print(f"[未量化] 第 {lineno} 行: {line.strip()}") # 术语表与数据元字典是否为空的粗检 for sec in ["定义", "数据约定"]: block = re.search(rf"^#+\s*.*{sec}(.*?)(?=^#)", text, re.M | re.S) if block and len(block.group(1).strip()) < 50: print(f"[疑似空节] {sec}，正文长度不足 50 字符")

脚本三段分别对应三种低级错误。第一段查章节完整性，模板五章是硬要求，缺章说明文档根本没按骨架写。第二段查量化，逻辑很简单：提到响应时间、并发这类词的行里如果一个数字都没有，那基本就是「响应时间要快」这类废话。第三段查空节，用正则在两个一级标题之间截取正文，长度不足就报疑似空节，对付「定义」和「数据约定」这种经常留白的章节很有效。阈值 50 是我按中文填写习惯拍的，团队可以按自己的模板调整。

这套检查跑完通常只要几秒，但能省掉评审会上最没营养的那半小时。有一次我拿它扫一份已经过了两轮评审的稿子，扫出七条未量化的性能描述，其中三条当场被开发指出根本没法测，那一次之后我就把这个步骤固定进了文档定稿流程。机械检查负责扫地，人负责判断，两者不冲突。希望帮到你。

本文还有配套的精品资源，点击获取