SRS需求规约模板拆解：六章骨架、落地流程与追踪矩阵

简介：这份文档围绕IBM软件需求规约（SRS）的格式要求与案例展开，面向项目经理、需求分析人员、开发及测试QA团队，帮助读者在项目早期组织完整需求、明确系统外部行为，并为需求讨论、设计输入和测试用例编写提供统一参照。压缩包内含1个doc文件，约150KB，篇幅集中，便于直接查阅和复用其章节结构。内容覆盖SRS概述、指定、标准、数量、可用性、安全性等模块，同时涉及功能性需求、非功能性需求、假设与问题列表、从前景到SRS以及活动工件等要点，可帮助读者理解需求规约如何收集、组织和验证需求。已有277人学习下载，适合需要参考IBM模板要求、梳理SRS目录框架或完善需求文档的初、中级从业人员。

1. 需求规约被退回三次之后，我才看懂这套模板的价值

某次内部评审，一份需求规约（SRS）连着被退回三次，理由都差不多：功能性需求写了几十页，非功能性需求那一栏只有“系统应具备良好的性能与可用性”。写的人委屈，看的人也没法签字——这种句子既不能指导设计，也不能拿去写测试用例。后来换成这套出自统一过程方法论、由一家大型 IT 厂商公开维护的需求规约要求，逐条对照着补，才发现它真正值钱的地方不是那六个章节的目录结构，而是把“假设”“指定”“策略”这些平时散落在会议纪要和口头约定里的东西，全部变成了必须落笔、必须有人认账的条目。它适合正在补需求文档的开发、被临时拉去写 SRS 的测试人员，以及需要拿一份文档跟业务方逐条对齐的项目经理。下面按“骨架长什么样 → 怎么填 → 哪里会翻车 → 怎么验收”的顺序拆。

2. SRS 骨架拆解：六个一级章节分别在拦什么风险

这套模板的章节顺序不是随手排的。它先从“我们还不知道什么”入手（概述里的假设与问题），再收紧“哪些东西已经被定死了”（指定），接着对齐“组织层面已有的规矩”（标准与策略），最后才落到三个必须量化的维度（数量、可用性、安全性）。这个顺序背后是一条很实际的判断：一份 SRS 里真正会导致返工的，往往不是功能漏写，而是约束没写、量化没做、非功能需求写成形容词。

我见过太多团队把 SRS 当成功能清单的加长版，结果设计阶段才发现要跑在客户既有的操作系统映像上、要接一个不能定制的封装包、要在每天晚上停机做批处理。这些信息在模板里全都有位置，只是没人往里填。下面按章节拆开看，每一节都说明“这一章在拦什么风险”和“合格线在哪”。

2.1 概述与地理组织：把“假设”和“问题”变成两条独立台账

概述这一章看起来最虚，实际上它承担了一个很硬的任务：把所有“暂时没答案但会影响设计”的东西显式记录出来。模板要求维护两个列表——假设列表和问题列表，而且这两个列表要随着设计研究持续更新，不是写一次就封存。

假设列表要记的是：在需求和设计过程中做出的所有假设，以及每条假设背后的推理过程；还有那些可能牵出项目之外（或项目之后）相关子项目、相关工作项的假设。问题列表记的是所有可能中断项目推进的重要事项。模板特别提到，在每个阶段结束时应该和客户一起复审这些问题；假设也要复审，但不太重要的假设，客户未必是合适的复审人选——这点很关键，否则每次复审会变成一场把客户拖进技术细节的消耗战。

地理组织这一节常被当成填表应付，但它直接影响后面几个章节的写法。要记录的内容包括：受系统影响的业务部分所处的地理位置；未受影响但安装有主要 IT 设备的工作地点；组织里所有的移动工作部门（比如常年在外跑、用工作站办公的销售团队）；以及所有可能需要提供特殊自然语言支持（NLS）的地理位置。最后一条经常被漏，等到上线前才发现某个区域的用户要求从右向左的文本排版。

