从需求规约模板到验收对照表：SRS信息包与需求追踪实践

简介围绕IBM软件需求规约SRS格式模板要求整理的案例文档面向需求分析人员、项目经理、开发与测试/QA团队成员也可供软件工程课程学习者参考。内容以SRS指南为主线覆盖概述中的假设与问题、地理组织指定部分的预选应用程序包、特殊硬件与现有数据标准部分的技术架构、网络架构与连接策略以及数量、可用性和安全性等章节同时说明功能性需求与非功能性需求的记录方式并阐释SRS作为交流基础、项目参考标准和测试输入的作用。压缩包共1个doc文件约150KB篇幅精简便于快速查阅模板结构与章节要点。已有277人学习适合在撰写需求规格说明、评审需求完整性或搭建项目文档框架时对照使用。文档对“从前景到SRS”的过渡、活动工件定位、项目成员参考标准等也有提示便于理解需求收集与组织思路。1. 接手一个跨部门调度系统的第二周我被要求补一份需求规约代码已经写了一部分接口说明散在三个共享目录里测试同事问「验收标准在哪一页」会议室安静了半分钟。后来翻出一份老模板——某老牌 IT 厂商随统一过程方法论一起发布的需求规约案例六大部分从「假设与问题」一路排到「安全性需求」中间夹着指定、标准、数量、可用性。它不教你怎么写代码也不附带任何工具价值在于把「一份能被人拿去对质的需求文档该有哪些格子」列清楚了。下面按这份模板的骨架讲每一格填什么、哪些格子放到今天必须改口径、以及我在真实项目里翻过的几次车。2. 先定工件形态SRS 是「包」不是大卷文档2.1 文档还是包这个争论决定了模板怎么落地模板里专门花了一节讨论「软件需求规约到底是文档还是包」结论挺反直觉不必纠结工具之间的差异重点应放在有效收集和组织需求上所以假定 SRS 中的需求集合构成一个信息包各种系统需求的详细说明都归到这个包名下。这个结论一旦接受落地方式就完全变了。包意味着它是一组内容的集合而不是把所有文字塞进一个 Word 文件。功能性需求可能躺在用例模型里非功能性需求和设计约束可能躺在补充规约里还有一部分是客户在会议纪要里口头给的硬约束。SRS 包要做的是给这些散落的东西一个统一入口而不是再抄一遍。我一般会把它做成「索引 决策 引用路径」三层。索引层是六大部分的一级目录决策层只放那些必须拍板的事比如「本项目采用指定的应用程序包其屏幕设计与业务逻辑不再自定义」引用路径层写清每条需求真正存在哪个工件的哪个编号下。这样一份 SRS 主文件通常控制在二十页以内改起来不心疼也没人会在两个地方维护同一句话。提示如果你的团队已经用需求管理工具SRS 更要瘦。工具负责存条目SRS 负责讲清「为什么这么组织」两者的职责别混。2.2 从前景文档到 SRS交接点在哪模板里这句话说得极准前景文档和 SRS 服务于不同的需要通常由不同的作者编写。到了 SRS 这个阶段项目重点已经从「用户需要什么、目的和目标是什么、目标市场和系统特性是什么」转移到「解决方案里怎么实施这些特性」。判断一句话该落在哪边我有个很土但好用的办法看主语和语气。出现「用户希望」「市场需要」「我们要进入某类业务」的还在前景文档出现「系统必须」「系统将」「在 X 条件下系统应」的才进 SRS。前者是意图后者是行为承诺。操作上分三步走。第一步把前景文档里的每条特性编号形成一张特性清单第二步对每条特性追问「为了交付它系统必须执行哪些操作」答案写成用例或行为条款第三步反问一遍「这条操作如果没人要求是不是可以不实现」答不上来的条款基本是设计不是需求挪到设计文档去。第三步最能砍掉注水内容也是我见过最容易被跳过的一步。2.3 三类读者的三种读法模板给 SRS 定了三个使用场景每个场景对应一种读法落地时最好在文档开头就写明省得后面扯皮。项目经理拿它当讨论基准。项目经理不太可能有时间精力去读开发写的代码再跟前景文档比对所以讨论范围必须收敛到 SRS 里写了什么。这意味着 SRS 里不该出现「详见某次口头讨论」这种指向。开发人员拿它当契约。模板的原话很硬不在 SRS 包里的开发人员就不应处理在 SRS 包里的开发人员就有责任交付。这句话反过来对需求方也是约束——想加功能先改 SRS。测试与 QA 拿它当测试用例和 QA 过程的输入。这个视角最容易被忽略但恰恰是最有效的校验如果一条需求写不出对应的验证方式那它大概率不是需求是愿望。我的做法是在每条需求后面留一列「验证方式」只允许填演示、测试、审查、分析四种。填不出来的当场打回重写比等到验收阶段吵架便宜得多。2.4 六个部分的排序逻辑模板的六大部分是概述、指定、标准、数量、可用性、安全性。乍看有点乱其实顺序有讲究先声明不确定再锁死约束然后量化最后才是质量属性。概述里的「假设与问题」排在最前是因为后面所有内容都可能被它推翻。有些问题拿不到满意答案可能是缺信息也可能是答案会危及设计可行性所以模板要求维护两份列表所有做过的假设及推理过程以及所有可能中断项目的主要问题并且每个阶段结束时和客户一起复审。「指定」和「标准」排在数量之前因为约束会改变量化口径。举个例子如果指定了某个封装应用包那它的结构和设计已经决定了最终用户看到的可用性特征你后面写可用性需求时就得围着它转而不是凭空定一个 99.99%。顺序调换的代价我在一个项目里真实付过先把性能指标定死再发现必须沿用客户已有的系统管理惯例结果每晚固定的批处理窗口把高峰时段切掉两小时性能条款全部重谈。从那以后我排目录约束一律前置。3. 指定与标准把设计自由度提前钉死3.1 预选应用程序包会连带锁死哪些技术决策模板里有个词很到位——「指定」。需求里一旦写了要用某个应用程序包你其实是在做一批系统设计决策只是很多人没意识到数量有多大。按模板列的清单一个包可能连带要求工作站类型、连接方法、处理器与直接存取存储设备类型、系统控制程序、数据的组织存放与管理方式、编程语言、批处理接口、进程与数据关系、业务逻辑、屏幕设计与最终用户界面、性能与可用性特征、打印架构与首选打印数据格式、国家语言支持。这些里面只要有四五项和你的原设计不一致架构就得推倒重来。所以填这一格时我的写法是两列对照左列写「包强制要求」右列写「本项目原本计划」逐项标注「接受 / 需改造 / 不可接受」。第三列出现任何一项「不可接受」就该在 SRS 里明确写排除理由而不是留到设计阶段再吵。还有一条模板提醒得很实在不要认为关于这个包的知识很容易获得要确保在需要时能拿到。技能来源无非三条——包的原厂商、外部顾问、经过专门培训的设计团队成员。SRS 里应该点名由谁提供以及提供不了的降级方案是什么。我见过最惨的情况是项目中期才发现团队里没人真正懂那个包的数据组织方式硬啃了六周。3.2 特殊硬件与现有数据的登记表这两格看着简单漏填率极高。硬件那格模板要求「尽量记录」落到实操我整理成下面这张表一个设备一行缺一列就是隐患。字段填什么漏填的后果设备名称与型号范围用一般性术语还是精确型号明确写采购阶段被换成低配型号性能不达标软硬件先决条件驱动、固件、系统补丁的最低版本联调时才发现系统版本不匹配厂商与支持组织谁负责故障响应响应时限出问题互相推诿无人兜底国家语言支持是否涉及多语言字符集与输入法上线后界面乱码或录入不可用加密设备是否要求专用加密硬件及其接口安全合规过不了返工改架构连接方式接口类型、线缆、转接设备现场安装发现物理接口对不上现有数据那格模板要求记录六项数据当前在哪个系统上、现有结构是关系型文件还是平面文件、数据量大小、当前哪些用户和系统在用、可用性方面的限制比如数据库维护或批处理导致数据不可用的时间段、以及这些数据能不能移动或复制。最后一项最容易被当成技术细节跳过但它直接决定迁移方案是「同步复制」还是「一次性导入」。不能移动的数据你的新系统只能做读取封装能复制的数据才有双写和切换的余地。这个结论要在 SRS 里写死别留给实施阶段自由发挥。3.3 技术架构、网络架构、连接策略三者的边界这三格经常被写成同一段话其实是三个层次判据可以用一句话概括架构讲「是什么」策略讲「允许怎么连」。技术架构大致等同于企业技术平台、企业技术基础设施里面通常已经定义了计算中心的数量和用途、企业级广域网连接性、某些场所的局域网连接性、客户机/服务器基础设施服务也就是中间件的覆盖范围、跟踪网络资源与属性的目录及命名服务、防止未注册用户非法使用网络资源的安全服务及权限级别、校准全网时间的时间服务、协调多系统资源恢复的事务管理服务、将用于新应用的开发方法、已接受的可支持产品集、打印子系统架构。网络架构是一组公用的高层连接规则外加公用传输基础设施可能包括主干网的定义。要记录的是物理拓扑特征网络节点是密集分布还是松散分布、当前基础设施支持哪些高层连接功能、用哪些通信标准支撑这些功能、支持哪些编程接口以及有没有对客户机/服务器分层之间的连接方式做硬性规定——比如表示逻辑必须始终在工作站、数据访问逻辑必须始终在集中式主机。连接策略则是更具体的约束是否强制使用某种协议或通信设备是否隐含要求用特定协议来支持现有设备或软件是否复用现有物理连接设备线缆、网络或外围控制器、常用载体如果不用是出于什么限制管理政策、物理空间、产权归属、第三方参与需要第三方施工时由谁承包、职责怎么划以及是否要支持移动用户。填这三格时我坚持一个习惯技术架构只摘录「会影响本系统设计」的条目不要整篇复制企业架构文档。模板里那句提醒很关键——架构文档里的规则可能被严格执行也可能根本没人执行所以每条摘录后面加一列「执行强度强制 / 建议 / 历史遗留」否则后面设计评审会被一堆过期条款绑住手脚。3.4 隐含策略最容易漏的一类约束模板专门问了句「客户是否有任何其他策略、标准或规则没有在需求中明确声明」这一问救过我好几次。典型的隐含策略有这几类最终用户的所有新系统接口必须按面向对象原则设计并支持拖放操作所有新系统必须基于客户机/服务器应用模型所有新系统必须按公开标准定义国家语言支持的标准和政策尤其涉及从右向左文本操作时定义用户身份验证、访问控制和数据保护的管理职责与标准的安全策略以及可能需要特殊连接或安全设备的应用间数据交换标准。还有一类最隐蔽用户或部门能不能在工作站和服务器上自行添加或开发本地程序。模板对这个问题的描述相当不客气——如果不加控制本地程序会很快耗尽原本为生产系统采购的资源等到首次公开展示生产系统时你才发现装不上去。对策不是写一句「禁止安装」而是在 SRS 里定义配额与审批路径工作站允许占用多少本地资源、服务器磁盘空间由谁审批、违规安装如何回退。把它当需求写才有执行依据写在运维手册里通常没人看。打包应用方案还会引入隐含标准——包本身就在形成架构定义。所以每次引入指定的包我都会补一段「该包隐含约束清单」把它带来的标准、限制和默认行为列出来让评审的人有机会说「这条我们不接受」。4. 数量、可用性与安全性把形容词换成可验证的数字4.1 评测单元先对齐叫法再谈数量模板里这个提醒非常实战不同人群会用各自的名称来标识同一个单元。「事务」在应用开发背景的人听来是一个意思在基础设施团队听来是另一个意思。所以必须先协作对齐名称再收集信息。我的做法是画一条三层链路业务流程 → 应用程序 → IT 事务。业务流程是客户视角的比如订单处理应用程序是 IT 视角的落地单元一个业务流程可能由一个或多个应用实现IT 事务是最小计数单元比如查询库存水平、生成客户函件。还要处理乘数。一个业务流程可能启动多个更小事务实例比如一张客户订单里有多项订购商品记录数量时必须把这个乘数算进去。模板同时提醒不要过分深究细节复杂系统更不必——我一般控制在三层以内超过三层就说明这个系统的边界还没想清楚。术语对齐的产出是一张对照表三列业务方叫法、开发叫法、基础设施团队叫法右侧统一编号。这张表放在 SRS 概述后面后面所有数量、性能、可用性条款都引用统一编号。少了这张表性能条款就会变成玄学——你说的高峰和他理解的高峰可能不是同两个小时。4.2 业务量与峰值四个必填字段数量这一格模板给的字段不多但每个都不能糊弄。我整理成四个必填项缺一项就退回。字段具体要求备注并发用户数分别记录一般时段与高峰时段按业务流程或应用拆不要只写总数要写清分布峰值出现规律按日、周、月分别说明高峰发生在什么时间结算类系统常见月末峰值处理速度高峰与一般时段各需要什么事务处理速率单位统一为每秒事务数数据规模每个数据组的数据元素数量、实例数量及大小元素数和实例数分开记这四个字段填完容量规划的输入才算齐。填的时候有个细节要注意数据规模要写增长预期否则设计方按当前数据量做方案第二年就撑不住。模板没强制要求写增长率但既然要写「预计生命期内的变化」顺手补上更省事。4.3 可用性写成时间窗而不是「7×24」这是整份模板里我认为最值得抄的一段。模板明确建议以较小的间隔指定可用性需求比如按各个流程、用户组、数据组分别写而不要给整个系统一个「全局」需求。系统连续可用性要求越高这一点越重要。它给了个对照例子。写「系统必须每天 24 小时为两个不同时区的用户提供服务」给设计人员留下的灵活性远不如写成「东部时区用户在当地时间上午 7 点到下午 7 点必须能对自己的数据执行事务处理海外时区用户在当地时间上午 7 点到下午 7 点必须能对自己的数据执行事务处理」。后一种写法下即使一个时区还在工作时间内设计人员也能对另一个时区的数据或系统构件做维护。第二个例子更细某类自助终端应用在凌晨三点能执行存款和取款可能很重要而在那个时间点能不能准确提供账户余额信息可能不那么重要。于是条款可以写成——必须每天 24 小时接受存款和取现希望每天 24 小时提供准确的余额信息但余额查询过程中允许偶发中断中断时长必须少于 10 分钟且只能发生在凌晨 3 点到 4 点之间。这里有个关键动作区分「希望」和「强制」。模板还补了一刀——如果没达到某个可用性目标并不会直接影响用户完成业务目标的能力那这个目标可能就不该作为系统的可用性需求。另外间接反映可用性的需求比如「必须建立某类控制区域」通常不如直接反映可用性的需求比如「柜面人员必须能执行流程 X 和 Y」有用。我改条款时会强制问三句谁在什么时间用什么流程这个流程中断多久他能忍超过多久就算不可用而不是慢三句答不上来这条可用性需求就是拍脑袋。4.4 服务中断成本与缩减功能预案中断成本这一格模板的做法是按持续时间分档评估短暂中断或响应极慢的时段、1 分钟、数分钟、15 分钟、30 分钟、1 小时、2 小时、4 小时再到一次换班、一天、许多天。每一档都要评估对业务的影响并尽量从财务上量化——员工或设备生产效率降低的成本、失去当前业务的价值损失、因客户不满意而对未来业务造成的估计损失、利息开支、合规性处罚。量化不出来的部分也别硬编写「无法量化按最高优先级处理」比写个假数字更负责。模板还提醒要考虑与用户组不直接相关的流程比如夜间票据交换这类流程中断往往没人第一时间发现。更有价值的是它给的「缩减功能」思路与其追求全功能高可用不如定义系统在降级状态下还能保住什么。模板举了三个例子我按同样的结构改写成本项目常见形态完整功能缩减功能降级边界读取并更新记录只录入更新请求排队等维护结束后统一执行排队队列长度上限与超时丢弃规则要写明读取最新余额从备选来源读取可能不很新的余额数据陈旧度不得超过约定时长例如 24 小时更新电子日志更新纸质日志事后补录补录责任人与补录时限降级边界这一列是灵魂。没有边界降级就变成了「随便凑合」事后无法判断系统到底算不算可用。4.5 安全性需求的对象—威胁矩阵模板给的方法论很干脆按逻辑或物理安全性列出需要保护的对象再确定与各对象相关的侵害场景最后把威胁和场景关联起来。对象侧的侵害场景分三类查看访问也就是违反保密性比如账户信息、客户列表、专利更新访问比如为进行欺骗、掩饰和资金转移而修改数据资产丢失比如所有权被他人获得从而对拥有者不再可用这与灾难造成的丢失是两回事典型对象是客户和潜在客户列表、合同。威胁来源要按环境列全数据中心工作人员、其他 IT 工作人员如开发人员、组织中的非 IT 工作人员、组织外人员。威胁类型包括意外损坏或破坏、故意的损坏或破坏、商业间谍行为、欺骗、未授权访问行为、病毒。物理安全威胁单列构件被窃、未授权物理访问、用户人身安全。落到表格就是一张对象 × 威胁的矩阵受保护对象查看访问更新访问资产丢失物理威胁特殊安全需求客户主数据高高中低访问控制、可审核性交易流水中高低低加密传输、审计日志合同附件高中高中加密存储、权限分级终端设备低低高高物理锁具、丢失远程擦除还要注意两个容易漏的点。一是同一对象在静态位置硬盘上和移动中传输期间的安全需求可能不同设计如果把对象扩展到不安全区域需要重查一遍。二是某些封装应用方案自带安全子系统如果你有指定包就得先搞清它的安全功能再决定哪些需求交给它、哪些自己补。模板对特殊安全要求的判断也很直接敏感系统、大额资金流转系统、处理个人机密信息的系统一旦确认属于这类就该找安全专家参与设计别自己硬扛。5. 五个翻车点从「填了」到「能验收」差在哪5.1 结构层面的三处翻车第一处把包当文档。现象是 SRS 长到七八十页用例模型里存一份、补充规约里存一份、SRS 里又抄一份改一次需求版本就分叉评审时三个人手上三份不一样的文档。原因是没接受「SRS 是信息包」这个前提把汇总理解成了复制。解决办法是把 SRS 瘦成索引加决策功能性需求只写用例编号和一句行为摘要非功能性需求只写补充规约条目号正文一律不重复改需求只改源头一处。第二处假设与问题列表建了但没人复审。现象是项目中期突然发现某条启动会上的假设早就错了比如「现有平台能承载新峰值」而这条假设一直挂在文档第 3 页没人碰。原因是模板要求的「每个阶段结束时与客户一起复审」没落到流程里只在启动会看了一眼。解决办法是把它做成带责任人和复审节点的表阶段评审第一项议程就是过这张表每条假设必须标注「仍成立 / 已失效 / 需重新验证」失效的当场转成问题项。第三处地理组织只写了总部。现象是上线前才发现有两个移动办公部门要用工作站接入还有一个地点需要额外的语言支持界面字符集返工。原因在于把「地理位置」理解成了机房位置。解决办法是照模板的四类扫一遍受系统影响的业务部门所在地、未受影响但装有主要 IT 设备的工作地点、所有移动工作部门、所有可能需要特殊语言支持的地点。四类各出一份清单缺哪类都要写明「本项目不涉及」并给出理由。5.2 条款层面的两处翻车第四处可用性写成「系统必须 7×24 可用」。现象是设计方按最高冗余报价成本翻倍还压不下来商务谈判卡了两周。原因是全局需求没有按时段、用户组、数据组拆开设计方只能按最严口径响应。解决办法是改成按用户组和时间窗分别表述并对每条标注强制或希望同时补一句「非强制项未达成时不构成验收不通过」。改完之后冗余方案降了一档成本回到可谈区间。第五处性能标准写了「响应要快」。现象是验收时甲乙双方各执一词甲方说三秒乙方说五秒也算快。原因是模板要求的那几个字段全缺在哪儿评测、不同时段是否可接受不同标准、恢复或应急期间能否放宽、是否需要性能保证、未达标对各方的影响、以及业务流程被认为可用的最低性能线。解决办法是每条性能条款补四个字段——指标值与单位、评测点与测量方法、时段差异说明、降级阈值。其中降级阈值最有用它明确划出「低于这条线系统算不可用而不是慢」避免把性能问题拖成可用性问题。注意第五条里「是否需要性能保证」这一项很多团队直接跳过。它其实是商务问题而不是技术问题早写清楚比验收时补合同便宜。5.3 发布前过一遍的六项检查我把上面这些坑压缩成一张自查表SRS 定稿评审前逐项打勾一项不过就不发版。检查项通过标准每条需求有唯一编号功能性、非功能性、约束三类各自前缀全局不重号每条需求可追溯到来源能指向前景特性、用例或客户书面指定每条需求有验证方式演示、测试、审查、分析四选一不允许留空假设与问题有责任人和复审节点每条至少一个名字和一个阶段节点可用性按时段与用户组拆分不存在全系统级「7×24」表述指定与标准类约束标注执行强度强制、建议、历史遗留三档明确这张表不解决需求写得好不好的问题它只保证文档不会因为结构性缺失而在验收阶段返工。6. 把 SRS 变成验收对照表一个可复用的追踪技巧模板反复强调 SRS 是测试与 QA 的输入但没说怎么落。我后来固定用一个做法给每条需求一个稳定编号然后在 SRS 主表里只保留六列——编号、条款摘要、类型、来源、验证方式、验收阶段。编号规则很简单功能性用 F 前缀非功能性用 N约束用 C后面跟三位序号。稳定是关键条款文字可以改编号不改这样版本对比时一眼能看出改的是措辞还是范围。来源列必须能指回去指不回去的条目说明它是设计而不是需求当场挪走。真正起作用的是双向追踪。正向从需求出发每条需求至少对应一个用例和一个测试用例反向从测试用例出发任何一个测试用例如果找不到需求编号那它就是范围外功能要么砍掉要么补需求。这张表我一般这么填编号条款摘要类型来源验证方式验收阶段F-012调度单提交后 2 秒内返回受理结果功能用例 UC-04测试系统测试N-007月末高峰时段每秒处理不少于 40 笔事务非功能客户书面指定测试性能测试N-011海外时区用户当地时间 7:00-19:00 可执行事务处理非功能前景特性 P-09演示验收测试C-003沿用现有目录与命名服务不自建约束技术架构摘录审查设计评审这张表还有个副作用挺香变更影响分析。客户提一个新需求先看它落在哪个编号段再看这个编号被哪些用例和测试用例引用影响面一次算清。以前靠翻文档一改就漏现在改一行diff 里只有那一行。有个细节值得单独说可用性条款的验收阶段我从不填「系统测试」一律填「演示」或「验收测试」。因为可用性是用户感知出来的实验室里跑指标跑不出真实结论。中断成本那几档也一样得让业务方在场看着系统降级运行确认缩减功能预案真的能撑住关键流程。从那以后我每次开新项目第一件事不是画架构图而是把「假设与问题」那张表拉出来先写三条最可能翻车的假设再给每条配一个复审节点和责任人。这份老模板里最耐用的不是它的六层目录而是这个习惯——先承认自己不知道什么再谈系统该做什么。希望帮到你。本文还有配套的精品资源点击获取