简介IBM软件需求规约SRS格式要求与案例文档面向需求分析人员、项目经理以及开发、测试和QA成员帮助解决SRS结构不统一、需求收集与组织缺乏依据的问题。文档为1个doc文件资源包约150KB内容以IBM提供的SRS指南为线索依次说明概述、指定、标准、数量、可用性、安全性等章节的编写要点并涉及假设与问题列表、地理组织、预选应用程序包、技术架构与网络架构、评测单元与业务量、服务时间及灾难恢复等具体条目。其价值在于把功能性需求与非功能性需求的记录方式、SRS作为项目交流基础和测试QA输入的作用讲清楚可作为编写需求规约、评审需求完整性和建立团队参考标准的模板材料。目前已有277人学习下载适合需要规范需求文档结构、补齐SRS条目和对照案例自查的读者参考。1. 一份 2001 年就定型的 SRS 模板现在填起来照样容易出错上个月帮一个团队看需求规约文档 60 多页验收前两周测试拿着它问“这条怎么验”翻到可用性那节只有一句话系统应保证 7×24 小时可用。开发说这做不到测试说这没法测项目经理说当初评审都签过字了。问题不是没写需求规约而是写了一堆没法验收的句子。这份源自某大型软件工程方法论体系的 SRS 模板价值恰恰在这里它把需求规约拆成概述、指定、标准、数量、可用性、安全性六段每一段都指向一个能落地、能追问、能验收的落点。适合正在写 SRS 的 BA、要接需求做设计的架构师以及被要求“把需求文档规范一下”的技术负责人。2. 六段骨架先立住概述段和指定段怎么填才不是抄模板先给结论这份模板的六段骨架不能当作“目录”来抄而应当看成一串追问清单。概述段问的是“边界在哪”指定段问的是“哪些设计自由度已经被提前锁死”标准段问的是“必须服从谁的规则”数量段问的是“按什么单位数、数多大”可用性段问的是“停多久算事故”安全性段问的是“保护什么、防谁”。下面两节先把概述和指定段拆开。2.1 先定一件事SRS 是文档还是信息包模板里有一段容易被跳过的判断不必纠结工具差异SRS 里的需求集合构成一个信息包。这句话的实操含义是一份 SRS 可以是多个工件的集合可以按承载方式拆分功能性需求放用例模型非功能性需求和设计约束放补充规约前景文档作为上游输入。真正要保证的是一致性和可追溯而不是排版统一。我一般会先定一张工件对照表让团队知道每类需求该去哪写、谁维护、在哪个评审节点冻结工件承载内容维护人冻结节点前景文档用户需要、目标、目标市场、系统特性概述产品/BA立项评审后用例模型功能性需求、外部行为、场景BA需求基线评审前补充规约非功能性需求、设计约束、标准符合性架构师 BA需求基线评审前SRS 索引包上述工件的引用关系与条目编号BA每次变更后编号规则要在第一天定死否则三个月后没人能对上号。常见做法是用“域-类型-序号”三段式域对应模板六个部分类型区分功能、非功能、约束、度量。下面这段脚本用来做结构校验接在提交前跑一遍能挡掉大部分低级错误import re, csv, collections # 域OVW 概述 / SPC 指定 / STD 标准 / QTY 数量 / AVL 可用性 / SEC 安全性 # 类型FR 功能 / NFR 非功能 / CON 约束 / MET 度量 ID_PATTERN re.compile(r^SRS-(OVW|SPC|STD|QTY|AVL|SEC)-(FR|NFR|CON|MET)-(\d{3})$) REQUIRED [id, title, statement, source, acceptance, priority] def load(path): with open(path, newline, encodingutf-8) as f: return list(csv.DictReader(f)) def check(rows): errors, seen [], collections.Counter(r[id] for r in rows) for r in rows: rid r[id].strip() if not ID_PATTERN.match(rid): errors.append(f{rid}: 编号不符合 SRS-域-类型-序号) if seen[rid] 1: errors.append(f{rid}: 编号重复 {seen[rid]} 次) for k in REQUIRED: if not r.get(k, ).strip(): errors.append(f{rid}: 字段 {k} 为空) if len(r.get(statement, )) 20: errors.append(f{rid}: 需求陈述过短无法验收) return errors if __name__ __main__: rows load(srs_items.csv) errs check(rows) print(\n.join(errs) if errs else f{len(rows)} 条需求通过结构校验)脚本里三个参数值得调ID_PATTERN的域枚举要和你实际的章节划分对齐新增一节就加一个枚举值不要用“其他”兜底REQUIRED中的acceptance是验收方法缺了它这条需求就是不可测的比缺标题严重得多statement的长度阈值只是防止“系统应友好”这类空话混进来20 字符是下限不是标准真正的判据是能不能写出验收步骤。提示先跑校验脚本再进评审会。评审会上花二十分钟争论编号格式是最不划算的消耗。2.2 概述段的两张清单假设与问题、地理组织概述段里最容易被写成废话的是 1.1 和 1.2。模板说得很直接收集和验证非功能性需求时要维护一份“假设与问题”列表。为什么强调这个因为有些问题拿不到满意答案可能是缺信息也可能是答案会危及设计可行性。这两种情况处理方式完全不同但都必须留痕。两张清单的字段我一般固定成这样逼着填表的人写“依据”字段说明常见错误编号ASM-001 / ISS-001 分开编两类混编后续无法筛选内容一句话说清假设或问题写成一段议论依据为什么这么假设信息来源是什么只写结论不写推理影响范围影响哪些需求条目编号写“影响整个系统”是否阻塞问题类必填阻断/非阻断全部标非阻断复审节点与哪个阶段评审绑定写“后续再看”血泪经验是“依据”那一栏。半年前某项目做了个假设现有批处理窗口可以在新系统上线后压缩到 30 分钟。当时没人写清这个数字来自哪次沟通结果上线前运维说这个窗口是他们唯一的对账时间一分钟都不能动。假设本身没错错在没留推理链导致没人敢推翻它。1.2 地理组织也不是填个地址列表就完事。模板要求记录三类位置受系统影响的业务部门所在地、未受影响但安装有主要 IT 设备的工作地点、以及所有移动办公部门。第三类最常被漏比如需要带着工作站到处跑的现场销售。这些信息直接影响后面可用性段的分时段写法也影响多语言支持的范围界定——哪些地点需要本地语言界面、是否涉及从右向左的文本排版都要在这里先标出来。2.3 指定段四问包、其他指定、特殊硬件、现有数据指定段是整份 SRS 里“含金量”最高的一段因为它记录的是已经无法更改的设计决策。四项里最重要的是第一项是否指定使用某个应用程序包。一旦指定了包被锁死的东西比想象中多工作站类型、连接方式、处理器和存储类型、系统控制程序、数据组织与存放方式、编程语言、批处理接口、进程与数据关系、业务逻辑、屏幕设计与最终用户界面、性能和可用性特征、打印数据格式、多语言支持。这串清单的用法是逐项打勾勾上的就是设计自由度已经没了架构评审时不用再讨论。紧接着要追问的是技能来源。模板提醒得很实在不要认为这些知识很容易获得。包的知识可能来自厂商、外部顾问或经过专门培训的设计团队成员三条路各有代价——厂商响应有排期顾问贵且会走自培成员要占用项目工时。要在需求阶段就把“需要时能否拿到”写清楚而不是等到联调时才发现没人懂这个包的批接口。第二问是“其他指定”也就是任何会限制设计灵活性的既有条件现有处理器或操作系统镜像、现有工作站设备、现有网络、现有系统管理惯例以及某些强制模型比如要求设计里必须清楚体现表示逻辑、业务逻辑、数据访问逻辑三层并规定它们在哪一层交互。这里有一串必须对着问的问题新系统跑在现有平台上现有负载已经占了多少连接和处理容量现有负载用的是什么安全控件现有负载有什么可用性特征比如是不是每晚必须整体关机这些答案会直接改掉后面的容量结论和安全设计。第三问特殊硬件注意区分两种写法一般性描述系统必须支持高速平板绘图仪和具体型号系统将支持现有的某型号自助终端。后者约束强得多要同时记录硬件或软件先决条件、厂商及其支持组织、多语言考虑、加密设备。第四问现有数据要记录六件事数据当前在哪个系统、结构是关系型还是平面文件、数据量大小、目前哪些用户和系统在用、有没有因维护或批处理造成的不可用时段、以及能否迁移或复制。最后这条经常决定项目要不要做数据清洗子项。3. 标准与数量把架构约束和性能基线写成可测的数字标准段和数量段是 SRS 里最像“工程文档”的两节也是最容易被写成“参见相关规范”的两节。写成参见等于没写。这一章的目标是把它们变成可执行、可测量、可对照检查的内容。3.1 标准段的三层追问技术构架、网络构架、连接策略第一层是技术构架和 IT 战略计划。客户如果有这套东西几乎可以肯定你的设计必须与它保持一致。要读的规则包括计算中心的数量和用途、企业广域网连接性、某些场地的局域网连接性、中间件服务的覆盖范围目录与命名服务、安全服务与权限级别、全网时间校准服务、跨系统资源恢复的事务管理服务、规定的开发方法、已接受的可支持产品集硬件、系统控制软件、常用应用、帮助台、安全规则、打印子系统构架。读完之后要落一条结论哪些子构架是强制使用、哪些是明确排除。模板里提到的例子包括某种开放系统互联体系、某种系统网络体系、某类 Unix 变体、某厂商的系统应用架构以及因封装应用方案而被动引入的特殊构架。这里还有个容易忽略的点要记录客户要求的开放程度也就是厂商独立性和互操作性要求它决定了你能不能选某个绑定很深的方案。第二层是网络构架。要弄清基本规则和拓扑记录四件事物理拓扑方面的考虑网络覆盖是集中还是分散、网络附属装置是密集还是松散分布、当前基础设施支持哪些高层连接功能、用哪些通信标准来支撑这些功能、以及支持哪些编程接口。最硬的一条是层级间的连接约束比如“表示逻辑必须始终在工作站数据访问逻辑必须始终在集中式主机”或者“工作站到数据库服务器的访问必须走特定数据库产品的协议”。这类约束一旦写进需求架构选型基本就定了。第三层是连接策略。即使没有成文的技术构架也常有一些零散规定是否要求用特殊协议或通信设备实现跨楼、跨组织连接现有设备或软件是否隐含要求某种协议是否复用现有物理链路电缆、网络或外设控制器、常用载体如果不复用是因为政策、法规、场地条件还是第三方参与需要安装或修改物理设备时第三方承包商、通信服务商如何介入、责任怎么划以及移动用户的接入支持。还有一类容易漏的“其他策略”新系统接口是否必须按面向对象原则设计并支持拖放是否必须基于客户端/服务器模型是否必须按公开标准定义多语言支持的标准和政策特别是从右向左文本安全策略中认证、访问控制、数据保护的职责划分以及行业交换标准的使用要求。最后补一条模板里点得很透的策略用户或部门能否在工作站和服务器上自行安装、开发本地程序。不控制这项本地程序会很快吃光为生产系统采购的资源等到首次公开展示时系统装不上那时候再处理就晚了。3.2 评测单元怎么切业务流、应用、事务三层对齐数量段的第一步不是数数是定义“数什么”。模板给的路径是与开发人员合作把业务流程细分成更小的单元比如更小的业务流程或事务。原因很实际——下一步要记录业务量必须先确定计数对象。这里有个组织层面的常见问题不同背景的人用同一个词指不同东西。“事务”对应用开发背景的人是一个含义对基础设施团队是另一个含义。所以第一件事是建词汇表把三层关系对齐层级定义示例谁关心业务流程端到端业务目标订单处理业务方、产品应用程序实施该流程的 IT 系统订单系统架构师、开发事务应用内的具体操作查询库存、生成客户函件开发、运维、容量一个业务流程通常由一个应用实施也可能由多个应用共同实施一个应用内通常有多个事务。切分时要注意乘数一个业务流程可能触发多个更小事务的实例比如一张订单里有多条订购商品行记录数量时要把这个乘数算进去。但也不必过度追究细节尤其是复杂系统切到能稳定计数、能对应监控指标的程度就够了。落地时我会要求每个评测单元带一张小卡单元编号、所属业务流程、实施应用、事务名、计数口径按请求数还是按业务单据数、乘数说明。这张卡后面会被容量估算、压测脚本、监控看板三处复用口径不一致就会出现“压测说撑得住、生产说扛不住”的翻车现场。3.3 业务量与性能标准高峰值的记录口径有了评测单元业务量和大小就好记了。模板列了四类信息一般时间和高峰期的用户数、高峰期的时间粒度按天、按周还是按月看、高峰与一般时间的处理速率、以及每个数据组里数据元素和实例的数量与大小。第三项和第四项常被写反——处理速率是流量数据量是存量容量规划要两个都有。性能标准这一节模板给了八个记录项我建议直接做成表格逐项填缺一项就标红记录项填什么用途响应/周转需求分事务类别给指标验收依据评测位置客户端测还是服务端测避免各测各的分时段的差异夜间是否可放宽给设计留弹性恢复期能否达标降级或恢复状态下是否仍满足决定应急预案是否需要性能保证是否要写进合同商务口径未达标的业务影响具体损失描述优先级排序依据可用与缓慢的分界低于哪个值算“不可用”定性与定量分界封装包的性能特征从哪拿、什么时候拿选型阶段的前置动作最后一项要单独强调。如果已经选了封装应用方案就必须知道怎么拿到它的性能特征数据。你现在可能不需要这些数字但将来一旦需要得知道去哪找让第三方提供数据可能要花不少时间所以要在选型或招标阶段就把它列为交付物而不是等性能验收前两周才发邮件去要。4. 可用性与安全性把“不能停”翻译成可验收的条款这两节是 SRS 里最容易被写成口号的地方。“系统必须 7×24 小时可用”“系统必须安全可靠”这类句子写进去评审能过实施全崩。这一章讲怎么把它们拆成能测的条款。4.1 可用性需求的四步推导与分时段写法模板给的推荐路径是四步第一确定真实最终用户、他们执行的业务流程、以及执行这些流程的时间段第二分析服务可用或不可用会如何影响用户完成业务目标的能力第三据此指定直接反映用户需求的可用性需求第四如果选了封装方案要注意它的结构和设计对可用性特征的影响——没按连续运行设计的包很难做连续运行尤其卡在维护和批处理窗口上。关键原则有两条。第一条按较小颗粒度指定别给整个系统一个全局指标按流程、用户组、数据组分别写设计人员才有腾挪空间。第二条区分“希望”和“强制”。举个改写示例原句是“系统必须每天 24 小时为两地的用户提供服务”这么写设计只能全冗余。改成“从 A 时区当地时间上午 7 点到下午 7 点A 地用户必须能对自己的数据执行事务处理从 B 时区当地时间上午 7 点到下午 7 点B 地用户必须能对自己的数据执行事务处理”设计就能在一个时区仍处于工作时间时对另一时区的数据或构件做维护。再看一个强制与希望分离的写法自助终端必须能全天接受存款和取现希望全天提供准确的账户余额查询但余额查询允许偶发中断中断时长必须少于 10 分钟且只能发生在凌晨 3 点到 4 点之间。这个句子的好处是每一段都能测功能范围能测、时长能测、时间窗能测。还有一条判断标准值得记住如果某个可用性目标没达到也不会直接影响用户完成业务目标那它可能不该作为系统的可用性需求写进来。同样间接反映可用性的指标比如“必须建立某控制区域”通常不如直接指标比如“柜员必须能执行流程 X 和 Y”有用因为后者能直接转成测试用例。4.2 服务中断成本怎么量化要定出真正重要的可用性需求得先知道中断的代价。模板的做法是按流程集和用户组分别评估几类情形计划时间内短暂中断或响应极慢“短暂”和“极慢”要结合具体应用定义、各种更长时长的中断1 分钟、数分钟、15 分钟、30 分钟、1 小时、2 小时、4 小时等、以及长时间中断一个班次、一天、多天。还要覆盖与用户组不直接相关的流程比如夜间票据交换。量化口径有几条现成的员工或设备生产效率降低的成本、当前业务的价值损失、客户不满导致的未来业务估计损失、利息开支、合规性处罚。这里有个容易漏的动作评估每种中断影响时要同时确定应急流程并考虑这些流程能把实际影响压到多低。因为应急流程的存在会改变结论不写进去成本模型就是虚的。然后是降级方案。模板给了三组对照很能说明问题完整功能是读取并更新记录缩减功能是先录入更新请求、排队等维护结束后再落库完整功能是读取最新余额缩减功能是从可能不很新的备选来源读取完整功能是更新电子日志缩减功能是更新纸质记录。降级态必须带边界比如“过时余额信息的过时时间不得超过 24 小时”否则降级就成了无期限凑合。中断影响的差异也要写清楚。生产线控制流程短暂中断影响可能很小因为可以按先前打印的工作单继续变更手工记录后再补录但中断超过六十分钟产线可能在剩下的工作时间都停着。金额巨大的财务清算系统在交易最后时段中断可能带来严重的利息成本或合规风险。应急响应类系统的派遣功能不可用时手工流程仍能响应但响应时间会拉长风险依然存在。预订类系统在高峰期中断当下业务未必损失但客户不满可能在下次选择时体现出来。4.3 灾难恢复的范围裁剪灾难恢复这一节最常见的错误是“全都要”。模板写得很清楚并不一定所有业务流程都需要灾难恢复设备只应选择那些至关重要、并且确实需要灾备的流程即使在这些流程内也可能不需要包含所有功能。裁剪本身就是这一节的核心工作。裁剪之后要回答四个问题服务必须在多长时间内恢复恢复时间是从灾难发生时算起还是从决定前往异地工作地点时算起组织在什么条件下会决定异地恢复而不是本地恢复异地数据要更新到什么程度业务才能继续时刻最新、故障后几分钟内更新、还是可接受前一天的数据首次从异地恢复服务是什么时间点以及这组应用相对于共享同一计算设备的其他应用远程恢复优先级如何。还要注意系统的不同部分、不同类型的灾难可能有不同的标准集。另外模板提了一个容易被忽略的联动项如果使用加密系统恢复要同时覆盖可能存放在系统外的机密信息并确保加密保护数据的恢复与相应密钥的恢复相互协调。只恢复数据不恢复密钥等于没恢复。4.4 安全性需求资产—威胁矩阵与加密审计安全性这一节的操作顺序是固定的。先确定需要保护的数据再确定各类数据面临的威胁类型意外损坏或破坏、故意损坏或破坏、商业间谍、欺骗、入侵、病毒再确定物理安全威胁构件失窃、未经授权的物理访问、用户人身安全再确定威胁来源数据中心人员、其他 IT 人员、组织内非 IT 员工、组织外人员最后确定特殊安全需求重点看三处对系统的访问、对数据的加密、可审核性。此外还要检查有没有一般性政策会影响安全设计。真正好用的是矩阵法分三步。第一步按逻辑或物理安全性列出需要保护的对象。第二步为每个对象确定侵害场景典型三类查看访问违反保密性比如账户信息、客户列表、专利、更新访问为欺骗、掩饰或资金转移而篡改数据、资产丢失所有权被他人获得而对拥有者不可用区别于灾害造成的丢失。第三步把对象与威胁场景关联并标注对象处于静态位置如硬盘上还是移动中如传输期间的安全需求差异。由于设计可能把对象扩展到不安全的区域这个矩阵还要在设计阶段复查一次。注意并非所有对象对上述所有侵害场景都敏感。给每条都打勾的矩阵等于没做评审时会被直接退回。最后一件事是早判断。某些系统对安全的要求会苛刻到支配设计决策让在其他场景很合适的结构和构件变得不可接受比如涉及高价值资金流转的系统、处理个人机密信息的系统。如果判断自己属于这一类需求阶段就该找安全方向的专家介入而不是等架构定完再补。所有非功能性需求包括上面这些最终都要归到补充规约里跟功能需求分开维护。5. 避坑SRS 评审前最容易翻车的五处这一节是按“现象—原因—解决”整理的现场记录都是评审会上真实被退回过的类型。第一条全系统一句 7×24。现象可用性章节只有一行“系统须 7×24 小时可用”架构评审直接卡住因为满足它意味着全链路冗余加双活成本翻倍。原因没有按流程、用户组、数据组切分把“希望”当成了“强制”。解决改成时段×用户组矩阵每个格子写清强制还是希望强制项配验收方法把维护窗口显式写进需求比如“A 地用户非工作时段允许不超过 4 小时的计划中断”。第二条假设只写结论不写依据。现象项目中期要改一个容量假设没人说得清它当初为什么成立只能整套重算。原因“假设与问题”列表只记了内容没记推理过程和影响范围。解决每条假设强制填依据、影响的需求编号、复审节点每个阶段末和客户一起复审问题列表假设列表则按重要度分级复审——不重要的假设客户未必是合适的复审人。第三条评测单元口径不一致。现象压测报告说系统能撑住上线后监控显示的事务量是压测的三倍两边都对不上。原因业务流、应用、事务三层混用乘数漏算或者一个按请求数计、一个按单据数计。解决先建词汇表和计数口径表一张订单含几条明细必须写明容量估算、压测脚本、监控看板共用同一套单元编号。第四条封装包的性能特征没提前要。现象性能验收前两周发现厂商给不出基线数据排期要一个月。原因选型阶段没把性能特征列为交付物以为“以后再问也来得及”。解决把性能特征数据写进选型材料清单明确要哪几类指标、什么粒度、谁提供同时在 SRS 里记录获取渠道即使当期不用。第五条可用性需求写成间接指标。现象验收时测试问“必须建立某控制区域”这条怎么验没人答得上来。原因写的是内部构件状态不是用户可感知的行为。解决每条可用性需求后面跟一条可观测的验收方法写成“谁、在什么时段、执行哪个流程、在多长时间内完成”写不出来的条目要么改写成直接指标要么从需求里删掉。6. 用一张追溯表收口从需求条目到测试用例最后一章讲一个我自己每次评审前必走的动作拿一张追溯表把每条需求从头到尾串一遍。这张表只有五列但能挡住大部分返工需求编号类别验收方法测试用例编号关联设计件SRS-AVL-MET-004可用性度量分时段执行流程 X记录成功率TC-AVL-012部署视图 v1.3SRS-SEC-CON-002安全约束审计日志字段核对TC-SEC-005数据模型 v2.0走法很简单按编号顺序过每行问三个问题——验收方法能不能被第三方独立执行测试用例编号是否真实存在还是只占了个位关联设计件是不是最新版本。三问里任何一问卡住这条需求就不该被判为“已基线”。我一般会把它做成一列状态位PASS、GAP、NA三种GAP必须在评审会前清零或者带上明确的关闭计划。有个细节值得单独说追溯表要和第 2 章那段校验脚本一起用。脚本管结构编号合法、字段齐全、陈述够长追溯表管关系每条需求都有验收方法和用例。两者都不覆盖内容质量——内容质量只能靠人读。所以我的习惯是脚本跑完人工只读GAP行和新增行剩下的时间用来跟业务方确认“不可用”与“缓慢”的分界值这个数字没人替你定。从那以后我每次提交 SRS 前都强制把校验脚本和追溯表各走一遍哪怕只有三条需求变更。不是因为流程要求是因为被退回过一次代价是两周返工。希望帮到你。本文还有配套的精品资源点击获取