提示：假设列表和问题列表建议单独建文件维护，不要埋在 SRS 正文段落里，否则每次复审都要重新翻一遍。

2.2 指定：预选应用包、特殊硬件、现有数据这三类硬约束

“指定”是整份模板里最容易被低估的一章。它问的是一个很直接的问题：需求里有没有已经钦定、会限制设计灵活性的东西？如果有，现在就得写清楚，因为这些东西一旦进入设计阶段再暴露，代价是重做架构。

第一类是预选的应用程序包。模板列了一长串会被封装包锁死的设计决策：工作站类型、连接方法、处理器和存储设备类型、系统控制程序、数据组织与存放管理方式、编程语言、批处理接口、进程与数据关系、业务逻辑、屏幕设计和最终用户界面、性能与可用性特征、既有的打印架构（比如首选打印数据格式 PostScript、PCL、IPDS）、国家语言支持。这里有一条血泪经验：如果你有一个“指定”包，务必提前确认团队能不能拿到这个包的适当技能和知识，来源可以是厂商、外部顾问、或受过专门培训的成员。模板原话的意思很直白——不要认为这些知识很容易获得，要确保在需要时能拿到。

第二类是其他指定。包括：使用现有的处理器或操作系统映像、使用现有的工作站设备、使用现有的网络、使用现有的系统管理惯例、以及使用特定的架构模型（例如明确要求用客户机/服务器模型，并在设计里标出表示逻辑、业务逻辑、数据访问逻辑的位置和交互方式）。这里有个连锁反应要特别注意：如果新系统要跑在现有平台和现有负载上，那现有负载已经占用了多少连接和处理容量、用的是什么安全控件、有什么可用性特征（比如是不是每天夜里必须关掉整个处理器），全都会传导到新系统的非功能需求上。这些必须记录下来，后面写安全性和可用性时逐条对照。

第三类是特殊硬件。可以写得笼统（“系统必须支持高速平板绘图仪”），也可以写得很具体（点名某型号设备）。要记的包括：硬件或软件先决条件、厂商及其支持组织、国家语言考虑、加密设备。

第四类是现有数据。如果需求指定要沿用现有数据，那下面六项必须落笔：数据当前在什么系统上、现有数据的结构（关系型文件还是平面文件）、数据量大小、目前哪些用户和系统在用、可用性上的限制（比如因为数据库维护或批处理导致数据不可用的时间段）、以及这些数据能不能移动或复制。

注意：现有数据的“不可用窗口”这一项，是后面写服务时间和中断成本时最直接的输入，别只写一句“数据在主机上”。

2.3 标准与策略：技术架构、网络架构、连接策略怎么读

这一章处理的是“组织已经有的规矩”，它的存在理由是：客户方几乎一定有一套技术架构或 IT 战略计划，你的设计要么对齐它，要么在 SRS 里明确写出为什么不对齐。

技术架构大致等同于企业技术平台、企业技术基础设施。在这份文档里通常能查到：计算中心的数量和用途、企业级广域网连接性、某些场地的局域网连接性、客户机/服务器基础设施服务（中间件）的覆盖范围、用于新应用的开发方法、已接受的可支持产品集（硬件、系统控制软件、常用办公应用、帮助台的使用方式、安全规则）、打印子系统架构。中间件服务那一段值得细读，它列了四类：跟踪网络资源和属性的目录及命名服务；防止未注册用户非法使用网络资源、并规定权限级别的安全服务；校准全网日期与时间的时间服务；协调网络中各种系统资源恢复活动的事务管理服务。这四类服务如果客户已经有，你的系统通常要复用，而不是自己再造一套。

需要记录的是那些明确要求使用或排除某些子架构的需求，例如 OSI 或 SNA、某种 UNIX 变体、厂商的专有系统应用架构、特定硬件加特定操作系统的组合、以及因为选用封装应用方案而被动引入的特殊架构。还有一项容易被忽略：客户要求的开放程度，也就是厂商独立性和互操作性到什么水平。

