简介：这份DOC文档面向软件需求分析人员、项目经理及测试与QA团队，提供IBM软件需求规约的格式模板要求与案例参考，用于解决SRS结构不清、需求收集与组织不规范等问题。文档共1个DOC文件，约150KB，篇幅紧凑，便于快速查阅和对照使用。内容围绕概述、指定、标准、数量、可用性、安全性六大部分展开，涉及假设与问题列表、地理组织、预选应用程序包、特殊硬件与现有数据约束、技术及网络架构、评测单元与业务量、服务时间与灾难恢复等记录要点，并说明功能性需求可借助用例模型和用例定义、非功能性需求应记录于补充规约。已有277人学习，适合需求分析、项目管理、测试与QA人员作为撰写SRS、评审需求完整性和建立测试依据的参考资料。
1. 需求规约：为什么“写清楚需求”反而经常把项目写死
一份 SRS 写得越厚，项目死得越快——这话听着反直觉，但做过几年需求的人多半见过：几百页 Word 里躺着一堆“系统应具备良好的扩展性”“界面应友好”，评审会开了六轮，最后开发照样按自己的理解开工，上线后吵架时双方都能从文档里翻出对自己有利的句子。问题不在“写不写”，而在 SRS 到底是一个什么样的工件。这份来自 IBM 体系的需求规约模板给出的答案很直接：SRS 不是一卷交付后就被放进角落的文档，而是一个“活动的、有生命的”需求包；它把“如果不是 SRS 包中的内容，开发人员就不应处理它；如果是 SRS 包中的内容，开发人员就有责任交付”当作契约底线。搞懂它的结构性设计动机，比套用它的目录更重要，因为那些看似啰嗦的章节——地理组织、连接策略、服务中断成本、缩减功能——每一条都对应着后来设计阶段一个真实的翻车点。
2. 定位先行：SRS 是包不是文档，这个判断如何改变后续一切
模板开篇就问了一个很“工程哲学”的问题：SRS 到底是文档还是包？它自己给了答案——不必纠结工具差异，重点是有效地收集和组织需求，因此假定 SRS 中的需求集合构成一个信息包。这个判断不是文字游戏，它直接决定了后面所有章节的组织方式和可维护性。
2.1 从前景文档到 SRS：工件交接时到底交了什么
模板明确说 SRS 包与前景文档有关，前景文档可作为 SRS 的输入，但两者服务于不同需要，通常由不同作者编写。区别在于关注点的迁移：前景阶段概括说明用户需要、目的和目标、目标市场、系统特性；进入 SRS 阶段，重点转向“将如何在解决方案中实施这些特性的具体细节”，需要的是一个能描述系统全部外部行为的工件集合，用一句话概括就是“为了交付这些功能，系统必须执行以下操作”。
常见的实现思路是把功能性需求放在用例里，把非功能性需求、设计约束放在补充规约里，再用工具把它们关联起来。模板对此的态度相当务实：你可能用几种不同工具收集需求，需求可以分散在数个不同工件中，不必为了工具统一而牺牲表达效率。真正的约束不是“一个文件”，而是“一套可追溯的集合”——哪个需求来自哪条前景、哪条用例、哪条约束，链路要闭合。一旦按包来理解，需求就获得了版本、归属和状态，而不是一段无法定位的段落。
2.2 活动的工件：SRS 在开发、测试、管理三条线上分别承担什么
模板给出了 SRS 的三个消费方，这个划分值得单独拆开看。第一是开发人员，SRS 充当各方之间的交流基础，包括不同开发人员之间、开发人员与外部小组（用户和其他涉众）之间；它以正式或非正式方式代表契约性协议。第二是项目经理，他们不太可能有时间精力去读代码再跟前景文档对照，必须把 SRS 当作与团队讨论的标准参考。第三是测试和 QA 小组，他们的职责是创建测试用例和 QA 过程，确保系统确实满足了 SRS 提出的需求，SRS 同时是计划和测试活动的标准参考。
提示：把“谁读这份 SRS”写进工件说明，比在文档开头写一句“本文档适用于全体项目成员”有用得多。三类读者的阅读目的不同，对同一份需求的颗粒度要求也不同。
这里的机制值得多想一层：一个工件能同时服务三种读者，前提是需求条目本身是原子化、可引用的。如果一条需求写成三大段散文，开发能读，测试没法据此写用例，项目经理也没法拿它做验收口径。所以“活动的工件”这个定位，实际是对需求的可引用性提出了硬要求——每条需求要能被单独指向、单独判对错、单独追溯来源。这也是后面所有章节共享的隐含设计：功能性需求走用例建模，非功能性需求走补充规约，两类都在 SRS 包里汇合成可验证的集合。
3. 约束的收集：为什么“指定”和“标准”要写在需求里
多数团队的 SRS 只写系统该做什么，不写系统被什么框住。模板恰恰用了整整两大章（指定、标准）来讲约束。原因很实在：任何限制设计灵活性的因素，如果不提前写进需求，就会在实现阶段变成不可谈判的既成事实，那时候再谈成本要高一个数量级。
3.1 预选应用程序包：一个“指定”如何反向锁死设计决策
模板把“使用特定应用程序包”列为非常重要的一类指定，并逐项列出包可能强制的构件和决策：工作站类型、连接方法、处理器和 DASD 类型、系统控制程序、数据组织与存放管理、编程语言、批接口、进程和数据关系、业务逻辑、屏幕设计和最终用户界面、性能和可用性特征、打印构架（如 PostScript、PCL 这类首选打印数据格式）、国家语言支持。这段清单的价值在于它把“选了个包”这件事的真实代价摊开了——包越固定、定制空间越小，上述每一项就越是硬约束。
模板还补了两条容易被忽略的判断。其一，影响任何指定程序包的因素也会影响你的设计，所以有了“指定”包就必须确保能获得对应技能与知识，来源可能是包厂商、外部顾问或经过专门培训的设计团队成员，并且不能假设这些知识很容易获得，要确认在需要时真的能拿到。其二，某些应用程序包本身就可形成构架定义——这条尤其关键，它意味着“选包”这个动作可能在没人注意的时候已经完成了架构决策。
3.2 现有环境即约束：硬件、数据、网络构架怎么变成需求条目
特殊硬件和现有数据这两节写得很细，细到能直接当检查表用。特殊硬件要记录：任何硬件或软件先决条件、厂商及其支持组织、国家语言考虑事项、加密设备。现有数据要记录：数据当前位于什么系统上、结构（关系型文件还是平面文件）、大小、目前哪些用户和系统在使用、可用性考虑事项（例如因数据库维护或批处理活动导致数据不可用的时间段）、这些数据是否可以移动或复制。
“标准”章的落点则在组织级约束。技术构架大致等同于企业技术平台与企业技术基础设施，其中可能已定义：计算中心的数量和用途、企业网络连接性（WAN）、某些设施的局部连接性（LAN）、客户机/服务器基础设施服务（中间件）覆盖范围、目录及命名服务、安全服务与权限级别、跨网络的时间服务、协调资源恢复活动的事务管理服务、将用于新应用程序的开发方法、已接受的可支持产品集（硬件、系统控制软件、常用应用、帮助台使用、安全规则）、打印子系统构架。模板提醒这份列表可能被严格实施也可能根本不执行，所以要记录的是“明确要求使用或排除某些子构架”的需求，并记录客户所需的开放程度，即厂商独立性和互操作性。
网络构架与连接策略两节更像是在收集“不可见的物理事实”。网络构架是一组公用的高层连接性规则外加公用传输基础设施，可能包括主干网络（集线器和线路）的定义；要了解基本规则和拓扑，记录物理拓扑考虑（网络基本位于农村还是大城市、网络附属装置是密集分布还是松散分布）、当前基础设施支持哪些高层连接功能、使用哪些通信标准、支持哪些编程接口，以及对客户机/服务器层或基本系统模型层之间连接性的定义——例如表示逻辑必须始终在工作站中而数据访问逻辑必须始终在集中式主机系统中。连接策略则要记录特殊协议或通信设备的强制要求、是否隐含要求特定协议以支持现有设备或软件、是否使用现有物理连接设备，若不使用则要记录约束来源（政策、法规、物质空间、房产所有权、第三方参与），以及移动用户的支持情况。
把这几节连起来看，机制就清楚了：它们收集的不是“需求”，而是设计自由度的边界。边界一旦缺失，设计阶段就会反复出现“方案做到一半才发现不能用”的情况，而这类返工的代价远高于在需求阶段多问几十个问题。
4. 可验证性工程：数量与可用性怎么从形容词变成判据
这两章是整份模板里最不像“需求文档”、却最有工程价值的部分。它们处理的共同问题是：性能和可用性一旦写成形容词就彻底失去约束力，必须转成可测量、可判定的表述。
4.1 从业务流程到评测单元：数量指标为什么必须先对齐术语
模板给的第一步不是“填数字”，而是跟应用开发人员合作把业务流程细分为更小的单元，比如更小的业务流程或事务，理由是下一步要记录数量，必须先确定计数对象。它还提醒一个业务流程可能启动几个更小业务事务的实例（例如各个客户订单中的多项订购商品），记录数量时要记住这些乘数，但不必过分深究细节，复杂系统尤其如此。
术语冲突这段写得非常真实：一个业务流程（如客户订单处理）通常由一个“应用程序”实施，也可能由多个应用程序实施；每个应用程序里通常有很多 IT“事务”，比如“查询库存水平”或“生成客户信函”；不同人群用各自名称标识同一单元——“事务”对应用开发背景的人和基础设施团队可能完全是两个意思。所以必须通过协作让名称相互关联，然后再收集信息。这是典型的血泪经验：数量指标算错，十有八九不是数字填错，而是大家数的根本不是同一个东西。
数量与大小的记录项包括：预计一般时间和高峰期各有多少用户使用各业务流程或应用程序、高峰期按每天每周每月如何界定、高峰期和一般时间各需要什么处理速度、每个数据组中数据元素和实例的数量及大小。性能标准则要记录：各类别的响应/周转需求、在哪里评测、不同时间（如非高峰夜间）是否可接受不同标准、恢复或应急期间是否可达标、是否需要性能保证、未达标对所有各方的影响、业务流程被认为可用的最低性能条件（在该点以下系统被认为是“不可用”而不是“缓慢”）。最后一条是整节的技术核心——“不可用”与“缓慢”的界线一旦不定义，后续所有可用性讨论都没有共同语言。
4.2 可用性五步法与缩减功能：恢复策略为什么要写进需求
模板给出的可用性确定方法分四步：确定系统的真实最终用户、他们执行的业务流程以及执行时间；分析服务可用性或不可用性将如何影响最终用户完成业务目标的能力；指定适当的可用性需求，直接反映最终用户为完成业务目标而具有的需求；并注意已选应用程序包的结构和设计可能严重影响最终用户看到的可用性特征——未被设计来进行连续操作的包，可能很难进行连续操作，尤其在维护和批窗口方面。
其中最有价值的机制是“缩小间隔”。模板反对给整个系统定一个全局可用性需求，主张按流程、用户组、数据组分别指定，这样设计人员才有灵活度。它给了一个可直接对照的例子：语句“系统必须每天 24 小时为纽约和香港的用户提供服务”给设计人员的设计灵活性，就不如“从纽约时间上午 7 点到下午 7 点，纽约用户必须能够对他们的数据执行事务处理；从香港时间上午 7 点到下午 7 点，香港用户必须能够对他们的数据执行事务处理”。后一种写法下，即使一个时区仍处于工作日，设计人员也能对另一个时区的数据或系统构件做维护。模板还强调要区分“希望”和“强制”，并给了 ATM 的表述范式：必须能 24 小时接受存款和取现；希望 24 小时提供准确余额信息，但查询可有偶尔中断，中断须少于 10 分钟且只能发生在上午 3:00 到 4:00 之间。
“服务中断成本”一节则把可用性锚在业务影响上，要求按不同中断时长（1 分钟、数分钟、15 分钟、30 分钟、1 小时、2 小时、4 小时等）和长时中断（一次换班、一天、许多天）分别评估，并尽量从财务上量化，包括生产效率降低、失去当前业务的价值损失、客户不满意导致的未来业务损失、利息开支、法规性处罚。紧接着是“缩减功能”这个非常实用的设计：完整功能读取和更新股票记录，缩减功能是先输入更新数据并排队等待以后更新；完整功能读取最新客户余额，缩减功能是从可能不很新的备选来源读取；完整功能更新计算机日记，缩减功能是更新日记的硬拷贝。并且缩减要有边界，例如过时的客户余额信息过时时间不得超过 24 小时。
注意：缩减功能不是降级运行的托词，它必须带可接受边界（过时多久、丢失哪些操作），否则在恢复阶段会演变成数据不一致。
可用性和恢复标准要写成可判定的形式：在给定分钟/秒数内被恢复的中断所占百分比；在给定周/月/年内用户无法执行特定功能的最大时间长度。并要区分计划内与计划外中断、发生时段（关键时段还是低使用率时段）、受影响用户范围。模板还给了两条很实用的反向约束：不要指定不太紧迫的可用性标准，因为会显著影响实施成本；如果在一组给定中断条件下无法确定重要业务/财务成本或风险，可能表明不应把这些中断条件写进标准。若使用加密系统，还要考虑恢复可能保存在系统外的机密信息，并确保加密保护数据的恢复与相应加密密钥的恢复相互协调。
灾难恢复则要逐项问清：服务必须在多长时间内恢复、恢复时间从灾难发生时算起还是从决定前往远处工作地点时算起、组织在什么条件下决定异地恢复、异地数据必须处于怎样的更新状态（必须时刻最新、故障后几分钟内更新、可接受前一天数据）、首次异地恢复服务是什么时候、相对依赖相同计算设备的其他业务应用该组应用具有何种远程恢复优先级。最后一节还列了设计人员会关心的灵活性问句：维护期间能否只查询不更新、能否接受更新请求但延后到维护完成再写库；数据恢复时是优先尽快恢复服务（哪怕用非最新数据），还是优先把数据恢复到当前状态（哪怕更慢）；故障时“正在处理中”的请求，用户是否一定会在服务恢复后重新输入；是否存在非技术性事项影响可用性（如业务策略规定流程 B 不可用时流程 A 也不可用）。
这几组问题合起来构成一个清晰的机制：可用性需求的本质是把业务损失函数翻译成设计可选项。翻译得越具体，设计人员越有空间用低成本手段满足真实目标；翻译得越笼统，最后只能靠堆硬件兜底。
4.3 安全性需求的两条分类轴：对象与侵害场景如何配对
安全性这章的方法论很干净：先按逻辑或物理安全性列出需要保护的对象，再确定与各对象相关的侵害场景，典型三类是查看访问（违反保密性，如账户信息、客户列表、专利）、更新访问（如为欺骗、掩饰和资金转移而修改数据）、资产丢失（所有权被他人获得从而对拥有者不再可用，如客户和前景列表、合同）。模板明确提醒，并非所有对象对上述所有场景都敏感。
威胁来源要结合环境确定，例如心怀不满的雇员、未经授权的雇员、在公有场合进行公开的终端会话、黑客、电话窃听、设备丢失（如便携式 PC）。然后逐对象判断可能受到哪种威胁并关联到具体威胁场景，同时要检查对象在静态位置（如硬盘上）和移动中（如传输期间）的安全性需求——由于设计可能把对象所处位置扩展到不安全区域，这个检查需要重做。特别要确定的需求集中在：对系统的访问、对数据的加密、可审核性。物理安全威胁则包括偷窃构件、未经授权的物理访问、用户的人身安全。
模板还给了一条判断“什么时候该请专家”的边界：某些系统设计在安全性方面可能有非常苛刻的要求，会支配设计决定，可能使其他情况下很合适的结构和构件变得不可接受；如果认为自己有特殊安全性要求，就应该找安全专家或从业者协助系统安全性设计。对已指定的应用程序包，则要了解它自带的安全性子系统功能。这条边界意识很重要——安全需求不是靠需求文档写全的，文档的职责是识别出“这里必须请专业介入”。
5. 避坑与排查：SRS 落地时最常见的五个翻车点
5.1 把 SRS 当成一次性交付物
现象：评审通过、归档、后续变更只落在邮件和聊天记录里，半年后文档与系统完全对不上。原因：把 SRS 理解成“文档”而非“包”，没有把它当作需要维护状态的活工件。解决：按包管理需求条目，每条需求有唯一标识、来源和状态；变更必须回到 SRS 中登记，而不是在实现侧默默生效。模板那句“如果不是 SRS 包中的内容，开发人员就不应处理它”反过来也成立：处理了就必须回写。
5.2 假设与问题清单缺失，导致风险和未知混在需求里
现象：需求评审时所有人对某些点心照不宣，实现阶段各按各的理解做，集成时才发现分歧。原因：没有维护“假设与问题”两个列表。模板的要求很具体：记录需求与设计流程中作出的所有假设及其基本原理或思维过程；记录可能用来确定此项目之外或之后的相关子项目或工作项的假设；记录所有可能中断项目进行的主要问题；并在每个阶段结束时与客户一起复审这些问题，假设也要复审，但对不太重要的假设，客户可能并不是合适的复审人选。解决：把这两个列表作为 SRS 的常驻附件，阶段末强制复审。
5.3 数量指标术语没对齐，容量规划全盘偏移
现象：容量评估结论与上线后实际负载差一个数量级，或者性能测试压的根本不是生产里那个“事务”。原因：如 4.1 所述，业务流程、应用程序、IT 事务三个层级被混用，不同团队用同一词语指代不同单元，且忽略了“一个流程启动多个事务实例”的乘数。解决：在填数字之前先做术语对齐，明确每个评测单元的定义、边界和乘数关系，宁可多花半天开会，也别在错误的单元上算容量。
5.4 可用性写成全局口号，成本失控却没人能说清为什么
现象：需求里一句“系统需 7×24 高可用”，设计阶段只能靠冗余堆料，预算超支也无法论证必要性。原因：没有按流程、用户组、数据组缩小间隔，没有区分希望与强制，没有把服务中断成本量化到财务口径，也没有定义“不可用”与“缓慢”的分界。解决：按 4.2 的方法逐流程写可用窗口和恢复标准，用中断时长分档评估业务影响，并把缩减功能方案一并写入需求。
5.5 指定包的知识可得性没验证
现象：项目中期才发现团队里没人真正懂那个被指定的应用程序包，定制能力、性能特征、安全子系统全靠猜。原因：把“指定包”当成一条普通需求记录，没同步评估技能获取路径。解决：在需求阶段就确认知识来源（厂商、外部顾问、受训成员），并落实“在需要时能获得”；同时索取该包的性能特征与安全功能资料——模板提醒这类数字由第三方提供可能要花时间，现在就该提出要求。
6. 设计取舍：为什么这份模板宁可啰嗦也不肯抽象
把整份模板通读一遍会发现一个明显的取向：它几乎拒绝一切漂亮的抽象，转而用大量具体问句把需求往现实里拽。地理组织要记到“四处旅行并使用工作站的销售部门”和需要自然语言支持的所有地理位置；连接策略要记到电缆归属和第三方承包；可用性要记到“警察和消防部门的人员派遣系统不可用时，手工应急仍能响应但响应时间会增加”这种颗粒度。这种写法在审美上不讨喜，但它服务的是一条很硬的工程逻辑：需求文档的价值不在于表达优雅，而在于消除歧义与遗漏，而歧义和遗漏恰恰藏在具体情境里。抽象层次越高，读者越容易各自脑补，而脑补的差异要到集成和验收时才暴露，那时修改成本最高。
代价也是真实的。这份模板对编写者的领域知识要求很高——要能问出“现有工作量是否一定要求在每天晚上关闭整个处理器”“现有平台和工作量特征是否将影响新系统”这种问题，得先懂运行环境；要能判断哪些中断条件值得写进可用性标准，得先能量化业务损失。它也没有给出裁剪指南，照单全收会写出远超项目需要的文档量。我在实际使用时通常会做一次取舍：约束类章节（指定、标准、现有数据、特殊硬件）几乎不裁剪，因为漏一条就是设计返工；数量与可用性按项目风险分级，只对有明确业务损失的部分做完整量化；安全性则先做对象与场景的粗配对，再决定是否需要引入专门角色。验证方式也很朴素——把 SRS 交给一个没参加需求讨论的开发和一个测试，让他们各自独立说出“这条需求怎么算做完了”，两边答案一致才算过关。
提示：判断一条需求是否合格，可以用一个低成本测试：它能不能被写成一条测试用例，且该用例的通过与否不依赖解释。
从那以后我每次接手需求工件，都会强制走一遍“对象—场景—判据”的检查：这条需求保护或约束的对象是什么，在什么场景下会失效，失效与否怎么判定。走不通的条目，不是需求写得不清楚，就是它本来就不该出现在 SRS 里。这套来自 IBM 体系的需求规约模板与案例，价值也正在这里——它不是让你照抄目录，而是把那些必须回答的问题摆在你面前，逼你在还来得及的时候回答。希望帮到你。
本文还有配套的精品资源，点击获取
