简介面向软件需求工程初学者与项目团队的一份IBM软件需求规约SRS格式模板与案例文档用于解决需求收集、组织和表述缺少统一框架的问题。文档以IBM Corporation提供的SRS结构为蓝本依次展开概述、指定、标准、数量、可用性、安全性六个章节并逐条说明假设与问题、地理组织、预选应用程序包、特殊硬件、现有数据、技术构架与网络构架、评测单元与业务量、计划服务时间与灾难恢复、安全性需求等条目分别应填写什么内容。文中还说明了SRS与前景文档的分工SRS作为项目成员参考标准以及测试和QA输入的作用功能性需求借助用例模型定义、非功能性需求记入补充规约并维护“假设与问题”清单的写法。压缩包内共1个doc文件约150KB轻量易读可直接作为撰写SRS时的对照清单与模板骨架。目前已有277人学习下载适合需要规范需求文档结构、查漏补缺的需求分析师、项目经理及软件工程课程学习者参考。1. 需求评审会上最怕的不是吵架是没人拿得出数字一个跨部门系统刚立项评审会就卡住了业务方说“必须 7×24 不能停”运维说“每晚得留停机窗口做备份”开发说“那就先按最高标准设计”。三方都没错但谁也说服不了谁因为桌上没有一份能把话逼到具体数字上的需求规约SRS模板。这份源自某老牌 IT 厂商统一过程体系的 SRS 案例把需求规约拆成概述、指定、标准、数量、可用性、安全性六个大节每一节都在追问同一件事这条约束是谁提的、代价多大、怎么测。它适合正在写第一版 SRS 的人也适合被“需求写了但没法验收”折磨过的项目经理和测试负责人。2. 六个大节的骨架每一节其实在替谁挡风险这份模板最值得抄的地方不是它的排版而是它把“需求”拆成了六类不同性质的约束前提类、指定类、标准类、容量类、可用性类、安全性类。这六类的责任人、验证方式、变更成本完全不同混在一起写最后必然变成一篇谁都不认的散文。我一般拿到一份 SRS 草稿先做一次“归类体检”把每一条需求扔进这六个筐里扔不进去的要么是废话要么是还没想清楚。下面这张表是我自己用的对照表来源就是这份模板的六个大节。大节它在逼你回答的问题缺了这一节的典型后果概述有哪些假设没验证、有哪些问题可能中断项目项目中期发现某个前提根本不成立返工指定哪些设计决策已经被提前锁死架构做完了才发现必须用某个既有软件包标准客户已有的架构和策略有哪些是硬约束交付时因不符合既有网络规范被驳回数量评测单元怎么切、业务量多大、性能标准多少上线后容量不够性能争议无法裁决可用性谁在什么时间需要什么功能、中断代价多大可用性指标拍脑袋定成本失控安全性保护什么、防谁、防到什么程度安全需求写成一句“系统应安全可靠”2.1 概述与指定先把“改不动的前提”钉在纸面上模板第 1 节“概述”里有两个容易被跳过的子项1.1 假设与问题、1.2 地理组织。这两项看着像填表实际上是整份 SRS 的地基。假设与问题要维护成两张清单——一张记录你在需求和设计流程中做出的所有假设以及做出这个假设的理由另一张记录所有可能中断项目推进的重要问题。模板特别强调这两张清单要在每个阶段结束时和客户一起复核但“不太重要的假设客户可能并不是合适的复核人选”这句话很实在不是所有假设都值得占用客户的时间内部先分层。地理组织这一项模板要求记录的不只是“客户在哪”还包括受系统影响的业务部门所在地、未受影响但装有主要 IT 设备的工作地点、所有移动办公部门比如长期出差、用工作站的岗位以及所有可能需要特殊自然语言支持的位置。我见过一个项目因为漏记了移动办公场景结果离线状态下的数据同步完全没进需求上线第一个月就被业务方投诉。第 2 节“指定”是整份模板里最“反直觉”的一节——它要求你在需求阶段就把那些会限制设计灵活性的东西全部写出来。包括预选的应用程序包、现有处理器或操作系统映像、现有工作站设备、现有网络、现有系统管理惯例甚至包括“必须采用客户机/服务器模型”这种架构级指定。预选软件包尤其要小心模板列了它可能连带锁死的一长串东西工作站类型、连接方法、处理器和存储类型、系统控制程序、数据组织与存放方式、编程语言、批处理接口、屏幕设计与最终用户界面、性能和可用性特征、打印数据格式、国家语言支持。写这一节的时候我习惯追问一句这个软件包一旦选定我们还能改什么提示指定这一节写完让架构师签字。签字的含义不是“同意”而是“我知道这些约束存在且没有异议”。2.2 标准与数量架构约束怎么落到可计数的口径第 3 节“标准”分四块技术构架与战略计划、网络构架、连接策略、其他策略。技术构架那一块模板给了一份很长的可发现清单——计算中心的数量和用途、企业广域网连接性、局部局域网连接性、中间件服务覆盖范围目录与命名服务、安全服务、时间服务、事务管理服务、将采用的开发方法、已接受的可支持产品集硬件、系统控制软件、常用应用软件、帮助台、安全规则、打印子系统构架。这份清单的价值在于提醒你客户的“技术架构”不是一张图而是一堆会落到你设计上的规则。网络构架那一块要记的是物理拓扑特征节点是密集还是松散分布、当前基础设施支持的高层连接功能、使用的通信标准、支持的编程接口以及对客户机/服务器各层之间连接性的规定。连接策略那一块更偏工程现实是否强制使用特定协议或通信设备、是否隐含依赖既有设备、是否沿用现有物理连接设施、如果需要安装或改造物理线路会牵扯哪些第三方、对移动用户的支持方式。其他策略里有一条很值得单独拎出来用户在本地自己写程序的策略。模板说得很直白——如果不加控制本地程序会很快耗尽生产系统所需的资源等到首次公开展示生产系统时你可能发现系统根本装不上。第 4 节“数量”是整份模板里实操性最强的一节。4.1 要求先定义“评测单元”和开发人员一起把业务流程切成更小的单元比如更小的业务流程或事务。这里有个必须注意的乘数问题——一个业务流程可能启动多个更小事务的实例一张订单里的多项商品就是典型记数量的时候要把乘数算进去。模板也提醒不要过度深究细节复杂系统尤其没必要精确到个位数。还有一句很关键不同人群对“事务”的理解不一样开发背景的人和基础设施团队说的往往不是一回事必须先对齐名称再做信息收集。4.2 业务量和大小要记录一般时段和高峰时段各有多少用户使用各业务流程、高峰期出现在什么时间粒度每天、每周、每月、高峰期和一般时段各需要多快的处理速度、每个数据组中数据元素和实例的数量及大小。4.3 业务流程性能标准要按类别记响应或周转需求、在哪里评测、非高峰时段是否可以接受不同标准、恢复或应急期间能否达到、是否需要性能保证、未达标对各方的影响、以及“业务流程被认为可用的最低性能条件”——也就是那条线以下系统算“不可用”而不是“慢”。最后这一条我特别看重它把“慢”和“挂”分开了事后追责时是唯一的依据。2.3 可用性与安全性用业务成本倒推技术指标第 5 节“可用性”是这份模板写得最细的部分细到有点啰嗦但啰嗦得有道理。5.1 给了一套四步法确定真实最终用户、他们执行的业务流程、执行时间分析服务可用或不可用会如何影响用户完成业务目标据此指定可用性需求注意预选软件包本身的结构可能就限制了你能否连续运行。模板里有两条原则值得反复读。第一条可用性需求要按较小粒度指定各流程、用户组、数据组不要给整个系统一个“全局”指标。它举的例子是与其写“系统必须每天 24 小时为两地用户提供服务”不如写“从 A 地时间早 7 点到晚 7 点A 地用户必须能对自己的数据执行事务处理从 B 地时间早 7 点到晚 7 点B 地用户必须能对自己的数据执行事务处理”——后一种写法下设计人员可以在一个时区仍处于工作时间时维护另一个时区的数据或构件。第二条区分“希望”和“强制”。模板的例子是自助取款终端必须每天 24 小时接受存款和取现希望 24 小时提供准确的余额查询但允许在凌晨某个固定一小时内中断且不超过 10 分钟。5.2 计划中的服务时间要按业务流程和用户组分别确定跨时区的用户组当作独立用户组处理并说明是否存在不需要应用的偶然时间段比如业务假期以便设计人员利用这些窗口做大规模维护。还要预判在系统生命周期内服务时间会怎么变系统与其他系统交互时服务时间会不会受对方影响5.3 服务中断成本要求把中断按持续时间分档1 分钟、数分钟、15 分钟、30 分钟、1 小时、2 小时、4 小时、一个班次、一天、多天逐档评估业务影响和财务成本并确定应急过程能抵消多少实际影响。模板还要求给出“缩减功能”方案完整功能是读取并更新记录缩减功能是先录入更新请求、排队等维护结束后再落库完整功能是读最新余额缩减功能是从可能不很新的备选来源读。缩减状态下也有底线比如过时数据不得超过 24 小时。5.4 可用性和恢复标准要用可测形式写给定分钟或秒数内被恢复的中断所占百分比给定周期内用户无法执行特定功能的最大时长。模板提醒不要指定不紧迫的标准因为那会显著抬高实施成本如果某类中断条件下算不出业务成本或风险通常说明这类条件不该写进标准。5.5 灾难恢复只覆盖真正关键的流程而且要问清楚恢复时间从灾难发生时算还是从决定切换时算、什么条件下决定异地恢复、异地数据要新到什么程度、首次异地恢复是什么时候、相对依赖同一批设备的其他应用优先级如何。5.6 的其他设计事项更偏工程折中维护期间能否只查不改、能否接受排队更新、是优先快速恢复服务还是优先数据完整、故障时“处理中”的请求用户是否愿意重输、是否存在“流程 B 不可用则流程 A 也不许用”这类非技术性依赖。第 6 节“安全性”给的是一套对象—威胁—场景的清单法先确定需要保护的数据再确定威胁类型意外损坏、故意破坏、情报窃取、欺骗、未授权访问、恶意代码再确定物理安全威胁构件失窃、未授权物理访问、人身安全再确定威胁来源数据中心人员、其他 IT 人员、非 IT 员工、外部人员最后落到特殊安全需求访问控制、加密、可审计性。模板还要求区分对象在静态位置比如硬盘上和移动中传输期间的安全需求因为设计可能会把对象扩展到不安全区域。某些封装软件包自带安全子系统这时候要先搞清楚它的能力边界。3. 把模板填成可评审的 SRS三条落地路径模板看懂了和填得出来是两回事。这一章讲三件最耗时的活怎么干评测单元怎么切、可用性需求怎么分档写、安全性需求怎么列成清单。3.1 从业务流程切到评测单元切评测单元最容易犯的错是按组织架构切而不是按业务事务切。销售部下单、仓储部发货、财务部对账这是三个部门但可能只是同一个“订单履约”流程的三段。正确做法是先把业务流程列出来再往下拆到“一次可计数的业务事务”。我一般的操作顺序是这样的拉上业务方和开发列出全部一级业务流程用业务方的话命名不要用 IT 术语。每个一级流程往下拆到事务级标准是“这件事发生一次系统里会产生一次可观测的操作”。标出乘数关系一次上层流程会触发几次下层事务。一张订单 N 个商品就是 N 倍。对齐命名让开发和基础设施团队对同一个单元用同一个词模板里专门提醒过这件事不然后面对不上数。每个单元标注数据组和体量估算区间先给区间不给点值。第 2 步的“可观测”很关键。如果一件事在系统里看不出来发生过它就不该作为评测单元因为它没法验证也没法在性能测试里复现。3.2 可用性需求的分档写法与中断成本表可用性需求写成一句话基本等于没写。可评审的写法至少包含四个维度用户组、时间窗、功能范围、强制还是期望。我在实际项目里用下面这个 markdown 片段作为需求条目模板直接贴进 SRS 里评审时逐格填。### 可用性需求 AVL-003 !-- 用户组与时间窗必须同时写缺一个就无法验证 -- - 用户组一线受理岗约 120 人集中在时区 A - 时间窗工作日 08:00-20:00其余时间允许计划内维护 - 功能范围受理录入、状态查询 - 等级强制M/ 期望D - 指标单次不可用时长 ≤ 5 分钟月度累计不可用 ≤ 30 分钟 - 评测点前端拨测 服务端可用性日志双源比对 - 降级方案录入请求本地排队恢复后 15 分钟内补齐 - 未达标影响受理积压单小时积压约 80 单需加班消化参数说明等级这一栏是模板 5.1 里“区分希望和强制”的落地标 M 的进验收标 D 的只做监控告警评测点必须写两个源单源数据在争议时没有说服力降级方案对应模板里的“缩减功能”没有降级方案的高可用需求基本等于要求无限预算未达标影响是给决策层看的它决定了这条需求值不值得花钱。配套再做一张中断成本表按持续时间分档填这张表是后面定可用性标准的唯一依据。中断时长受影响流程业务影响可量化成本应急手段能抵消多少≤ 5 分钟受理录入可忽略无全部本地排队30 分钟受理 查询窗口排队变长需临时加开窗口约 70%2 小时全部受理当日积压加班成本 违约风险约 40%1 个班次全部受理当日业务中断需评估是否触发赔付条款基本无这张表填完你会发现很多“必须 7×24”其实是被夸大的——真正的高成本区间往往只集中在少数几个时间窗和少数几个功能上其余部分完全可以接受计划内维护。3.3 安全性需求的对象—威胁—场景三步清单安全性需求最怕写成形容词。模板给的方法拆开就是三步列对象、列威胁、做交叉。我把它落成一张三列表格一行一个对象逐格填。第一步对象清单要写到“可指认”的程度客户档案、交易流水、密钥材料、审计日志、配置基线。写“业务数据”这种粒度后面没法防护。第二步对每个对象列出侵害场景模板分了三类查看访问违反保密性、更新访问为了欺骗或转移而篡改、资产丢失所有权被他人获得区别于灾难造成的丢失。这三类要分开写因为防护手段完全不同——加密防查看完整性校验和审批链防篡改权限回收和介质管控防丢失。第三步把对象和威胁来源交叉。威胁来源至少覆盖运维人员、开发人员、非 IT 员工、外部人员。一个对象对不同来源的敏感度可能差很远比如审计日志对内部运维是高敏感的改日志能掩盖操作对外部人员反而价值有限。交叉完还要补一条模板里强调的检查同一个对象在静态位置和移动中的安全需求是否一致。硬盘上的密钥材料和传输中的密钥材料防护要求通常不是一回事。4. 写得能被测试需求条目改造与追溯SRS 写完只是第一步真正的考验是三个月后测试团队拿着它能不能写出用例。这一章讲两件事单条需求怎么改造成可验证的以及追溯矩阵怎么建才不流于形式。4.1 把形容词改成数字一条需求的改造过程“系统应具备良好的响应性能”——这句话在评审会上永远不会有人反对因为它不可证伪。改造它需要四步找出隐含的主体、找出隐含的时间窗、找出隐含的度量点、给出可接受区间。改造前改造后补了什么系统应具备良好的响应性能一线受理岗在高峰时段提交单条录入从点击提交到收到成功回执的 P95 ≤ 2 秒P99 ≤ 5 秒主体、时间窗、度量点、分位数系统应支持大量并发用户高峰时段同时在线受理岗 ≥ 300 人每人每分钟 4 次查询持续 30 分钟无错误率上升并发定义、操作模型、持续时长系统应保证数据安全客户档案在传输中加密静态存储的敏感字段加密审计日志保留 ≥ 180 天且不可由业务账号删除保护对象、状态区分、留存期、权限约束改造时有个经验凡是能用“P95/P99 时间窗 操作模型”表达的就别用平均值。平均值会把长尾抹平而线上投诉基本都来自长尾。4.2 追溯矩阵怎么建、怎么用追溯矩阵不是给评审看的装饰品它解决的是变更影响面问题。最简版本三列就够需求 ID、设计或实现载体、验证用例 ID。但要用得起来得加两列变更历史、关联的指定项。加“关联的指定项”这一列是因为第 2 节写的那些指定预选软件包、现有数据、特殊硬件一旦变动会连带影响一批需求。有了这一列指定项变更时你能一秒钟拉出受影响清单。加“变更历史”是为了在事后复盘时能回答“这条需求是什么时候、因为什么变成现在这样的”。维护节奏上我一般要求每次需求变更评审后 24 小时内更新矩阵宁可条目粗一点也不要攒到里程碑前一次性补——补出来的矩阵八成是错的。| 需求ID | 需求摘要 | 关联指定项 | 实现载体 | 验证用例 | 最近变更 | |--------|----------|------------|----------|----------|----------| | FR-012 | 受理单提交后生成流水号 | SPEC-01 预选包 | 受理模块 | TC-101/102 | 2024-05 增加幂等要求 | | NFR-021| 录入 P95 ≤ 2s | SPEC-03 现有网络 | 受理模块网关 | PT-201 | 2024-06 分位数口径调整 | | AVL-003| 受理岗工作日可用性 | - | 整体 | TC-301 | 首次建立 |这三列里关联指定项是很多团队会漏的漏了之后指定项一变需求、设计、用例三方全脱节。最近变更用一个短句记原因不记人名不记会议号只记“为什么改”。4.3 补充规约与 SRS 的边界划分这份模板对功能性需求和非功能性需求给了明确的归属建议功能性需求走用例模型和用例非功能性需求记录在补充规约里而 SRS 包是这些内容的集合。实操中边界容易糊我的划分习惯是这样用例里只写“系统对外表现出什么行为”也就是触发条件、主流程、异常流程、后置状态。响应时间、容量、可用性窗口、安全控制这些全部放补充规约用统一编号管理。这样做的直接好处是用例评审时不会被性能数字带偏性能评审时也不用翻几十个用例。代价是两边要对得上号。解决办法是在用例里挂一个“关联非功能需求”的引用字段评审用例时顺带确认引用的非功能条目是否还存在、是否已变更。这一步多花十分钟能省掉后面很多扯皮。5. 踩坑排查这套模板落地时最容易翻车的五处模板本身没问题问题出在“照着填”和“填完就不管”这两种用法上。下面五条是我自己踩过或者亲眼看着别人踩的按现象、原因、解决三段写。坑一假设清单填成了“已知条件清单”。现象是假设与问题那一节写得很漂亮全是“我们假设客户会提供测试环境”“我们假设数据可迁移”这类话评审时没人反对项目中期全部爆雷。原因是写的人把“假设”理解成了“我希望成立的事”而不是“我没有验证但暂时依赖的判断”。真正的假设必须带风险标记如果不成立影响哪几条需求、代价多大、谁来验证、什么时候必须验证完。解决方法是给每条假设加四个字段——影响面、验证责任人、验证截止时间、不成立时的备选方案。没有备选方案的假设要么立刻去验证要么升级成待解决问题。坑二指定项写成了“技术选型说明”。现象是指定那一节洋洋洒洒写了某个软件包多合适、性能多好但没写它锁死了什么。原因很常见——写的人是提案方天然倾向于论证选型正确。后果是设计阶段才发现这个包不支持某种部署形态或者它的数据组织方式与既有报表体系冲突。解决办法是把这一节改写成“约束清单”而不是“选型理由”每一条指定后面跟一行“因此不能做什么”。比如“选定该软件包”后面跟“因此屏幕设计、数据组织方式、批接口格式均由其决定不可自定义”。写不出“因此不能做什么”的指定说明你还没搞清楚它的约束范围。坑三评测单元切得太细或太粗。切太细的典型症状是数量那一节列了几百个事务每个都给了一组估算数字结果维护成本比收益还高第一次业务调整就全废了。切太粗的症状相反只有“订单系统”“结算系统”两三个单元性能标准没法细化测试团队拿到手不知道压什么。原因是切分标准不统一——有人按系统切有人按功能切有人按接口切。解决办法是统一到“一次可计数的业务事务”这个标准上并且限定层级一级业务流程 → 二级事务 → 三级数据组只对二级做量化三级只记数据元素数量。这样条目数可控颗粒度也够用。坑四可用性指标拍脑袋成本失控。现象是可用性那一节写了个 99.99%一算全年允许不可用时间不到一小时架构方案直接翻倍。原因是这个数字不是从业务成本倒推的是从“别人都这么写”抄来的。模板其实给了正确的路径先做中断成本表再看哪些时段、哪些功能的中断成本高到必须避免最后才写指标。解决办法是把指标拆到流程和用户组粒度上让高指标只覆盖真正高成本的部分。我经手的一个项目最后落成“受理录入工作日 99.9%报表查询 99.5%夜间批处理允许 2 小时窗口”成本比全系统 99.99% 低了将近一半业务方也认可因为高成本区间确实都被覆盖了。坑五安全需求写完没人认领。现象是安全那一节列了一堆威胁和场景但每条需求后面没有责任方实施时被当成“非功能性附加项”一拖再拖。原因是安全需求通常跨团队——应用团队管不了物理访问运维团队管不了代码里的加密实现。解决办法是每条安全需求都标一个“控制点归属”是应用层控制、平台层控制还是管理流程控制并对应到具体的责任团队。跨团队的那几条提前拉一次三方确认会确认不了的就写成风险项上报别让它安静地躺在文档里。这一条我吃过亏文档里写着“敏感字段加密存储”但没人认领密钥管理最后上线前两周才发现密钥轮换方案根本没设计。6. 进阶用法把 SRS 变成验收基线而不是归档文档这套模板真正的价值是在项目后期还能被拿出来用。我一般会在 SRS 定稿时多做一件事把每个大节里“可验收”的条目抽出来单独形成一张三列对照表需求条目、验证方法、验收判据。这张表不进正式文档但它是我做验收时的唯一依据。需求条目验证方法验收判据NFR-021 录入 P95 ≤ 2s压测 生产拨测连续三天高峰时段采样达标AVL-003 月度累计不可用 ≤ 30 分钟可用性日志双源比对月度报告无争议条目SEC-014 审计日志留存 ≥ 180 天抽查 配置核查任意连续 180 天可回溯这张表逼着我在写需求阶段就想清楚“怎么证明它做到了”。想不清楚的条目要么改写要么降级成监控项绝不让它带着“待定”的状态进入开发。它还有个副作用变更评审时只要这张表里某一行要改我就知道对应的验收动作也要改不会出现需求改了、验收标准还是老的这种典型翻车。另外一个习惯是给“计划中的服务时间”单独建一个日历。模板里说服务时间在系统生命周期内会变这一点太容易被忽略。我会把未来两年的业务节奏旺季、结算周期、法定假期、已知的业务调整标上去让设计人员一眼看到哪些窗口现在能用、什么时候会消失。这个日历每次业务调整后更新一次成本很低但能避免“按当前窗口设计的维护方案半年后就没窗口可用”这种后悔药。从那以后我每次评审 SRS都会强制走一遍这六个筐的归类再强制填一遍那张验收对照表填不出来的条目当场打回。需求写得漂亮不难难的是半年后还有人敢拿它去对账。希望帮到你。本文还有配套的精品资源点击获取
简介面向软件需求工程初学者与项目团队的一份IBM软件需求规约SRS格式模板与案例文档用于解决需求收集、组织和表述缺少统一框架的问题。文档以IBM Corporation提供的SRS结构为蓝本依次展开概述、指定、标准、数量、可用性、安全性六个章节并逐条说明假设与问题、地理组织、预选应用程序包、特殊硬件、现有数据、技术构架与网络构架、评测单元与业务量、计划服务时间与灾难恢复、安全性需求等条目分别应填写什么内容。文中还说明了SRS与前景文档的分工SRS作为项目成员参考标准以及测试和QA输入的作用功能性需求借助用例模型定义、非功能性需求记入补充规约并维护“假设与问题”清单的写法。压缩包内共1个doc文件约150KB轻量易读可直接作为撰写SRS时的对照清单与模板骨架。目前已有277人学习下载适合需要规范需求文档结构、查漏补缺的需求分析师、项目经理及软件工程课程学习者参考。1. 需求评审会上最怕的不是吵架是没人拿得出数字一个跨部门系统刚立项评审会就卡住了业务方说“必须 7×24 不能停”运维说“每晚得留停机窗口做备份”开发说“那就先按最高标准设计”。三方都没错但谁也说服不了谁因为桌上没有一份能把话逼到具体数字上的需求规约SRS模板。这份源自某老牌 IT 厂商统一过程体系的 SRS 案例把需求规约拆成概述、指定、标准、数量、可用性、安全性六个大节每一节都在追问同一件事这条约束是谁提的、代价多大、怎么测。它适合正在写第一版 SRS 的人也适合被“需求写了但没法验收”折磨过的项目经理和测试负责人。2. 六个大节的骨架每一节其实在替谁挡风险这份模板最值得抄的地方不是它的排版而是它把“需求”拆成了六类不同性质的约束前提类、指定类、标准类、容量类、可用性类、安全性类。这六类的责任人、验证方式、变更成本完全不同混在一起写最后必然变成一篇谁都不认的散文。我一般拿到一份 SRS 草稿先做一次“归类体检”把每一条需求扔进这六个筐里扔不进去的要么是废话要么是还没想清楚。下面这张表是我自己用的对照表来源就是这份模板的六个大节。大节它在逼你回答的问题缺了这一节的典型后果概述有哪些假设没验证、有哪些问题可能中断项目项目中期发现某个前提根本不成立返工指定哪些设计决策已经被提前锁死架构做完了才发现必须用某个既有软件包标准客户已有的架构和策略有哪些是硬约束交付时因不符合既有网络规范被驳回数量评测单元怎么切、业务量多大、性能标准多少上线后容量不够性能争议无法裁决可用性谁在什么时间需要什么功能、中断代价多大可用性指标拍脑袋定成本失控安全性保护什么、防谁、防到什么程度安全需求写成一句“系统应安全可靠”2.1 概述与指定先把“改不动的前提”钉在纸面上模板第 1 节“概述”里有两个容易被跳过的子项1.1 假设与问题、1.2 地理组织。这两项看着像填表实际上是整份 SRS 的地基。假设与问题要维护成两张清单——一张记录你在需求和设计流程中做出的所有假设以及做出这个假设的理由另一张记录所有可能中断项目推进的重要问题。模板特别强调这两张清单要在每个阶段结束时和客户一起复核但“不太重要的假设客户可能并不是合适的复核人选”这句话很实在不是所有假设都值得占用客户的时间内部先分层。地理组织这一项模板要求记录的不只是“客户在哪”还包括受系统影响的业务部门所在地、未受影响但装有主要 IT 设备的工作地点、所有移动办公部门比如长期出差、用工作站的岗位以及所有可能需要特殊自然语言支持的位置。我见过一个项目因为漏记了移动办公场景结果离线状态下的数据同步完全没进需求上线第一个月就被业务方投诉。第 2 节“指定”是整份模板里最“反直觉”的一节——它要求你在需求阶段就把那些会限制设计灵活性的东西全部写出来。包括预选的应用程序包、现有处理器或操作系统映像、现有工作站设备、现有网络、现有系统管理惯例甚至包括“必须采用客户机/服务器模型”这种架构级指定。预选软件包尤其要小心模板列了它可能连带锁死的一长串东西工作站类型、连接方法、处理器和存储类型、系统控制程序、数据组织与存放方式、编程语言、批处理接口、屏幕设计与最终用户界面、性能和可用性特征、打印数据格式、国家语言支持。写这一节的时候我习惯追问一句这个软件包一旦选定我们还能改什么提示指定这一节写完让架构师签字。签字的含义不是“同意”而是“我知道这些约束存在且没有异议”。2.2 标准与数量架构约束怎么落到可计数的口径第 3 节“标准”分四块技术构架与战略计划、网络构架、连接策略、其他策略。技术构架那一块模板给了一份很长的可发现清单——计算中心的数量和用途、企业广域网连接性、局部局域网连接性、中间件服务覆盖范围目录与命名服务、安全服务、时间服务、事务管理服务、将采用的开发方法、已接受的可支持产品集硬件、系统控制软件、常用应用软件、帮助台、安全规则、打印子系统构架。这份清单的价值在于提醒你客户的“技术架构”不是一张图而是一堆会落到你设计上的规则。网络构架那一块要记的是物理拓扑特征节点是密集还是松散分布、当前基础设施支持的高层连接功能、使用的通信标准、支持的编程接口以及对客户机/服务器各层之间连接性的规定。连接策略那一块更偏工程现实是否强制使用特定协议或通信设备、是否隐含依赖既有设备、是否沿用现有物理连接设施、如果需要安装或改造物理线路会牵扯哪些第三方、对移动用户的支持方式。其他策略里有一条很值得单独拎出来用户在本地自己写程序的策略。模板说得很直白——如果不加控制本地程序会很快耗尽生产系统所需的资源等到首次公开展示生产系统时你可能发现系统根本装不上。第 4 节“数量”是整份模板里实操性最强的一节。4.1 要求先定义“评测单元”和开发人员一起把业务流程切成更小的单元比如更小的业务流程或事务。这里有个必须注意的乘数问题——一个业务流程可能启动多个更小事务的实例一张订单里的多项商品就是典型记数量的时候要把乘数算进去。模板也提醒不要过度深究细节复杂系统尤其没必要精确到个位数。还有一句很关键不同人群对“事务”的理解不一样开发背景的人和基础设施团队说的往往不是一回事必须先对齐名称再做信息收集。4.2 业务量和大小要记录一般时段和高峰时段各有多少用户使用各业务流程、高峰期出现在什么时间粒度每天、每周、每月、高峰期和一般时段各需要多快的处理速度、每个数据组中数据元素和实例的数量及大小。4.3 业务流程性能标准要按类别记响应或周转需求、在哪里评测、非高峰时段是否可以接受不同标准、恢复或应急期间能否达到、是否需要性能保证、未达标对各方的影响、以及“业务流程被认为可用的最低性能条件”——也就是那条线以下系统算“不可用”而不是“慢”。最后这一条我特别看重它把“慢”和“挂”分开了事后追责时是唯一的依据。2.3 可用性与安全性用业务成本倒推技术指标第 5 节“可用性”是这份模板写得最细的部分细到有点啰嗦但啰嗦得有道理。5.1 给了一套四步法确定真实最终用户、他们执行的业务流程、执行时间分析服务可用或不可用会如何影响用户完成业务目标据此指定可用性需求注意预选软件包本身的结构可能就限制了你能否连续运行。模板里有两条原则值得反复读。第一条可用性需求要按较小粒度指定各流程、用户组、数据组不要给整个系统一个“全局”指标。它举的例子是与其写“系统必须每天 24 小时为两地用户提供服务”不如写“从 A 地时间早 7 点到晚 7 点A 地用户必须能对自己的数据执行事务处理从 B 地时间早 7 点到晚 7 点B 地用户必须能对自己的数据执行事务处理”——后一种写法下设计人员可以在一个时区仍处于工作时间时维护另一个时区的数据或构件。第二条区分“希望”和“强制”。模板的例子是自助取款终端必须每天 24 小时接受存款和取现希望 24 小时提供准确的余额查询但允许在凌晨某个固定一小时内中断且不超过 10 分钟。5.2 计划中的服务时间要按业务流程和用户组分别确定跨时区的用户组当作独立用户组处理并说明是否存在不需要应用的偶然时间段比如业务假期以便设计人员利用这些窗口做大规模维护。还要预判在系统生命周期内服务时间会怎么变系统与其他系统交互时服务时间会不会受对方影响5.3 服务中断成本要求把中断按持续时间分档1 分钟、数分钟、15 分钟、30 分钟、1 小时、2 小时、4 小时、一个班次、一天、多天逐档评估业务影响和财务成本并确定应急过程能抵消多少实际影响。模板还要求给出“缩减功能”方案完整功能是读取并更新记录缩减功能是先录入更新请求、排队等维护结束后再落库完整功能是读最新余额缩减功能是从可能不很新的备选来源读。缩减状态下也有底线比如过时数据不得超过 24 小时。5.4 可用性和恢复标准要用可测形式写给定分钟或秒数内被恢复的中断所占百分比给定周期内用户无法执行特定功能的最大时长。模板提醒不要指定不紧迫的标准因为那会显著抬高实施成本如果某类中断条件下算不出业务成本或风险通常说明这类条件不该写进标准。5.5 灾难恢复只覆盖真正关键的流程而且要问清楚恢复时间从灾难发生时算还是从决定切换时算、什么条件下决定异地恢复、异地数据要新到什么程度、首次异地恢复是什么时候、相对依赖同一批设备的其他应用优先级如何。5.6 的其他设计事项更偏工程折中维护期间能否只查不改、能否接受排队更新、是优先快速恢复服务还是优先数据完整、故障时“处理中”的请求用户是否愿意重输、是否存在“流程 B 不可用则流程 A 也不许用”这类非技术性依赖。第 6 节“安全性”给的是一套对象—威胁—场景的清单法先确定需要保护的数据再确定威胁类型意外损坏、故意破坏、情报窃取、欺骗、未授权访问、恶意代码再确定物理安全威胁构件失窃、未授权物理访问、人身安全再确定威胁来源数据中心人员、其他 IT 人员、非 IT 员工、外部人员最后落到特殊安全需求访问控制、加密、可审计性。模板还要求区分对象在静态位置比如硬盘上和移动中传输期间的安全需求因为设计可能会把对象扩展到不安全区域。某些封装软件包自带安全子系统这时候要先搞清楚它的能力边界。3. 把模板填成可评审的 SRS三条落地路径模板看懂了和填得出来是两回事。这一章讲三件最耗时的活怎么干评测单元怎么切、可用性需求怎么分档写、安全性需求怎么列成清单。3.1 从业务流程切到评测单元切评测单元最容易犯的错是按组织架构切而不是按业务事务切。销售部下单、仓储部发货、财务部对账这是三个部门但可能只是同一个“订单履约”流程的三段。正确做法是先把业务流程列出来再往下拆到“一次可计数的业务事务”。我一般的操作顺序是这样的拉上业务方和开发列出全部一级业务流程用业务方的话命名不要用 IT 术语。每个一级流程往下拆到事务级标准是“这件事发生一次系统里会产生一次可观测的操作”。标出乘数关系一次上层流程会触发几次下层事务。一张订单 N 个商品就是 N 倍。对齐命名让开发和基础设施团队对同一个单元用同一个词模板里专门提醒过这件事不然后面对不上数。每个单元标注数据组和体量估算区间先给区间不给点值。第 2 步的“可观测”很关键。如果一件事在系统里看不出来发生过它就不该作为评测单元因为它没法验证也没法在性能测试里复现。3.2 可用性需求的分档写法与中断成本表可用性需求写成一句话基本等于没写。可评审的写法至少包含四个维度用户组、时间窗、功能范围、强制还是期望。我在实际项目里用下面这个 markdown 片段作为需求条目模板直接贴进 SRS 里评审时逐格填。### 可用性需求 AVL-003 !-- 用户组与时间窗必须同时写缺一个就无法验证 -- - 用户组一线受理岗约 120 人集中在时区 A - 时间窗工作日 08:00-20:00其余时间允许计划内维护 - 功能范围受理录入、状态查询 - 等级强制M/ 期望D - 指标单次不可用时长 ≤ 5 分钟月度累计不可用 ≤ 30 分钟 - 评测点前端拨测 服务端可用性日志双源比对 - 降级方案录入请求本地排队恢复后 15 分钟内补齐 - 未达标影响受理积压单小时积压约 80 单需加班消化参数说明等级这一栏是模板 5.1 里“区分希望和强制”的落地标 M 的进验收标 D 的只做监控告警评测点必须写两个源单源数据在争议时没有说服力降级方案对应模板里的“缩减功能”没有降级方案的高可用需求基本等于要求无限预算未达标影响是给决策层看的它决定了这条需求值不值得花钱。配套再做一张中断成本表按持续时间分档填这张表是后面定可用性标准的唯一依据。中断时长受影响流程业务影响可量化成本应急手段能抵消多少≤ 5 分钟受理录入可忽略无全部本地排队30 分钟受理 查询窗口排队变长需临时加开窗口约 70%2 小时全部受理当日积压加班成本 违约风险约 40%1 个班次全部受理当日业务中断需评估是否触发赔付条款基本无这张表填完你会发现很多“必须 7×24”其实是被夸大的——真正的高成本区间往往只集中在少数几个时间窗和少数几个功能上其余部分完全可以接受计划内维护。3.3 安全性需求的对象—威胁—场景三步清单安全性需求最怕写成形容词。模板给的方法拆开就是三步列对象、列威胁、做交叉。我把它落成一张三列表格一行一个对象逐格填。第一步对象清单要写到“可指认”的程度客户档案、交易流水、密钥材料、审计日志、配置基线。写“业务数据”这种粒度后面没法防护。第二步对每个对象列出侵害场景模板分了三类查看访问违反保密性、更新访问为了欺骗或转移而篡改、资产丢失所有权被他人获得区别于灾难造成的丢失。这三类要分开写因为防护手段完全不同——加密防查看完整性校验和审批链防篡改权限回收和介质管控防丢失。第三步把对象和威胁来源交叉。威胁来源至少覆盖运维人员、开发人员、非 IT 员工、外部人员。一个对象对不同来源的敏感度可能差很远比如审计日志对内部运维是高敏感的改日志能掩盖操作对外部人员反而价值有限。交叉完还要补一条模板里强调的检查同一个对象在静态位置和移动中的安全需求是否一致。硬盘上的密钥材料和传输中的密钥材料防护要求通常不是一回事。4. 写得能被测试需求条目改造与追溯SRS 写完只是第一步真正的考验是三个月后测试团队拿着它能不能写出用例。这一章讲两件事单条需求怎么改造成可验证的以及追溯矩阵怎么建才不流于形式。4.1 把形容词改成数字一条需求的改造过程“系统应具备良好的响应性能”——这句话在评审会上永远不会有人反对因为它不可证伪。改造它需要四步找出隐含的主体、找出隐含的时间窗、找出隐含的度量点、给出可接受区间。改造前改造后补了什么系统应具备良好的响应性能一线受理岗在高峰时段提交单条录入从点击提交到收到成功回执的 P95 ≤ 2 秒P99 ≤ 5 秒主体、时间窗、度量点、分位数系统应支持大量并发用户高峰时段同时在线受理岗 ≥ 300 人每人每分钟 4 次查询持续 30 分钟无错误率上升并发定义、操作模型、持续时长系统应保证数据安全客户档案在传输中加密静态存储的敏感字段加密审计日志保留 ≥ 180 天且不可由业务账号删除保护对象、状态区分、留存期、权限约束改造时有个经验凡是能用“P95/P99 时间窗 操作模型”表达的就别用平均值。平均值会把长尾抹平而线上投诉基本都来自长尾。4.2 追溯矩阵怎么建、怎么用追溯矩阵不是给评审看的装饰品它解决的是变更影响面问题。最简版本三列就够需求 ID、设计或实现载体、验证用例 ID。但要用得起来得加两列变更历史、关联的指定项。加“关联的指定项”这一列是因为第 2 节写的那些指定预选软件包、现有数据、特殊硬件一旦变动会连带影响一批需求。有了这一列指定项变更时你能一秒钟拉出受影响清单。加“变更历史”是为了在事后复盘时能回答“这条需求是什么时候、因为什么变成现在这样的”。维护节奏上我一般要求每次需求变更评审后 24 小时内更新矩阵宁可条目粗一点也不要攒到里程碑前一次性补——补出来的矩阵八成是错的。| 需求ID | 需求摘要 | 关联指定项 | 实现载体 | 验证用例 | 最近变更 | |--------|----------|------------|----------|----------|----------| | FR-012 | 受理单提交后生成流水号 | SPEC-01 预选包 | 受理模块 | TC-101/102 | 2024-05 增加幂等要求 | | NFR-021| 录入 P95 ≤ 2s | SPEC-03 现有网络 | 受理模块网关 | PT-201 | 2024-06 分位数口径调整 | | AVL-003| 受理岗工作日可用性 | - | 整体 | TC-301 | 首次建立 |这三列里关联指定项是很多团队会漏的漏了之后指定项一变需求、设计、用例三方全脱节。最近变更用一个短句记原因不记人名不记会议号只记“为什么改”。4.3 补充规约与 SRS 的边界划分这份模板对功能性需求和非功能性需求给了明确的归属建议功能性需求走用例模型和用例非功能性需求记录在补充规约里而 SRS 包是这些内容的集合。实操中边界容易糊我的划分习惯是这样用例里只写“系统对外表现出什么行为”也就是触发条件、主流程、异常流程、后置状态。响应时间、容量、可用性窗口、安全控制这些全部放补充规约用统一编号管理。这样做的直接好处是用例评审时不会被性能数字带偏性能评审时也不用翻几十个用例。代价是两边要对得上号。解决办法是在用例里挂一个“关联非功能需求”的引用字段评审用例时顺带确认引用的非功能条目是否还存在、是否已变更。这一步多花十分钟能省掉后面很多扯皮。5. 踩坑排查这套模板落地时最容易翻车的五处模板本身没问题问题出在“照着填”和“填完就不管”这两种用法上。下面五条是我自己踩过或者亲眼看着别人踩的按现象、原因、解决三段写。坑一假设清单填成了“已知条件清单”。现象是假设与问题那一节写得很漂亮全是“我们假设客户会提供测试环境”“我们假设数据可迁移”这类话评审时没人反对项目中期全部爆雷。原因是写的人把“假设”理解成了“我希望成立的事”而不是“我没有验证但暂时依赖的判断”。真正的假设必须带风险标记如果不成立影响哪几条需求、代价多大、谁来验证、什么时候必须验证完。解决方法是给每条假设加四个字段——影响面、验证责任人、验证截止时间、不成立时的备选方案。没有备选方案的假设要么立刻去验证要么升级成待解决问题。坑二指定项写成了“技术选型说明”。现象是指定那一节洋洋洒洒写了某个软件包多合适、性能多好但没写它锁死了什么。原因很常见——写的人是提案方天然倾向于论证选型正确。后果是设计阶段才发现这个包不支持某种部署形态或者它的数据组织方式与既有报表体系冲突。解决办法是把这一节改写成“约束清单”而不是“选型理由”每一条指定后面跟一行“因此不能做什么”。比如“选定该软件包”后面跟“因此屏幕设计、数据组织方式、批接口格式均由其决定不可自定义”。写不出“因此不能做什么”的指定说明你还没搞清楚它的约束范围。坑三评测单元切得太细或太粗。切太细的典型症状是数量那一节列了几百个事务每个都给了一组估算数字结果维护成本比收益还高第一次业务调整就全废了。切太粗的症状相反只有“订单系统”“结算系统”两三个单元性能标准没法细化测试团队拿到手不知道压什么。原因是切分标准不统一——有人按系统切有人按功能切有人按接口切。解决办法是统一到“一次可计数的业务事务”这个标准上并且限定层级一级业务流程 → 二级事务 → 三级数据组只对二级做量化三级只记数据元素数量。这样条目数可控颗粒度也够用。坑四可用性指标拍脑袋成本失控。现象是可用性那一节写了个 99.99%一算全年允许不可用时间不到一小时架构方案直接翻倍。原因是这个数字不是从业务成本倒推的是从“别人都这么写”抄来的。模板其实给了正确的路径先做中断成本表再看哪些时段、哪些功能的中断成本高到必须避免最后才写指标。解决办法是把指标拆到流程和用户组粒度上让高指标只覆盖真正高成本的部分。我经手的一个项目最后落成“受理录入工作日 99.9%报表查询 99.5%夜间批处理允许 2 小时窗口”成本比全系统 99.99% 低了将近一半业务方也认可因为高成本区间确实都被覆盖了。坑五安全需求写完没人认领。现象是安全那一节列了一堆威胁和场景但每条需求后面没有责任方实施时被当成“非功能性附加项”一拖再拖。原因是安全需求通常跨团队——应用团队管不了物理访问运维团队管不了代码里的加密实现。解决办法是每条安全需求都标一个“控制点归属”是应用层控制、平台层控制还是管理流程控制并对应到具体的责任团队。跨团队的那几条提前拉一次三方确认会确认不了的就写成风险项上报别让它安静地躺在文档里。这一条我吃过亏文档里写着“敏感字段加密存储”但没人认领密钥管理最后上线前两周才发现密钥轮换方案根本没设计。6. 进阶用法把 SRS 变成验收基线而不是归档文档这套模板真正的价值是在项目后期还能被拿出来用。我一般会在 SRS 定稿时多做一件事把每个大节里“可验收”的条目抽出来单独形成一张三列对照表需求条目、验证方法、验收判据。这张表不进正式文档但它是我做验收时的唯一依据。需求条目验证方法验收判据NFR-021 录入 P95 ≤ 2s压测 生产拨测连续三天高峰时段采样达标AVL-003 月度累计不可用 ≤ 30 分钟可用性日志双源比对月度报告无争议条目SEC-014 审计日志留存 ≥ 180 天抽查 配置核查任意连续 180 天可回溯这张表逼着我在写需求阶段就想清楚“怎么证明它做到了”。想不清楚的条目要么改写要么降级成监控项绝不让它带着“待定”的状态进入开发。它还有个副作用变更评审时只要这张表里某一行要改我就知道对应的验收动作也要改不会出现需求改了、验收标准还是老的这种典型翻车。另外一个习惯是给“计划中的服务时间”单独建一个日历。模板里说服务时间在系统生命周期内会变这一点太容易被忽略。我会把未来两年的业务节奏旺季、结算周期、法定假期、已知的业务调整标上去让设计人员一眼看到哪些窗口现在能用、什么时候会消失。这个日历每次业务调整后更新一次成本很低但能避免“按当前窗口设计的维护方案半年后就没窗口可用”这种后悔药。从那以后我每次评审 SRS都会强制走一遍这六个筐的归类再强制填一遍那张验收对照表填不出来的条目当场打回。需求写得漂亮不难难的是半年后还有人敢拿它去对账。希望帮到你。本文还有配套的精品资源点击获取