网络架构是一组公用的高层连接性规则，外加一个公用传输基础设施，可能包括对主干网络（集线器和线路）的定义。要了解基本规则和拓扑，并记录：物理拓扑方面的考虑（网络覆盖的是人口稀疏还是密集区域、网络附属装置是集中还是分散）、当前网络基础设施支持哪些高层连接功能、用哪些通信标准支撑这些功能（SNA、OSI、TCP/IP）、支持哪些编程接口、以及对客户机/服务器各层之间连接性的具体规定。最后这条经常以很硬的形式出现，比如“表示逻辑必须始终在工作站，数据访问逻辑必须始终在集中式主机”，或者“客户机到关系型服务器的数据访问必须走某个特定数据库产品的协议”。

连接策略这一节，即使客户没有成文的技术架构或网络架构，也仍然可能有约定俗成的策略。要记录：是否要求用特殊协议或通信设备实现跨建筑、跨组织边界的连接；是否隐含地要求用某个特定协议来支持现有设备或软件；是否沿用现有的物理连接设备（电缆、网络或外围控制器、常用载体），如果不沿用，是因为政策、法规、场地空间、产权、第三方参与等哪一类约束；如果需要安装或修改物理设备，会牵涉哪些第三方（承包商、公用通讯单位），职责怎么划分；以及对移动用户的支持方式。

其他策略这一节列的例子都很具体：所有新系统的最终用户接口必须按面向对象原则设计并支持拖放、所有新系统必须基于客户机/服务器模型、所有新系统必须按公开标准定义、国家语言支持的标准和政策（尤其是从右向左文本这类）、定义用户身份验证、访问控制和数据保护的管理职责与安全策略、可能需要特殊连接或安全设备的应用间交换标准。还有一个非常现实的策略问题：用户或部门能不能在工作站和服务器上自行添加、开发本地程序。模板给了一个很典型的后果描述——如果不加控制，本地程序会很快耗尽生产系统所需的资源，而这些本地构件原本是为生产系统采购的；等到首次公开展示生产系统时，可能发现系统装不上去。

2.4 数量、可用性、安全性：三个最容易被写虚的维度

这三章是整份模板里最难填、也最能拉开文档质量差距的部分，因为它们要求的都是数字和时间，不是形容词。判断标准很简单：写完之后，测试人员能不能照着写出一条可执行的验收用例；设计人员能不能据此做出容量和拓扑决定。

数量这一章的核心动作是先定“评测单元”。要和开发人员一起把业务流程切成更小的单元（更小的业务流程或事务），因为下一步要记录数量，必须先明确数的是什么。这里有个乘数问题：一个业务流程可能启动多个更小业务事务的实例（比如每张客户订单里有多个订购行项），记数量时要把乘数算进去，但也不必过度深究细节，复杂系统尤其如此。还有一个容易被忽略的组织问题：不同人群对同一个单元的叫法不一样——“事务”对应用开发背景的人是一个意思，对基础设施团队可能是完全另一个意思，所以要先协作把名称对应关系理清，再收集信息。

可用性这一章的方法论在 3.3 节展开，这里只说它的结构：先确定真实最终用户、他们执行的业务流程和执行时间；再分析服务可用或不可用会怎样影响用户完成业务目标；最后才写可用性需求。安全性这一章的结构是“保护对象清单 + 侵害场景 + 威胁来源 + 特殊需求”四段式。

3. 从前景文档到 SRS 包：一份可评审文档的落地流程

填这份模板最容易犯的错，是从第一章开始按顺序往下写。实际顺序应该是反过来的：先划清四份工件的边界，再把最难的量化部分（数量、可用性、安全性）先做掉，因为它们会反过来影响前面章节的内容。这一章给出一条可复制的推进路径，每一步都对应模板里的具体位置。

3.1 划边界：四份工件各管一段，别互相抄

