简介这份文档围绕IBM软件需求规约SRS的格式模板与案例展开面向需要编写或评审需求规格说明的项目经理、需求分析人员、开发与测试人员也可供软件工程课程学习参考帮助解决需求收集、组织与表达缺乏统一框架的问题。压缩包共1个doc文件大小约150KB内容以SRS主体结构为主线涵盖概述、指定、标准、数量、可用性、安全性等章节并涉及功能性需求、非功能性需求、假设与问题、地理组织、应用程序包、技术架构与网络架构、服务时间与灾难恢复等要点。文档还说明了SRS在开发人员、测试与QA小组、项目经理之间的参考与交流作用。已有277人学习适合用来对照IBM模板梳理需求条目、检查章节完整性并作为需求规约案例参考。1. 一份二十多年前定型的 SRS 模板为什么现在翻出来还能用评审会开到第三轮开发问了一句“这条需求验收时按什么判定”会议室安静了。需求文档里写着“系统应快速响应、稳定运行”评审时谁都挑不出错验收时谁都说不清。这份资源是某国际 IT 厂商在统一过程RUP工件体系里沉淀下来的软件需求规约SRS说明与案例骨架把 SRS 拆成概述、指定、标准、数量、可用性、安全性六块每一块都写清了要记录什么、找谁确认、细到什么颗粒度。写需求的 BA、接需求做设计的开发、拿需求建用例的 QA都能在里面找到自己那一栏该填的内容尤其是手里攒了一堆“高性能、高可用”形容词却不知道怎么落成数字的人翻一遍能省不少返工。2. SRS 是文档还是包先把工件边界和三类读者的用法划清楚2.1 从前景文档到 SRS 的交接点前景文档回答的是为什么做、给谁做、目标市场在哪、系统要有哪些特性语气偏概括。SRS 回答的是“为了交付这些功能系统必须执行以下操作”语气具体、可验证。两份工件有关系前景可以作为 SRS 的输入但它们服务不同的需要通常也由不同的人来写。项目走到 SRS 这一步重点已经从“说明用户需要什么”转到“在解决方案里怎么实现这些特性”这个转折点如果没卡住后面设计和测试都会反复回头补。交接时最容易出的问题是前景里写了一条特性SRS 里找不到对应的行为描述或者前景里的目标用户在地理组织那一节里没有落位置。我一般会在交接时过三件事——前景里的每条系统特性是否都能在 SRS 找到对应的行为条目前景里的目标用户群是否在“地理组织”里标了所在地和在线时段前景里的成功指标是否能转成“数量”章里的业务量或性能标准。三件事过完SRS 的骨架基本就立住了后面填肉不至于跑偏。这里有个容易被忽略的判断SRS 不是一个“大卷文档”而是一个信息包。原文的说法是没有充分理由去纠结工具之间的差异重点应放在有效收集和组织需求上。这句话放到今天依然成立——需求可能一半在用例工具里一半在表格里还有几条躺在邮件里真正要管的是它们的索引关系而不是它们存在哪个软件里。2.2 三类读者的三种用法同一份 SRS项目经理、开发、测试读的是不同的部分读法也不一样。项目经理不太可能有时间、精力或能力去读开发写的代码再和前景对照他们拿 SRS 当与团队讨论的标准参考开发在确定代码必须做什么的时候重点看 SRS它带有契约性质——不在 SRS 里的不做在 SRS 里的有责任交付测试和 QA 拿 SRS 建测试用例和 QA 过程用来确认开发出来的系统确实满足 SRS 里提的需求。QA 该参加早期讨论目的是理解前景但他们的职责是验证 SRS不是验证前景。把这三类用法落到具体动作上我会在 SRS 初稿评审前做一张读者分工表明确每一块内容由谁主笔、谁复核、谁签字。没有这张表SRS 很容易写成“给领导看的文档”而不是“给项目用的工件”。角色主要读哪几块用来做什么介入节点项目经理概述、数量、可用性作为与团队讨论的标准参考判断范围与验收口径需求基线冻结前开发/实施指定、标准、功能性需求确定代码边界识别设计约束SRS 初稿评审测试/QA功能性需求、可用性、安全性建测试用例和 QA 过程SRS 初稿评审越早越好运维可用性、灾难恢复、安全性评估服务时间、恢复目标和安全责任可用性章节定稿前下面这段话我建议每位写 SRS 的人都贴在显示器边上SRS 是一种活动的、有生命的工件不是编制好就放在角落里不再理会的卷宗。说它“活”体现在两件事上——开发动手实现时它是各方交流的基础它以正式或非正式的方式代表契约性协议。一旦需求变更没有回流到 SRS这份文档在两周内就会变成黑匣子谁也不敢引用。2.3 功能性与非功能性需求的分流功能性需求放到用例模型和用例里非功能性需求放到补充规约里。分流的原因不是洁癖是这两类需求的变更节奏、评审人、验证方式都不一样。功能性需求改了影响的是用例和测试用例非功能性需求改了影响的是架构选型和采购。混在一起写改一条要牵动一整章评审时也容易变成“懂业务的人听不懂性能懂性能的人不关心业务”。我会给每条需求配一个结构化条目字段固定下来写的人就不会漏。下面这个模板是从这份资源的分类方式里抽出来的字段名可以按团队习惯改但类型、验收口径、约束三项不建议省。{ req_id: SRS-NFR-AVL-014, type: non_functional, category: availability, source: 运营部门访谈 2024-03-11, statement: 东部站点用户在本地时间 07:00-19:00 可对其账户数据执行查询与更新事务, acceptance: 该时段内事务成功率达到 99.5%单事务 P95 响应时间不超过 2 秒, constraint: 维护窗口只能安排在 19:00-07:00, priority: mandatory, linked_usecase: UC-03 账户维护 }字段的含义需要说清楚req_id是跨工件的唯一索引后面做追踪矩阵全靠它type区分功能性与非功能性决定这条需求该进用例还是进补充规约acceptance是验收口径写不出这一项的需求基本等于没写constraint记录设计约束比如维护窗口priority用来区分强制和期望原文反复强调要区分“希望的可用性特征”和“强制的可用性特征”这个字段就是干这个用的linked_usecase把非功能性需求和它约束的用例挂上避免性能指标悬在空中。2.4 工件散落时用索引把 SRS 串起来需求散在多个工件里是常态。功能性需求在用例模型里非功能性需求在补充规约里指定和标准可能写在架构决策记录里数量和可用性可能来自运维的容量报告。SRS 包的作用不是把这些内容抄一遍而是给它们建一个统一的索引让任何人拿到一个需求编号都能顺着索引找到原始出处和当前状态。我一般会维护一张索引表字段不多但必须齐需求编号、所在工件、记录工具、负责人、当前状态、最近一次变更日期。这张表不追求好看追求的是评审时能当场翻到出处。索引表更新不及时SRS 就会退化成一份“看起来完整、实际过期”的文档这比没有文档更危险因为有人会信它。3. 指定与标准把设计约束写进需求别留给设计阶段去猜3.1 预选应用程序包一旦写进需求设计空间就被锁死“指定”这一章里杀伤力最大的是预选应用程序包。需求里一旦写了“必须使用某某包”很多设计决策在需求阶段就被定掉了而不是等到设计阶段再讨论。原文列了一串包可能要求的构件和决策工作站类型、连接方法、处理器和 DASD 类型、系统控制程序、数据组织与存放管理、编程语言、批接口、进程和数据关系、业务逻辑、屏幕设计和最终用户界面、性能和可用性特征、打印架构比如首选的打印数据格式是 PostScript、PCL 还是 IPDT、国家语言支持NLS。这份清单的价值在于它把“选了一个包”这件事拆成了十几个需要确认的接口点。很多项目翻车不是因为包不好而是因为只确认了功能匹配没确认打印格式、批接口、NLS 这些边角等到集成时才发现包不支持从右向左的文本排版或者批接口只认一种固定格式。写这一节时我会要求同时记录“包的灵活性”。有些包允许大量定制有些非常固定不允许定制。这个差异直接决定后面设计能改多少东西。还有一个常被跳过的动作确认技能和知识的可获得性。这些知识可能来自包厂商、外部顾问也可能来自经过专门培训的设计团队成员。不要假设这些知识很容易获得要在需要之前就确认能拿到最好落到人名和响应时限。3.2 特殊硬件与现有数据特殊硬件的需求可以写得很一般比如“系统必须支持高速平板绘图仪”也可以写得很具体比如“系统将支持现有某型号 ATM”。颗粒度取决于这个硬件对设计的约束有多强。要记录的内容包括任何硬件或软件先决条件、厂商及其支持组织、国家语言考虑事项、加密设备。加密设备这一项经常被漏等到安全评审时才补往往牵动整个数据流设计。现有数据的指定同样会影响设计。需要记录的是数据当前位于什么系统上、现有数据的结构是关系型文件还是平面文件、数据大小、目前哪些用户和系统在使用、可用性考虑比如因为数据库维护或批处理导致数据不可用的时间段、这些数据是否可以移动或复制。最后一项特别关键不能移动的数据会逼着新系统去适配老系统的接口和停机窗口设计上的自由度立刻少一截。我见过一种典型情况需求里只写了“新系统要读取现有客户数据”没写这份数据每晚有一段时间不可用。设计按实时读取做上线后每天那个时间段就报错最后只能加缓存层来兜。如果需求阶段把“不可用时间段”写进去设计一开始就会考虑缓存或者批量同步成本差一个量级。3.3 技术架构、网络架构与连接策略技术架构这一块原文给的清单相当长计算中心的数量和用途、企业的广域网连接性、某些设施的局域网连接性、客户机/服务器基础设施服务中间件的覆盖范围、目录及命名服务、安全服务以及权限级别、时间服务、事务管理服务、将用于新应用的开发方法、已接受的可支持产品集硬件、系统控制软件、常用应用、帮助台、安全规则、打印子系统架构。这份清单不用逐条填满但每一条都要判断“客户有没有明确规定”有就记下来没有就写“未规定”别留空。记录时要特别标注“明确要求使用或排除”的子架构以及客户所需的开放程度也就是厂商独立性和互操作性。开放程度这一项听起来虚实际影响很大要求厂商独立选型时就不能绑死在某一家中间件上要求互操作接口测试的工作量要提前算进去。网络架构是一组公用的高层连接性规则外加一个公用传输基础设施可能包括对主干网络的定义。需要记录的是物理拓扑方面的考虑网络基本位于人口稀疏区域还是大城市网络附属装置是密集分布还是松散分布、当前网络基础设施支持哪些高层连接功能、使用哪些通信标准来支持这些连接、支持哪些编程接口以及对客户机/服务器层之间连接性的任何定义。最后一项经常被写成一句含糊的话实际应该写到这种程度关系型数据访问是否必须借助特定关系数据库产品的协议表示逻辑是否必须始终在工作站而数据访问逻辑是否必须始终在集中式主机系统中。连接策略是另一层约束。要记录与特殊协议或通信设备有关的任何策略、是否隐含要求用特定协议来支持现有设备或软件、是否使用现有物理连接设备、是否需要第三方参与安装或修改物理设备、对移动用户的支持。第三方参与这一项在国际性连接的业务交互里尤其要写清楚承包关系和职责边界否则出问题时两边都说不清是谁的责任。还有一个策略容易被漏掉用户或部门是否可以在工作站和服务器上添加或开发自己的本地程序。原文提醒得很直白——如果不加以控制本地程序可能很快耗尽生产系统所需的资源而本地构件原本是为了这些生产系统才购买的。等到首次公开展示生产系统时可能发现系统根本装不上。这条我建议直接写进 SRS 的“其他策略”里并且明确谁有审批权。3.4 假设与问题清单与地理组织收集和验证非功能性需求时要维护一个“假设与问题”列表。原文把它拆成两个列表一个是需求和设计流程中作出的所有假设包括这些假设的基本原理或思维过程以及可能用来确定本项目之外的相关子项目或工作项的假设另一个是所有主要问题也就是可能中断项目进行的重要事项。每个阶段结束时应该与客户一起复审这些问题假设也需要复审但对于不太重要的假设客户可能并不是合适的复审人选。这段话里最有用的是“每个阶段结束时复审”这个动作。很多团队的假设清单只在启动会建一次之后再也不看等到项目中期假设已经不成立没人发现。我的做法是把复审排进阶段评审的议程问题清单逐条过状态假设清单只过“高影响”的那几条控制在半小时以内避免变成走过场。地理组织要记录三样东西客户的地理组织、受该系统影响的业务部分所处的地理位置、未受影响但安装有主要 IT 设备的工作地点。移动工作部门要单独记比如需要四处旅行并使用工作站的销售部门。还有一项是可能需要提供特殊自然语言支持的所有地理位置。这一节看起来是行政信息实际直接决定可用性章节怎么拆用户组——不同地理位置的用户服务时间往往不一样不拆开就没法写可用性指标。4. 数量与可用性把“要快、要稳”换成能验收的数字4.1 评测单元先统一口径再谈数量数量这一章的第一步不是收集数字是确定“数什么”。原文的建议是跟应用程序开发人员合作把业务流程细分为更小的单元比如更小的业务流程或事务。原因是下一步要记录数量必须先确定计数对象。一个业务流程可能会启动几个更小业务事务的实例比如各个客户订单中的多项订购商品记录数量时要记住这些乘数。这里有个协作上的坑不同人群会用各自的名称来标识同一个单元。“事务”对具有应用开发背景的人是一种意思对基础设施团队可能是完全不同的意思。所以要先通过协作把名称的对应关系对齐再开始收数。我一般的做法是拉一张对照表左列写业务侧的叫法右列写 IT 侧的叫法中间写换算关系三方签字后再往下走。这张表不签字后面所有容量数字都不可比。原文也提醒不必过分深究细节尤其对于复杂系统。这句话是给强迫症的一剂解药——评测单元切到能对应到一个可测量的处理动作就够了再往下切会陷入无穷递归。4.2 业务量与高峰期四类必须落表的数字确定评测单元之后要记录每个单元的业务量和大小信息。原文列了四类预计在一般时间和高峰期各有多少用户使用各个业务流程或应用程序什么时候是高峰期按天、周、月分别是什么情况在高峰期和一般时间各需要以什么速度处理事务在每个数据组中数据元素和实例的数量以及它们的大小。这四类数字里最容易糊弄的是“高峰期”。很多需求只写“高峰期用户较多”这种描述没法用来做容量设计。合格的写法要落到具体时段比如“每月最后两个工作日的 09:00-11:00 为峰值并发用户数为日常均值的 2.5 倍”。另一个容易漏的是数据组的大小它决定存储和备份策略也决定批处理窗口够不够。4.3 性能标准写清评测点和最低可用线客户可能指定了部分或所有业务流程的性能标准但系统支持流程如系统备份和应用程序开发流程的性能目标也值得记录。对每一类要写响应或周转需求、将在哪里进行评测、在不同时间比如非高峰的夜间是否可以接受不同的标准、在恢复或应急期间是否可以达到标准、是否需要性能保证、如果没有达到性能需求会对所有各方产生什么影响。还有一条是分界线表述业务流程被认为可用的最低性能条件也就是说在该点以下系统将被认为是“不可用”而不是“缓慢”。这条线不写验收时就会陷入争论——用户觉得慢得没法用开发觉得功能还在响应。把“不可用”的阈值定下来双方都有据可依。如果已经选择了封装的应用程序解决方案要提前知道怎么访问它的性能特征。现在可能不需要这些数字但将来一旦需要得知道从哪里找。让第三方提供需要的数字可能要花不少时间所以现在就该提要求。这一点是血泪经验等到上线前一周才去问厂商要吞吐量数据对方排期两周项目只能干等。4.4 服务时间、中断成本与恢复标准可用性这一块原文给了一个四步的推荐方法确定系统的真实最终用户、他们正在执行的业务流程、执行这些流程的时间分析服务可用性或不可用性将如何影响最终用户完成业务目标的能力指定适当的可用性需求直接反映最终用户为完成业务目标而具有的需求注意封装应用解决方案的结构和设计可能对最终用户看到的可用性特征产生重大影响未被设计来进行连续操作的包可能很难连续操作尤其是在维护和批窗口方面。服务时间要按业务流程和用户组来定不同时区的用户组应当作独立用户组处理。原文举的例子很能说明问题“系统必须每天 24 小时为两个不同时区的用户提供服务”给设计人员的灵活性远不如“从 A 时区上午 7 点到下午 7 点A 时区用户必须能够对数据执行事务处理从 B 时区上午 7 点到下午 7 点B 时区用户必须能够对数据执行事务处理”。后一种写法下即使一个时区还在工作时间设计人员也可以对另一个时区的数据或构件做维护。还要说明是否存在可能不需要应用的偶然时间段比如业务假期这样设计人员可以在这些时间段安排大规模维护。服务中断成本要分级评估计划服务时间内的短暂中断或响应极其缓慢的时段延续时间更长的中断按 1 分钟、数分钟、15 分钟、30 分钟、1 小时、2 小时、4 小时分档长时间中断比如一次换班、一天、许多天。与用户组不直接相关的流程也要考虑比如夜间票据交换。评估每种中断的影响时要确定应急过程并考虑这些过程如何减少对业务的实际影响。尽量从财务上量化员工或设备生产效率降低的成本、失去当前业务的价值损失、因客户不满意而对未来业务造成的估计损失、利息开支、法规性处罚。恢复标准的写法要具体到可判定。原文给了两种形式在给定的分钟或秒数内被恢复的中断所占的百分比在给定的周、月、年内用户无法执行特定功能的最大时间长度。还要尽量反映各种因素比如计划内和计划外中断的差异、中断发生的时段是“关键”时段还是低峰时段、受影响的是所有用户还是少数用户。原文还提醒不要指定不太紧迫的可用性标准因为会显著影响实施成本如果在一组给定的中断条件下无法确定重要的业务或财务成本那可能表明不应当把这些中断条件写进可用性标准。4.5 灾难恢复只给真正关键的流程配灾难恢复问的是“灾难情况下的可用性”比如损失严重或整个计算设备关闭时。原文明确说并不一定所有业务流程都需要灾难恢复设备只应选择那些至关重要并且的确需要灾难恢复的流程即使在这些流程内也可能不需要包括所有功能。需要写清的问题包括服务必须在多长时间内恢复恢复时间从灾难发生时开始计算还是从决定前往远处工作地点时开始计算组织在什么条件下会决定在远处工作地点恢复而不是在本地在远处工作地点的数据必须处于怎样的更新状态是必须时刻最新、故障后几分钟内更新还是可以接受前一天的数据首次从远处工作地点恢复服务是什么时候相对于依赖相同计算设备的其他业务应用程序这组应用程序的远程恢复具有什么优先级。系统的不同部分或不同类型的灾难可能会有不同的标准集这一点也要在文档里分开写。把可用性目标换算成允许停机时长可以避免“99.9%”这种数字被误读。下面这个小脚本我常放在需求评审的材料里用来当场对齐口径。# 把年度可用性目标换算成允许停机时长并校验恢复标准是否自洽 def allowed_downtime_minutes(target_availability, days365): total_minutes days * 24 * 60 return round(total_minutes * (1 - target_availability), 1) def recovery_pass_rate(incidents, recovered_within_sla): # incidents统计周期内的中断次数recovered_within_sla在承诺时间内恢复的次数 if incidents 0: return None return round(recovered_within_sla / incidents * 100, 2) print(allowed_downtime_minutes(0.999)) # 99.9% 对应的年度允许停机分钟数 print(allowed_downtime_minutes(0.9995)) # 99.95% 对应的年度允许停机分钟数 print(recovery_pass_rate(40, 38)) # 40 次中断里 38 次在承诺时间内恢复target_availability用小数传入0.999 表示三个九days默认按 365 天算闰年场景可以显式传 366。recovery_pass_rate返回的是达标率百分比incidents为 0 时返回None避免除零也避免把“没有中断”误报成 0% 达标。评审时把这两个数字一摆“99.9%”到底意味着一年停多久、恢复达标率要求多少讨论会具体很多。5. 安全性需求落地与五个高频翻车点按现象排查5.1 安全性需求的四步拆解安全性需求最怕写成一句“系统应保证安全”。原文给的方法是先列对象、再列侵害场景、再列威胁来源最后做关联。第一步确定需要保护的数据。第二步确定各种数据所受到的安全威胁类型意外的损坏或破坏、故意的损坏或破坏、商业间谍行为、欺骗、黑客行为、病毒。第三步确定对物理安全性的威胁偷窃构件、未经授权的物理访问、用户的人身安全。第四步确定哪些人可能是威胁来源数据中心工作人员、其他 IT 工作人员如开发人员、组织中的非 IT 工作人员、组织外的人员。然后确定特殊的安全性需求尤其是对系统的访问、对数据的加密、可审核性这三个方面。还要检查是否有一般性政策会影响系统的安全性设计。某些封装的应用程序解决方案拥有自己的安全性子系统如果选了指定的包就要了解它的安全性功能别假设它默认够用。原文还给了另一种更细的分类方法按照逻辑或物理安全性列出需要保护的对象确定与各个对象相关的侵害场景典型类别是查看访问违反保密性比如账户信息、客户列表、专利、更新访问为进行欺骗、掩饰和资金转移而修改数据、资产丢失所有权被他人获得从而对拥有者不再可用确定与所在环境相关的所有威胁比如心怀不满的雇员、未经授权的雇员、在公有场合进行公开的终端会话、黑客、电话窃听、设备丢失对每个对象确定它可能受到哪种威胁并关联到具体威胁场景。注意要检查对象在静态位置比如硬盘上和在移动中传输期间两种状态的安全性需求。保护对象查看访问保密性更新访问完整性资产丢失可用性主要威胁来源客户账户余额高高中未授权雇员、公开终端会话合同文本高中高离职雇员、设备丢失交易流水中高中外部人员、通信线路窃听批量对账文件低高高内部 IT 人员误操作这张表的作用不是打分是逼着写需求的人把“安全”拆到对象级别。填不出来的格子往往就是需求盲区。原文还提醒某些系统设计在安全性方面可能有非常苛刻的要求会支配设计决定使在其他情况下很合适的结构和构件变得不可接受比如敏感的军事系统、高额货币汇兑系统、处理个人机密信息的系统。遇到这类系统应该找安全专家或安全从业者协助设计不要自己硬扛。5.2 五个高频翻车点现象一SRS 写完就锁进柜子后续变更只在邮件里流转。原因通常是把 SRS 当成一次性交付物而不是活动工件。解决方式是把 SRS 挂到变更单上任何需求变更单必须写明影响哪几条 SRS 条目变更关闭时同步更新条目状态每个阶段末做一次条目与索引表的对账对不上的条目要么补更新要么标记废弃。这件事不靠自觉靠流程卡。现象二可用性写成“系统必须 7×24 小时可用”。原因是把全局可用性当成了唯一写法结果设计人员没有任何维护窗口只能靠堆冗余来兜。解决方式是按用户组、时区、业务流程拆开写把“希望的”和“强制的”分开。比如写成“收银员在营业时段必须能执行收款和退款账户余额查询允许在凌晨 03:00-04:00 之间有不超过 10 分钟的中断”设计人员立刻就有了排维护窗口的空间。现象三性能标准只有响应时间没有评测点和最低可用线。现象是验收时双方各执一词开发说功能还在返回用户说已经没法用。原因是需求只写了“响应时间不超过 2 秒”没写在哪个位置测、测什么操作、低于哪条线算不可用。解决方式是每条性能标准补三个字段评测位置、评测操作、最低可用性能条件。低于那条线系统状态直接判为不可用而不是缓慢。现象四选了封装包却没摸清它的安全性子系统。现象是安全评审时被问“这个包的审计日志覆盖哪些操作”没人答得上来。原因是需求阶段只验证了功能匹配把安全当成了包的默认能力。解决方式是在“指定”章节里单独列一小节写清包自带的安全功能、缺口、以及缺口由谁补。补的方式可能是加一层网关也可能是改流程两种成本差很多必须提前定。现象五假设与问题清单只在启动会建一次。现象是项目中期某个假设早已不成立但没人发现直到联调才暴露。原因是清单没有复审节点也没有责任人。解决方式是把复审排进阶段评审议程问题清单逐条过状态高影响假设单独过每条假设和问题都指定一个负责人和复审日期过期未复审的自动升级到项目例会上说。6. 评审前跑一遍检查表我的 SRS 交叉验证习惯6.1 评审前半小时的七项检查SRS 初稿写完到评审会之间我固定留半小时做一遍交叉验证。不是通读全文而是拿一张检查表逐项对对不上就回头改改不完就在评审会上明确标出来。这张表是从前面几章里压缩出来的七项半小时能跑完。检查项判定标准不通过时回头看功能性需求都有用例编号没有孤儿需求也没有无需求的用例2.3 节的分流模板可用性需求都带用户组和时间窗全文不出现“7×24”这类全局写法4.4 节的服务时间拆法性能标准都带评测点和最低可用线能当场回答“在哪测、低于多少算不可用”4.3 节的性能标准字段指定项都有技能来源包、特殊硬件、现有数据三项都落到人或组织3.1、3.2 节的记录清单假设与问题清单有复审日期最近一次复审在两周内高影响项有负责人3.4 节的复审机制安全对象-威胁矩阵覆盖静态与传输两种状态每行至少一个威胁场景空格子有解释5.1 节的对象分类灾难恢复只覆盖关键流程非关键流程有明确的“不恢复”结论4.5 节的取舍原则6.2 把检查表挂到变更单上这张表只用来评审前跑一遍效果有限真正让它发挥作用的是把它挂到变更单上。我的做法是任何需求变更单提交时提交人必须回答表中受影响的那几项比如改了可用性指标就要说明用户组和时间窗有没有跟着改改了指定包就要说明技能来源有没有重新确认。变更评审时这几项答不上来就打回。这个习惯是被一次返工逼出来的。早年做的一个项目SRS 评审时大家看得挺仔细半年后换了一版应用包没人回头改“指定”章节结果设计按老包的接口做集成时发现新包不支持原来的批接口格式整个批处理链路重写。从那以后我每次提交需求变更单都强制走一遍这张检查表哪怕只改一行字。希望帮到你。本文还有配套的精品资源点击获取