模板里有几段话其实是在反复强调一件事：SRS 包和前景文档有关系，但服务的是不同需要，通常也由不同作者编写。在项目这个阶段，重点已经从“概括说明用户需要、目的和目标、目标市场、系统特性”转移到“这些特性在解决方案里到底怎么实现”的具体细节。SRS 包要描述的是系统的全部外部行为，用一句直白的话概括就是：为了交付这些功能，系统必须执行以下操作。

功能性需求推荐在用例模型和用例里定义；非功能性需求（设计约束、质量属性这些）记录在补充规约里；SRS 包则是一个信息包，把这些分散在不同工件、用不同工具记录的需求集合起来。模板明确说，不要把注意力放在工具差异上——你是在收集需求，重点应放在有效收集和组织上，而不是纠结用哪个工具。所以我在项目里一般这样分工：

这里有个判断需要说清楚：SRS 不是一次性交付的大卷文档。模板的表述是“活动的、有生命的工件”，它在开发阶段承担三重角色——各方之间的交流基础（不同开发人员之间，以及开发人员和外部小组之间）；正式或非正式的契约性协议（不在 SRS 里的，开发人员不应处理；在 SRS 里的，开发人员有责任交付）；以及项目经理、设计和实施小组、测试和 QA 小组的参考标准。最后这条特别值得向管理层解释：项目经理不太可能有足够时间精力去读代码再和前景文档比对，他们只能拿 SRS 当讨论的标准参考。

提示：如果团队里有人坚持“SRS 就是把前景文档复制一遍”，把上面那句“不在 SRS 里的不应处理，在 SRS 里的必须交付”贴在评审会上，通常一次就能把边界谈清楚。

3.2 数量章节：先切评测单元，再谈峰值

数量这一章的填写顺序我一般是四步走，顺序错了后面全要重算。

第一步，切评测单元。和开发人员一起把每个业务流程拆到“事务”这一层，明确每个业务事件的乘数。比如“客户下单”是一个流程，“查询库存水平”“生成客户信函”是流程内的 IT 事务，一张订单平均带 6 个行项，那行项级操作就要乘 6。这一步不要陷入细节，拆到能估量级就停。

第二步，对齐命名。把业务方、应用开发、基础设施三方对同一单元的叫法拉齐，形成一张对照表。模板强调这件事的原因是：名称不一致会导致收集上来的数字根本不可比。

第三步，填业务量和大小。每个单元要记录：一般时段和高峰期各有多少用户使用该业务流程或应用；高峰期出现在什么时候（按日、周、月分别判断）；高峰期和一般时段各需要什么事务处理速率；每个数据组里数据元素和实例的数量以及它们的大小。

第四步，写性能标准。模板提醒，除了业务流程本身的性能标准，还要记录系统支持流程（比如系统备份）和应用程序开发流程的性能目标。对每一类要写清：响应或周转需求是什么；在哪里评测；非高峰时段是否允许不同标准；恢复或应急期间能不能达到；是否需要性能保证条款；没达到性能需求会对各方产生什么影响；以及最容易被漏掉的一条——业务流程被认为可用的最低性能条件，也就是低于这个点，系统应当被认定为“不可用”，而不是“缓慢”。

如果已经选定封装应用方案，还有一件事要现在就做：搞清楚怎么拿到它的性能特征数据。模板的说法是，现在可能根本不需要这些数字，但将来一旦需要，你得知道去哪里找；让第三方提供数字可能要花不少时间，所以现在就该提要求。这条经验在项目后期救过我不止一次。

3.3 可用性三段式：服务时间 → 中断成本 → 恢复标准

可用性需求写不好的根因，是大家一上来就写“几个 9”。这套模板给的路径是反过来推的，我把它整理成三段式，配一个条目模板。

第一段，服务时间。对每个业务流程和必须执行该流程的用户组，确定用户必须能执行该流程的时间。不同时区的用户组要当作独立用户组处理，因为这样才能给设计留出维护窗口。模板给的对照很说明问题：写“系统必须每天 24 小时为两个相隔 12 小时时区的用户提供服务”，设计灵活性远不如写“东部时区用户在工作日 7:00–19:00 必须能对自己的数据做事务处理；西部时区用户在工作日 7:00–19:00 必须能对自己的数据做事务处理”。后一种写法下，一个时区还在工作时，设计人员可以对另一个时区的数据或系统构件做维护。还要说明是否存在不需要应用的偶发时段（比如业务假期），以及在整个应用生命周期内这些服务时间会怎么变，是否受其他系统服务时间制约。

第二段，中断成本。要确定在计划服务时间内发生中断带来的业务影响、财务成本和风险，并按中断时长分档评估：短暂中断或响应极慢的时段（“短暂”和“极慢”要结合具体应用定义）、数分钟到数小时的各种时长、以及一次换班/一天/多天的长时间中断。量化角度包括：员工或设备生产率下降的成本、失去当前业务的价值损失、客户不满意导致的未来业务损失、利息开支、监管性处罚。同时要区分计划中断和意外中断、中断发生在一天中的什么时段、影响哪些用户组。评估每种中断影响时，要一并确定应急过程，以及这些过程如何降低实际影响。

模板在这里给了一个非常实用的抓手：缩减功能模式。也就是系统部分不可用时，让关键流程以降级方式继续运行。原文的例子可以直接改用：完整功能是读取并更新记录，缩减功能是先接收更新请求、排队等恢复后再入库；完整功能是读最新余额，缩减功能是从可能不很新的备选来源读余额；完整功能是更新电子日记，缩减功能是先记在纸上。但要给降级状态设边界，比如过时余额的滞后不得超过 24 小时。

第三段，恢复标准。这里只写“正常”情况，不包括灾难。写法有两种基本形式：在给定分钟或秒数内被恢复的中断所占的百分比；在给定周、月、年内用户无法执行特定功能的最大时长。要尽量把计划中断与计划外中断、中断发生的时段、受影响的用户范围区分开。模板有一句提醒很到位：不要指定不太紧迫的可用性标准，因为这会显著影响实施成本；反过来说，如果在一组给定中断条件下算不出业务或财务成本，那这类中断条件可能就不该写进可用性标准。如果计划服务时间或中断成本在系统生命周期内会变化，还要估计可用性标准会怎么跟着变。涉及加密系统时，额外考虑两件事：能恢复可能存放在系统之外的机密信息；确保加密保护数据的恢复与加密密钥的恢复相互协调。

<!-- 可用性需求条目模板：每个用户组 × 每个关键流程一条 --> - 需求编号: AVA-<流程代号>-<序号> - 用户组: <区域/角色，跨时区必须拆开> - 业务流程: <流程名，与数量章节的评测单元对齐> - 服务时间: <每周哪几天、几点到几点、是否含业务假期> - 强制/希望: <强制项写"必须"，期望项写"希望"并给容忍范围> - 性能底线: <低于此值判定为不可用，而非缓慢> - 中断成本分档: <1min / 5min / 30min / 2h / 1 班次 各自的业务影响> - 缩减功能: <降级时可接受的操作与数据滞后上限> - 恢复标准: <X 分钟内恢复的中断占比，或每季度最大不可用时长> - 评测点: <在哪里测、谁来测、用什么口径>

这段模板里每个占位符都对应模板原文的一条要求：需求编号用于后面做追踪矩阵；“强制/希望”的区分来自原文对 ATM 的例子——必须 24 小时能存取款，希望 24 小时能查准确余额，但允许凌晨 3:00 到 4:00 之间有累计不超过 10 分钟的中断；“性能底线”对应“最低性能条件”；“评测点”对应“将在哪里对其进行评测”。填不出来，通常说明前面某一步没做完，而不是模板太细。

注意：模板反复强调一条判断原则——间接反映用户体验的可用性需求（比如“必须建立某个控制区域”）通常不如直接反映用户体验的需求有用（比如“出纳必须能执行流程 X 和 Y”）。写的时候拿这条筛一遍。

3.4 安全性：保护对象 × 侵害场景，两张表交叉

安全性这一章的填法是两张表交叉，不是写一段“系统应保证安全”。

第一张表是保护对象。按逻辑或物理安全性列出需要保护的东西：账户信息、客户名单、合同、专利资料、密钥、设备本身。第二张表是侵害场景，模板给了三个典型类别：查看访问（违反保密性）、更新访问（为欺骗、掩饰、资金转移而修改数据）、资产丢失（所有权被他人获得从而对拥有者不再可用，注意这有别于灾难造成的丢失）。交叉填写时要注意，并非所有对象对上述所有场景都敏感，这一格填“不适用”是完全正常的。

威胁来源也要单独列：心怀不满的雇员、未经授权的雇员、在公开场合进行终端会话、外部入侵者、线路窃听、设备丢失（便携机）。然后确定每种数据受到的威胁类型：意外损坏或破坏、故意损坏或破坏、商业间谍、欺骗、入侵、病毒；物理安全威胁则是构件被偷、未经授权的物理访问、用户人身安全。

还有两个容易漏的点。一是要检查对象在静态位置（比如硬盘上）和移动中（传输期间）的安全性需求可能不同，而且设计可能会把对象扩展到不安全的区域，所以这一节要回头复查。二是一般性政策的影响，比如信息公开相关的法规要求。如果选了封装应用方案，要单独确认它自带的安全子系统能力边界。

模板最后给了一条判断标准，值得原文照搬到评审清单里：如果系统在安全性方面有非常苛刻的要求（敏感业务系统、大额资金清算、处理个人机密信息的系统），这些要求会支配设计决定，可能让在其他情况下很合适的结构和构件变得不可接受。这种情况下应当找安全专家或安全从业者协助设计，而不是靠需求文档自己扛。

4. 避坑与排查：五类最常见的 SRS 翻车现场

这几条都是我在实际评审里反复见到的，按“现象 → 原因 → 解决”记下来，方便对着排查。

4.1 需求归属与粒度类翻车

其一，SRS 里塞满了功能描述，非功能性需求只有一句话。

现象：评审时功能章节几十页，非功能章节不到一页，测试组拿不到可执行的验收条件。

原因：写的人把 SRS 当成功能清单，把补充规约当成可选项；而模板明确说非功能性需求应记录在补充规约里，SRS 包负责汇总和索引，两边都没做，就出现了真空。

解决：按 3.1 的分工表把四份工件的责任人定下来，在 SRS 包的功能条目后面强制挂“关联的非功能需求编号”，挂不上就说明这条需求还没写完整。评审时随机抽 5 条功能需求，要求当场指出对应的性能、可用性、安全性条目，抽不出来就打回。

其二，同一条需求在三份文档里写了三个版本。

现象：用例里说“查询响应在 2 秒内”，补充规约里写“响应迅速”，SRS 里又写成“实时响应”，开发按 2 秒做，客户按“实时”验收。

原因：多工具、多作者、没有单一来源。模板对这点说得很清楚：需求可能在数个不同工件中用不同工具找到，文本类需求放补充规约、功能性需求放用例模型都是合理的，但前提是有一个汇总口径。

解决：给每条需求一个全局唯一编号，在所有工件里只引用编号不重复描述正文；改动只在“权威工件”里改，其他地方同步引用。这条规则落地之后，我见过的重复描述冲突基本消失。

4.2 约束与标准类翻车

其三，设计做到一半才发现客户有强制技术架构。

现象：架构评审会上客户丢出一份技术架构文档，里面规定了中间件服务、可支持产品集和打印子系统架构，已经画好的部署图要推翻重画。

原因：SRS 的“标准”章节被跳过，或者只写了一句“遵循客户技术架构”，没有把具体条目摘出来；同时没有记录客户要求的开放程度和厂商独立性水平。

解决：在 SRS 里逐条摘录会约束设计的规则，包括明确要求使用或排除的子架构（通信协议、操作系统族、专有系统应用架构）、中间件的四类基础服务是否必须复用、打印数据格式要求。摘录时标注来源文档和版本，因为架构文档本身也会更新。

其四，忽略了“其他指定”里的现有平台负载。

现象：新系统上线后性能不达标，排查发现现有处理器和网络上已经跑着一批业务，新系统能分到的容量远低于估算。

原因：只记录了“要跑在现有平台上”，没有记录现有负载已经占用了多少连接和处理容量、用的是什么安全控件、有什么可用性特征（比如是否要求每晚关闭整个处理器）。

解决：把“其他指定”当成一份清单逐项打勾：现有处理器或操作系统映像、现有工作站设备、现有网络、现有系统管理惯例、特定架构模型。每一项后面追问三个问题——现有占用多少、有什么既有约束、会不会传导到新系统的安全性和可用性设计。

提示：现有环境的“每天晚上关闭处理器”这类惯例，会直接推翻你写的 7×24 可用性目标，务必在写可用性章节之前确认。

其五，把“希望”当成“强制”写进合同。

现象：上线验收时客户拿 SRS 逐条对，凡是写了的都要算钱，团队被迫做了大量成本高但业务价值低的功能。

原因：SRS 具有契约属性——在里面的开发人员就有责任交付。模板在可用性章节专门提醒要区分希望的可用性特征和强制的可用性特征，这个原则对其他非功能需求同样适用。

解决：每条非功能需求标注“强制/希望”两档，希望档必须附带容忍范围和触发条件（例如“允许偶尔中断，但单次不超过 10 分钟，且只发生在凌晨 3:00 到 4:00 之间”）。没有附带范围的希望项，一律按强制项处理，宁可不写。

4.3 可用性与量化类翻车

其六，评测单元没对齐，容量估算整体偏差一个数量级。

现象：容量规划里的“事务”和压测脚本里的“事务”不是一回事，压测通过但生产环境撑不住。

原因：业务方、应用开发、基础设施三方对“事务”“流程”“订单”的定义不一致，且没有把业务事件的乘数（一张订单多个行项）算进去。

解决：先出命名对照表，再做数量收集；每个评测单元标注乘数来源和假设；性能标准要写明评测点在哪里、由谁测、什么口径。这三件事做完，容量估算的偏差通常能压到可接受范围。

5. 评审怎么过：三条自检线和一张对账表

文档写完不等于能签字。这一章给的是签字前自己先跑一遍的检查动作，目的是把评审会上会被问倒的问题提前消掉。三条自检线分别对应可测试性、一致性和边界完整性，最后用一张对账表把四份工件串起来。

5.1 可测试性自检：每条需求能不能当场写出一条验收用例

做法很笨但有效：把 SRS 里的条目随机抽 20 条，逐条问“这条需求的验收用例第一句怎么写”。写不出来的，基本可以判定为不可测试。

常见写不出来的三类：包含“良好”“高效”“友好”“尽可能”这类无参照系的形容词；包含多个主体却没有判定条件的复合句（“系统应支持多用户并发访问并保证数据一致性”，两个要求混在一句里）；只描述手段不描述结果的句子（“系统应使用缓存技术提升性能”，这句话约束了实现方式，但没说性能目标）。模板在可用性章节给的原则可以直接借用：如果一个目标没有达成也不会直接影响用户完成业务目标的能力，那它可能就不适合作为需求。

自检时还要顺带确认一件事：性能标准里的评测点写清楚了没有。同一句“响应时间 2 秒”，在客户端测、在应用服务器测、在网络边界测，结果能差出一倍。模板要求记录“将在哪里对其进行评测”，这条不留白。

5.2 三角对账：SRS、前景、用例、补充规约的交叉一致性

对账的目标是回答三个问题：前景文档里的每个系统特性，在 SRS 里有没有对应的需求条目；用例模型里的每个用例，在 SRS 里有没有引用；补充规约里的每条非功能需求，有没有被至少一条功能需求“消费”。前两个方向查漏，第三个方向查悬空——悬空的非功能需求往往是没人认领的成本来源。

具体做法是在评审前跑一遍机械对照：把前景文档的特性清单、用例清单、补充规约的条目清单各导出一份，和 SRS 的条目编号列表做集合运算。差集里出现的项，要么补进 SRS，要么明确标注“本期不做”并写明理由。这一步用脚本或表格都能做，关键是有人在评审会上对差集逐项解释。

对账时还要检查一遍地理组织和 NLS 的落地情况：需要特殊语言支持的位置，在界面需求、数据存储、打印输出三个地方是否都有对应条目。这一项如果只在概述章节写了一句话，基本等于没写。

注意：对账要对着编号做，不要对着标题做。标题会在迭代中被改写，编号不会。

5.3 签字前的边界确认：把“不做什么”写进文档

模板在灾难恢复那一节有一句话很值得推广到整份文档：并不一定所有业务流程都需要灾难恢复设备，只应选择那些至关重要并且的确需要灾难恢复的流程；即使在这些流程内，也可能不需要包括所有功能。这个思路的本质是——范围边界要写清楚，而且边界要写在被排除的那一侧。

签字前建议确认四件事。第一，灾难恢复范围：哪些流程进、哪些不进、进的部分包含哪些功能；恢复时间从灾难发生时算起还是从决定切换时算起；异地数据要新鲜到什么程度（时刻最新、故障后几分钟内更新、还是可以接受前一天的数据）；首次从异地恢复服务是什么时候；相对于共享同一套计算设备的其他应用，这组应用的恢复优先级如何。第二，维护窗口的弹性：系统能否在短时间内只执行查询不执行更新，能否接受用户发出更新请求但实际在维护完成后才入库。第三，在途请求的处理：故障发生时用户请求处于“处理中”，服务恢复后是否要求用户重新输入。第四，非技术性耦合：是否存在业务策略规定“流程 B 对用户不可用，则流程 A 也不可用”。

把这四条写进 SRS 的对应章节，评审时争议会少很多，因为大部分争议其实来自“以为对方知道”。

6. 把 SRS 变成活文档：编号规则加一张追踪矩阵

模板里那句“SRS 不是一成不变的大卷文档，而是活动的、有生命的工件”，落地靠的不是自觉，是编号和矩阵这两个机械手段。

编号规则我一般用“域-流程-序号”三段式：域取 FUN（功能）、QUA（数量与性能）、AVA（可用性）、SEC（安全）、CON（约束与标准）五个，流程用两位数字对应业务流程清单，序号三位递增。比如 AVA-03-002 表示第 3 个业务流程的第 2 条可用性需求。这么编号的好处是，任何人看到编号就知道该去哪一章找上下文，评审时口头引用也不会串。

追踪矩阵是那张把所有东西串起来的表，列固定为六项：需求编号、来源（前景文档特性 / 用例 / 补充规约条目）、优先级（强制/希望）、验收用例编号、设计构件、状态。每次迭代只更新状态列和新增行，不重排历史行，这样矩阵本身就成了一份变更记录。

矩阵真正发挥作用是在两个时刻：一是需求变更时，从编号反查验收用例和设计构件，能立刻估出改动波及面；二是项目收尾时，状态列里所有“评审中”和“待验证”的行就是遗留风险清单，不用再靠回忆整理。

还有一个习惯我后来强制自己执行：每次 SRS 版本更新，先跑一遍“悬空检查”——矩阵里有没有需求没有验收用例，有没有验收用例找不到对应需求，有没有设计构件没有挂任何需求。这三类悬空项在一次迭代里通常各能查出几条，越晚发现越贵。有一次就是因为一条 AVA 需求没挂验收用例，上线后才发现降级模式的时效边界根本没测过，只能临时补一轮演练，那次的教训让我从此把这张矩阵当成发布前的必过关卡，而不是文档附件。希望帮到你。

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