尧图网站建设 
简介“IBM需求规约案例”以软件需求规约SRS的编制为主线整理自IBM公司提供的需求规约格式模板面向需求分析师、项目经理及软件开发测试人员。文档详细划分了概述、指定、标准、数量、可用性、安全性六大章节并说明从前景文档到SRS包的活动工件流转、功能需求通过用例定义、非功能需求记录于补充规约等核心方法同时涵盖需求管理中假设与问题清单的维护要点。资源包共包含1个doc文档大小约150KB便于直接参考与套用目前已有276人浏览学习。配套案例有助于读者掌握规范化的需求组织思路在项目实践中快速搭建SRS框架并明确各类需求条目从而提升需求沟通与交付质量。1. 需求规约不是“写文档”它是把 IBM 模板里的六类信息逼出来写软件需求规约SRS这件事在很多团队里是被当成“交作业”处理的项目启动会开完负责人找份模板把功能列表贴进去评审会签个字然后文档就躺在共享盘里再没人打开。但 IBM Rational Unified Process 这套需求规约指南最反直觉的一点是它明确告诉你 SRS 不是一个文档而是一个“信息包”并且这个包是活的——开发照它写代码、项目经理拿它做进度对齐、测试照着它设计用例任何一个环节把它当摆设后面都会在验收阶段翻车。这份资源的价值不在模板本身而在它把需求拆成了六类必须回答的问题概述、指定、标准、数量、可用性、安全性。适合需求分析师、项目经理、QA 和刚接触规范化流程的开发工程师。2. SRS 到底是个什么“包”功能性需求走用例、非功能性走补充规约2.1 先纠正一个惯性SRS 是信息包不是装订成册的 Word模板里有一句反复强调的话并没有充分的理由让我们注重所用工具之间的差异重点应放在有效地收集和组织需求上而不是考虑所使用的工具。这句话放到今天依然能解决很多人的内耗。我见过不少团队在需求阶段花大力气统一文档格式、折腾模板样式结果真正该收集的信息反而没收集全。按 IBM 这套思路SRS 包可以由多个工件组成非功能性需求、设计约束这类文本内容放在补充规约里功能性需求放进用例模型和用例假设与问题列表单独维护。你在 Word 里写也好、在 wiki 里维护也好、用 Rational Rose 这类工具画用例图也好只要这些内容合在一起能回答“为了交付这些功能系统必须执行哪些操作”它们就是一个完整的 SRS 包。这份模板还把 SRS 定义为“活动的、有生命的工件”这一点直接戳中了很多项目的死穴。为了过 ISO 9000 审计团队把 SRS 编制好就放在角落里后面整个项目过程不再理会。如果 SRS 只是用来应付审计的那它唯一的作用就是让项目在验收时多一份没人看的存档。真正能用的 SRS 应该在开发、测试、验收全过程中被反复翻开。2.2 功能性需求与非功能性需求用例加补充规约的分工IBM 模板对需求类型和承载位置有明确的划分。功能性需求不鼓励全部堆在一个大文档里而是通过用例模型和用例来定义非功能性需求性能、可用性、设计约束、安全等记录在补充规约中。需求类型推荐承载位置典型内容常见错误功能性需求用例模型、用例业务流程、系统行为、角色交互全部写成编号列表无法追溯到场景非功能性需求补充规约性能指标、可用性窗口、设计约束泛泛写“系统要稳定”没有量化假设与问题独立维护的列表暂无法确认的事项、设计前提记录一次后不再复审需要留意的是实施人员在问题解决和性能定义阶段可能已经参与项目但真正确定“代码必须做什么”时依据是 SRS 包而不是早前讨论中的口头约定。模板提醒 QA 和测试小组也要参加早期讨论理解前景文档里的“前景”但他们的验收标准依然来自 SRS 包。2.3 三类读者决定了 SRS 怎么写SRS 包在不同角色手里作用完全不同。项目经理不太可能去读开发人员生成的代码并与前景文档直接比较他们的标准参考是 SRS 包用它作为与项目团队讨论的基准开发人员把 SRS 当成契约性协议——不在 SRS 包里的内容不应处理在 SRS 包里的内容就有责任交付测试和 QA 小组则用它来创建测试用例和 QA 过程确保系统确实满足提出的需求。这三类读者决定了写作方式每条需求都要能追溯到验收方式每个量化指标都要回答“谁来测、怎么测”。我在写 SRS 时有个习惯每写完一小节就在旁边标一个“可验证方法”哪怕是简单到“评审确认”或“上线后统计”也比裸写一条需求要好。这条习惯就是从这套模板的读者视角来的。3. IBM 模板六大章节逐项拆解每节该填什么、哪些是雷3.1 概述与指定假设、地理组织、预选软件包概述部分重点是“假设与问题”两个列表。模板明确要求收集并验证非功能性需求时应维护一个假设与问题列表并在每个阶段结束时与客户一起复审问题。我在实际项目里观察到这个列表是最容易写了就忘的。假设和问题要分开假设是你在需求和设计流程中作出的判断必须写明基本原理问题是可能中断项目进行的重要事项必须定期复审。地理组织这一小节很多人直接跳过但模板里明确要求记录客户的组织地点、受影响的业务部门、未受影响但安装主要 IT 设备的工作地点以及需要特殊自然语言支持NLS的位置。移动工作部门也要记录比如四处出差、使用工作站的销售团队。对一个跨国或多分支机构的项目来说这里漏一项后面做部署方案时就要返工。指定部分的四个问题决定了设计自由度章节要回答的问题设计影响预选的应用程序包是否强制用某个现成软件包可定制程度如何包会锁定工作站类型、连接方法、编程语言、业务逻辑甚至屏幕设计其他指定是否有现有处理器、操作系统映像、网络、系统管理惯例必须沿用直接压缩设计空间例如强制客户机/服务器模型特殊硬件是否指定特殊硬件设备需要记录硬件/软件前置条件、厂商支持、NLS 和加密设备考虑现有数据是否必须使用现有数据影响系统设计需记录数据所在系统、结构、大小、使用方和可用性特别要注意预选应用程序包这条。模板提醒影响指定程序包的因素同样会影响设计必须确认你能获得包的厂商、外部顾问或经培训的团队成员支持。不要以为这些知识很容易获得。封装包的灵活性差异很大有的允许大量定制有的完全固定这个判断必须在写 SRS 时完成而不是选型之后。3.2 标准技术架构、网络、连接策略的约束收集标准这一章是 SRS 最容易写成“摆设”的部分因为很多项目组觉得架构问题跟自己无关。模板列举的内容每一项都是硬约束客户是否有技术架构或 IT 战略计划其中是否定义了计算中心数量与用途、企业 WAN 连接性、设施 LAN、客户机/服务器中间件、目录与命名服务、安全服务、时间服务、事务管理服务、可支持产品集这里容易被忽略的是“记录的开放程度”。客户要求厂商独立性和互操作性到什么水平直接决定了设计能不能绑定具体厂商。如果存在技术架构文档几乎可以肯定设计必须与它保持一致。我一般会在这一节末尾加一行“架构兼容性结论”列出哪些子架构被强制、哪些被排除。网络架构和连接策略是另一个隐藏雷区。模板建议记录物理拓扑考虑网络在农村还是大城市、设备密集还是松散分布、通信标准SNA、OSI、TCP/IP、支持的编程接口、客户机/服务器层的连接性定义。连接策略里有一条很实际如果业务交互涉及国际性连接要了解第三方承包商、公用通讯公司的参与如何管理。此外还有移动用户支持。对今天的项目来说这部分还要补充云连接和混合网络场景但模板的提问方式依然适用。其他策略一节提醒最终用户接口是否必须按面向对象原则设计、是否必须基于客户机/服务器模型、是否按公开标准定义、NLS 标准特别是从右向左文本、安全策略。模板还专门问了一句用户或部门能否在工作站、服务器上自行开发本地程序这个问题非常现实——本地程序会很快耗尽生产系统资源等到首次公开展示时发现系统装不上。3.3 数量评测单元、业务量、性能标准的口径统一数量部分是 SRS 里信息密度最高的部分也是大多数人不知道从哪下手的地方。模板第一步不是问“系统要支持多少用户”而是先定义“评测单元”。要和应用程序开发人员合作把业务流程细分为更小的单元——业务流程、事务。为什么要先做这一步因为你得先确定计数对象才能记录数量。一个业务流程可能启动多个更小业务事务的实例比如一个客户订单里有多项订购商品记录数量时要记住这些乘数。但也不要过分深究细节尤其对复杂系统更是如此。模板特别点出一个协作难点IT 术语在不同人群里含义不同。“事务”对应用开发背景的人来说是一种意思对基础设施团队的人来说完全是另一种意思。不先把名称对应关系对齐后面收集到的“事务数”根本没法比较。业务量和大小要记录的内容包括平常时间和高峰期各有多少用户、什么时候是高峰期每天、每周、每月、高峰和平常需要以什么速度处理事务、每个数据组中数据元素和实例的数量及大小。这些数据是整个容量规划的黑匣子不填死的后果就是上线前做压测时没有基线。业务流程性能标准一节模板要求记录响应/周转需求、评测地点、不同时段是否接受不同标准、恢复或应急期间能否达标、是否需要性能保证、未达标的影响。还有两个很容易漏的点系统支持流程如备份和应用开发流程也有性能目标如果选择了封装应用程序解决方案必须知道如何访问它的性能特征——第三方提供这些数字可能要花时间现在就应该提出要求。3.4 可用性服务时间、中断成本、恢复标准与灾难恢复可用性章节是这套模板里写得最细的部分。模板给出的可用性建议方法很明确确定真实最终用户和业务流程、分析不可用性如何影响用户达成业务目标、指定直接反映用户需求的可用性需求。这里第一条原则就是按更小的粒度指定可用性需求按流程、用户组、数据组不要指定整个系统的全局需求。全局可用性有个经典反例模板里给了纽约和香港的例子。“系统必须每天 24 小时为纽约和香港用户提供服务”听上去很严格实际却剥夺了设计灵活性。改成“纽约时间上午 7 点到下午 7 点纽约用户必须能对他们的数据执行事务处理香港时间上午 7 点到下午 7 点香港用户必须能对他们的数据执行事务处理”设计人员就能在一个时区的工作时间之外维护另一个时区的系统。计划中的服务时间、服务中断成本、可用性和恢复标准这三节是层层递进的。服务中断成本要求从财务上量化影响短中断、数分钟、15 分钟、1 小时、2 小时、4 小时、换班、数天每种持续时长对应的业务损失不同。业务功能缩减是可以接受的替代方案比如“完整功能读取最新客户余额缩减功能从可能不很新的备选来源读取客户余额”。缩减功能要有限制条件过时数据不能超过规定时限。可用性和恢复标准按 RTO/RPO 的思路来写会更清晰多少比例的中断需要在给定分钟或秒数内恢复、在给定周/月/年内用户无法执行特定功能的最大时长。灾难恢复只选关键业务流程不必所有流程都做主备服务恢复时间从灾难发生时算还是从决定前往远程工作地时算这些口径都要写明。3.5 安全性数据分类、威胁场景与特殊需求排序安全性章节模板提供了一套可操作的流程确定需要保护的数据、确定威胁类型意外损坏、故意破坏、商业间谍、欺骗、黑客行为、病毒、确定物理安全威胁偷窃、未授权物理访问、人身安全、确定威胁来源数据中心工作人员、其他 IT 人员、组织内非 IT 人员、组织外人员、确定特殊安全需求访问控制、数据加密、可审核性。模板还给出了分类方法按逻辑或物理安全性列出需要保护的对象确定与各对象相关的侵害场景。典型类别是查看访问违反保密性、更新访问为欺骗、掩饰、资金转移而修改数据、资产丢失所有权被他人获得。注意不是所有对象对上述侵害场景都敏感。之后把威胁与具体侵害场景关联并检查对象在静态位置硬盘和移动中传输期间的不同安全状态。如果系统有特别苛刻的安全性要求模板建议找安全专家或安全从业者协助。判断标准很明确系统是否涉及高安全等级数据、资金清算系统、个人机密信息。我一般会在 SRS 的安全性章节末尾加一个“特殊安全要求是否成立”的确认项如果成立就让安全专家介入设计评审而不是由开发团队自行判断加密方案。4. 从前景到 SRS如何把“大概要什么”变成可验收的量化指标4.1 前景负责“为什么做”SRS 负责“必须做什么”模板明确指出 SRS 包与前景文档Vision相关事实上前景文档可用作 SRS 的输入但两个工件服务于不同需要通常由不同作者编写。项目阶段从概括性说明用户需要、目的、目标、目标市场、系统特性转移到如何在解决方案里实施这些特性的具体细节。这个转换项目经理要盯住如果 SRS 里还在写“提升用户体验”“提高运营效率”这类目标性描述说明前景的内容混进了 SRS。SRS 只回答一件事——为了交付这些功能系统必须执行哪些操作。前景文档回答的是系统为什么存在、为谁存在。4.2 评测单元先于数量命名对齐比数据收集更重要数量章节的第一动作不是收集数据而是拆分评测单元并做术语对齐。模板强调不同人群会对“单元”使用各自名称应用程序开发背景的人说“事务”是一种意思基础设施团队说“事务”是另一种意思。因此务必要通过相互协作使名称相互关联再进行信息收集。我实际操作时会先做一张“评测单元对齐表”列出业务流程、对应的应用程序、IT 事务、基础设施视角名称让各方确认同一件事。比如一个客户订单处理流程可能对应一个应用程序但内部有“查询库存水平”“生成客户信函”等多个事务在基础设施团队眼里这些事务又可能被归并为“在线交易请求”。对齐表做完数量收集才有意义。4.3 给每一条非功能需求配一个可度量指标量化是 SRS 从“文档”升级为“契约”的关键。IBM 模板给出了一系列可借鉴的量化模式维度模糊写法模板倾向的写法可用性系统必须高可用按用户组时间段拆分纽约用户工作时段内事务成功率 ≥ 99.5%性能系统响应要快高峰时段订单提交事务平均响应 ≤ 2 秒95 分位 ≤ 5 秒恢复故障后要尽快恢复RTO ≤ 30 分钟RPO ≤ 5 分钟数据丢失服务中断影响中断影响很大按中断时长分级1 小时内损失 X 元4 小时损失 Y 元模板还特意区分了“希望”和“强制”两类可用性特征。比如 ATM 应用必须 24 小时能存取款这是强制账户余额查询允许偶尔中断但只能发生在凌晨 3 点到 4 点这是希望。混在一起写设计和测试都没法判断优先级。另外如果某个可用性目标没达成也不会直接影响用户完成业务目标那它就不适合作为需求写进 SRS更合适的做法是留在前景文档里。5. 避坑指南SRS 评审中常见的五个翻车现场与应对5.1 五个典型翻车现场现象、原因、解决我在评审和审计中见到的 SRS 翻车案例大部分集中在这五个点上。第一条SRS 里只有功能清单没有非功能项。现象是文档通篇是“用户能查询订单”“系统能生成报表”评审会上测试问“性能指标呢”才意识到没写。原因是模板只用了功能性需求部分忽略了数量、可用性、安全性章节。解决方法是把第 4、5、6 章作为强制项每条功能至少配套一条可度量的非功能需求。第二条“系统必须 7×24 小时可用”这类全局指标无人能挑战。现象是评审会上这句写在最前面所有人默认它很严格实际设计时发现根本没有可行方案。原因是粒度太粗业务并没有要求所有功能全天候可用。解决方法是按用户组和业务时段拆分写成“工作日 8:00-20:00财务人员必须能完成日终结算操作结算功能年可用性 ≥ 99.9%”。第三条假设与问题列表建了但不复审。现象是列表里有十几条未确认事项到了设计阶段才发现其中一条假设直接否定了选型方向。原因是列表没有设复审时点和负责人。解决方法是为每一条假设和问题分配 owner把复审绑定到阶段评审或里程碑会议问题列表必须和客户一起过。第四条现有数据没盘点就开始做迁移设计。现象是系统升级时对接旧数据库发现数据结构、编码规则和数据量和早前预估完全不符。原因是 SRS 的 2.4 现有数据小节空着。解决方法是写数据盘点表数据位于什么系统、结构是关系型还是平面文件、大小、当前用户、不可用时间段、是否可移动或复制。第五条封装包的性能特征没有提前获取。现象是选完软件包到容量规划时供应商才告知性能数据需要额外付费或专项测试项目等了三周。原因是模板 4.3 的警告被无视——第三方提供数字需要时间现在就该提出要求。解决方法是选型阶段就把性能特征作为技术附件写入合同或采购单。5.2 评审 CheckList把避坑经验沉淀进模板我建议把上述五条整理成 SRS 评审的检查项每次评审会逐条过检查项通过标准功能与非功能齐全每项功能可追溯到一个或多个可度量非功能需求可用性按粒度拆分不存在整系统全局式“7×24”表述有强制/希望之分假设与问题已复审列表条目有 owner、有复审日期、问题已与客户确认现有数据已盘点有数据盘点表结构与迁移方案匹配封装包数据已就绪供应商性能特征已拿到或已书面约定获取日期这套 check list 不依赖具体工具无论是 Word 模板、wiki 还是专门的 ALM 系统都能直接套用。6. 交付前把 SRS 变成验收工具自检脚本与 15 分钟检查习惯6.1 用一段脚本快速检查 SRS 章节完整度SRS 是文本型资源但章节完整性检查可以自动化。我平时会把 SRS 大纲导出成纯文本跑一段 Python 脚本确认六个核心章节都在避免评审会现场才发现有人把“安全性”整章删了。import re import sys # SRS 大纲章节自检脚本 # 用法: python check_srs.py srs_outline.txt required [概述, 指定, 标准, 数量, 可用性, 安全性] path sys.argv[1] if len(sys.argv) 1 else srs.txt with open(path, encodingutf-8) as f: text f.read() missing [] for key in required: # 匹配一级或二级标题中包含关键词的行 if not re.search(rf^#\s*.*{key}, text, re.MULTILINE): missing.append(key) if missing: print([缺失章节], 、.join(missing)) sys.exit(1) else: print([OK] 六个核心章节齐全)这段脚本的逻辑是逐行匹配以#开头的标题只要某个核心关键词在任何层级的标题中出现就判定该章节存在。required列表可以按项目裁剪比如把“安全性”拆成“安全需求”和“隐私需求”两个关键词。path默认读取当前目录的 srs.txt实际使用时改成你的大纲文件路径即可。脚本只是文字层面的完整性检查不验证内容质量但它能在一分钟内拦住最基础的结构缺失。6.2 15 分钟逐章追问把模板当验收工具脚本跑完我会再做一遍 15 分钟的人工检查。六个章节各对应一个追问概述部分的假设与问题是否还有未确认项指定部分有没有强绑定现有系统的约束被遗漏标准部分的技术架构和连接策略是否和实际基础设施矛盾数量部分是否每个评测单元都有业务量和性能目标可用性部分是否区分了强制和希望安全性部分是否所有保护对象都有对应的侵害场景。这套习惯是从一次失败的项目学来的。那年我们做的系统在开发阶段一切顺利上线前测试才发现可用性指标压根没法验收——因为 SRS 里写的是“系统必须稳定运行”没有量化测试用例只能靠猜。从那以后我每次交付前都强制走一遍六章节追问确保整份 SRS 的每一条内容都能被测试或评审直接使用而不是一段“看起来合理但无法验证”的文字。希望帮到你。本文还有配套的精品资源点击获取 软件需求规约实战：IBM模板六大章节拆解与量化验收
简介“IBM需求规约案例”以软件需求规约SRS的编制为主线整理自IBM公司提供的需求规约格式模板面向需求分析师、项目经理及软件开发测试人员。文档详细划分了概述、指定、标准、数量、可用性、安全性六大章节并说明从前景文档到SRS包的活动工件流转、功能需求通过用例定义、非功能需求记录于补充规约等核心方法同时涵盖需求管理中假设与问题清单的维护要点。资源包共包含1个doc文档大小约150KB便于直接参考与套用目前已有276人浏览学习。配套案例有助于读者掌握规范化的需求组织思路在项目实践中快速搭建SRS框架并明确各类需求条目从而提升需求沟通与交付质量。1. 需求规约不是“写文档”它是把 IBM 模板里的六类信息逼出来写软件需求规约SRS这件事在很多团队里是被当成“交作业”处理的项目启动会开完负责人找份模板把功能列表贴进去评审会签个字然后文档就躺在共享盘里再没人打开。但 IBM Rational Unified Process 这套需求规约指南最反直觉的一点是它明确告诉你 SRS 不是一个文档而是一个“信息包”并且这个包是活的——开发照它写代码、项目经理拿它做进度对齐、测试照着它设计用例任何一个环节把它当摆设后面都会在验收阶段翻车。这份资源的价值不在模板本身而在它把需求拆成了六类必须回答的问题概述、指定、标准、数量、可用性、安全性。适合需求分析师、项目经理、QA 和刚接触规范化流程的开发工程师。2. SRS 到底是个什么“包”功能性需求走用例、非功能性走补充规约2.1 先纠正一个惯性SRS 是信息包不是装订成册的 Word模板里有一句反复强调的话并没有充分的理由让我们注重所用工具之间的差异重点应放在有效地收集和组织需求上而不是考虑所使用的工具。这句话放到今天依然能解决很多人的内耗。我见过不少团队在需求阶段花大力气统一文档格式、折腾模板样式结果真正该收集的信息反而没收集全。按 IBM 这套思路SRS 包可以由多个工件组成非功能性需求、设计约束这类文本内容放在补充规约里功能性需求放进用例模型和用例假设与问题列表单独维护。你在 Word 里写也好、在 wiki 里维护也好、用 Rational Rose 这类工具画用例图也好只要这些内容合在一起能回答“为了交付这些功能系统必须执行哪些操作”它们就是一个完整的 SRS 包。这份模板还把 SRS 定义为“活动的、有生命的工件”这一点直接戳中了很多项目的死穴。为了过 ISO 9000 审计团队把 SRS 编制好就放在角落里后面整个项目过程不再理会。如果 SRS 只是用来应付审计的那它唯一的作用就是让项目在验收时多一份没人看的存档。真正能用的 SRS 应该在开发、测试、验收全过程中被反复翻开。2.2 功能性需求与非功能性需求用例加补充规约的分工IBM 模板对需求类型和承载位置有明确的划分。功能性需求不鼓励全部堆在一个大文档里而是通过用例模型和用例来定义非功能性需求性能、可用性、设计约束、安全等记录在补充规约中。需求类型推荐承载位置典型内容常见错误功能性需求用例模型、用例业务流程、系统行为、角色交互全部写成编号列表无法追溯到场景非功能性需求补充规约性能指标、可用性窗口、设计约束泛泛写“系统要稳定”没有量化假设与问题独立维护的列表暂无法确认的事项、设计前提记录一次后不再复审需要留意的是实施人员在问题解决和性能定义阶段可能已经参与项目但真正确定“代码必须做什么”时依据是 SRS 包而不是早前讨论中的口头约定。模板提醒 QA 和测试小组也要参加早期讨论理解前景文档里的“前景”但他们的验收标准依然来自 SRS 包。2.3 三类读者决定了 SRS 怎么写SRS 包在不同角色手里作用完全不同。项目经理不太可能去读开发人员生成的代码并与前景文档直接比较他们的标准参考是 SRS 包用它作为与项目团队讨论的基准开发人员把 SRS 当成契约性协议——不在 SRS 包里的内容不应处理在 SRS 包里的内容就有责任交付测试和 QA 小组则用它来创建测试用例和 QA 过程确保系统确实满足提出的需求。这三类读者决定了写作方式每条需求都要能追溯到验收方式每个量化指标都要回答“谁来测、怎么测”。我在写 SRS 时有个习惯每写完一小节就在旁边标一个“可验证方法”哪怕是简单到“评审确认”或“上线后统计”也比裸写一条需求要好。这条习惯就是从这套模板的读者视角来的。3. IBM 模板六大章节逐项拆解每节该填什么、哪些是雷3.1 概述与指定假设、地理组织、预选软件包概述部分重点是“假设与问题”两个列表。模板明确要求收集并验证非功能性需求时应维护一个假设与问题列表并在每个阶段结束时与客户一起复审问题。我在实际项目里观察到这个列表是最容易写了就忘的。假设和问题要分开假设是你在需求和设计流程中作出的判断必须写明基本原理问题是可能中断项目进行的重要事项必须定期复审。地理组织这一小节很多人直接跳过但模板里明确要求记录客户的组织地点、受影响的业务部门、未受影响但安装主要 IT 设备的工作地点以及需要特殊自然语言支持NLS的位置。移动工作部门也要记录比如四处出差、使用工作站的销售团队。对一个跨国或多分支机构的项目来说这里漏一项后面做部署方案时就要返工。指定部分的四个问题决定了设计自由度章节要回答的问题设计影响预选的应用程序包是否强制用某个现成软件包可定制程度如何包会锁定工作站类型、连接方法、编程语言、业务逻辑甚至屏幕设计其他指定是否有现有处理器、操作系统映像、网络、系统管理惯例必须沿用直接压缩设计空间例如强制客户机/服务器模型特殊硬件是否指定特殊硬件设备需要记录硬件/软件前置条件、厂商支持、NLS 和加密设备考虑现有数据是否必须使用现有数据影响系统设计需记录数据所在系统、结构、大小、使用方和可用性特别要注意预选应用程序包这条。模板提醒影响指定程序包的因素同样会影响设计必须确认你能获得包的厂商、外部顾问或经培训的团队成员支持。不要以为这些知识很容易获得。封装包的灵活性差异很大有的允许大量定制有的完全固定这个判断必须在写 SRS 时完成而不是选型之后。3.2 标准技术架构、网络、连接策略的约束收集标准这一章是 SRS 最容易写成“摆设”的部分因为很多项目组觉得架构问题跟自己无关。模板列举的内容每一项都是硬约束客户是否有技术架构或 IT 战略计划其中是否定义了计算中心数量与用途、企业 WAN 连接性、设施 LAN、客户机/服务器中间件、目录与命名服务、安全服务、时间服务、事务管理服务、可支持产品集这里容易被忽略的是“记录的开放程度”。客户要求厂商独立性和互操作性到什么水平直接决定了设计能不能绑定具体厂商。如果存在技术架构文档几乎可以肯定设计必须与它保持一致。我一般会在这一节末尾加一行“架构兼容性结论”列出哪些子架构被强制、哪些被排除。网络架构和连接策略是另一个隐藏雷区。模板建议记录物理拓扑考虑网络在农村还是大城市、设备密集还是松散分布、通信标准SNA、OSI、TCP/IP、支持的编程接口、客户机/服务器层的连接性定义。连接策略里有一条很实际如果业务交互涉及国际性连接要了解第三方承包商、公用通讯公司的参与如何管理。此外还有移动用户支持。对今天的项目来说这部分还要补充云连接和混合网络场景但模板的提问方式依然适用。其他策略一节提醒最终用户接口是否必须按面向对象原则设计、是否必须基于客户机/服务器模型、是否按公开标准定义、NLS 标准特别是从右向左文本、安全策略。模板还专门问了一句用户或部门能否在工作站、服务器上自行开发本地程序这个问题非常现实——本地程序会很快耗尽生产系统资源等到首次公开展示时发现系统装不上。3.3 数量评测单元、业务量、性能标准的口径统一数量部分是 SRS 里信息密度最高的部分也是大多数人不知道从哪下手的地方。模板第一步不是问“系统要支持多少用户”而是先定义“评测单元”。要和应用程序开发人员合作把业务流程细分为更小的单元——业务流程、事务。为什么要先做这一步因为你得先确定计数对象才能记录数量。一个业务流程可能启动多个更小业务事务的实例比如一个客户订单里有多项订购商品记录数量时要记住这些乘数。但也不要过分深究细节尤其对复杂系统更是如此。模板特别点出一个协作难点IT 术语在不同人群里含义不同。“事务”对应用开发背景的人来说是一种意思对基础设施团队的人来说完全是另一种意思。不先把名称对应关系对齐后面收集到的“事务数”根本没法比较。业务量和大小要记录的内容包括平常时间和高峰期各有多少用户、什么时候是高峰期每天、每周、每月、高峰和平常需要以什么速度处理事务、每个数据组中数据元素和实例的数量及大小。这些数据是整个容量规划的黑匣子不填死的后果就是上线前做压测时没有基线。业务流程性能标准一节模板要求记录响应/周转需求、评测地点、不同时段是否接受不同标准、恢复或应急期间能否达标、是否需要性能保证、未达标的影响。还有两个很容易漏的点系统支持流程如备份和应用开发流程也有性能目标如果选择了封装应用程序解决方案必须知道如何访问它的性能特征——第三方提供这些数字可能要花时间现在就应该提出要求。3.4 可用性服务时间、中断成本、恢复标准与灾难恢复可用性章节是这套模板里写得最细的部分。模板给出的可用性建议方法很明确确定真实最终用户和业务流程、分析不可用性如何影响用户达成业务目标、指定直接反映用户需求的可用性需求。这里第一条原则就是按更小的粒度指定可用性需求按流程、用户组、数据组不要指定整个系统的全局需求。全局可用性有个经典反例模板里给了纽约和香港的例子。“系统必须每天 24 小时为纽约和香港用户提供服务”听上去很严格实际却剥夺了设计灵活性。改成“纽约时间上午 7 点到下午 7 点纽约用户必须能对他们的数据执行事务处理香港时间上午 7 点到下午 7 点香港用户必须能对他们的数据执行事务处理”设计人员就能在一个时区的工作时间之外维护另一个时区的系统。计划中的服务时间、服务中断成本、可用性和恢复标准这三节是层层递进的。服务中断成本要求从财务上量化影响短中断、数分钟、15 分钟、1 小时、2 小时、4 小时、换班、数天每种持续时长对应的业务损失不同。业务功能缩减是可以接受的替代方案比如“完整功能读取最新客户余额缩减功能从可能不很新的备选来源读取客户余额”。缩减功能要有限制条件过时数据不能超过规定时限。可用性和恢复标准按 RTO/RPO 的思路来写会更清晰多少比例的中断需要在给定分钟或秒数内恢复、在给定周/月/年内用户无法执行特定功能的最大时长。灾难恢复只选关键业务流程不必所有流程都做主备服务恢复时间从灾难发生时算还是从决定前往远程工作地时算这些口径都要写明。3.5 安全性数据分类、威胁场景与特殊需求排序安全性章节模板提供了一套可操作的流程确定需要保护的数据、确定威胁类型意外损坏、故意破坏、商业间谍、欺骗、黑客行为、病毒、确定物理安全威胁偷窃、未授权物理访问、人身安全、确定威胁来源数据中心工作人员、其他 IT 人员、组织内非 IT 人员、组织外人员、确定特殊安全需求访问控制、数据加密、可审核性。模板还给出了分类方法按逻辑或物理安全性列出需要保护的对象确定与各对象相关的侵害场景。典型类别是查看访问违反保密性、更新访问为欺骗、掩饰、资金转移而修改数据、资产丢失所有权被他人获得。注意不是所有对象对上述侵害场景都敏感。之后把威胁与具体侵害场景关联并检查对象在静态位置硬盘和移动中传输期间的不同安全状态。如果系统有特别苛刻的安全性要求模板建议找安全专家或安全从业者协助。判断标准很明确系统是否涉及高安全等级数据、资金清算系统、个人机密信息。我一般会在 SRS 的安全性章节末尾加一个“特殊安全要求是否成立”的确认项如果成立就让安全专家介入设计评审而不是由开发团队自行判断加密方案。4. 从前景到 SRS如何把“大概要什么”变成可验收的量化指标4.1 前景负责“为什么做”SRS 负责“必须做什么”模板明确指出 SRS 包与前景文档Vision相关事实上前景文档可用作 SRS 的输入但两个工件服务于不同需要通常由不同作者编写。项目阶段从概括性说明用户需要、目的、目标、目标市场、系统特性转移到如何在解决方案里实施这些特性的具体细节。这个转换项目经理要盯住如果 SRS 里还在写“提升用户体验”“提高运营效率”这类目标性描述说明前景的内容混进了 SRS。SRS 只回答一件事——为了交付这些功能系统必须执行哪些操作。前景文档回答的是系统为什么存在、为谁存在。4.2 评测单元先于数量命名对齐比数据收集更重要数量章节的第一动作不是收集数据而是拆分评测单元并做术语对齐。模板强调不同人群会对“单元”使用各自名称应用程序开发背景的人说“事务”是一种意思基础设施团队说“事务”是另一种意思。因此务必要通过相互协作使名称相互关联再进行信息收集。我实际操作时会先做一张“评测单元对齐表”列出业务流程、对应的应用程序、IT 事务、基础设施视角名称让各方确认同一件事。比如一个客户订单处理流程可能对应一个应用程序但内部有“查询库存水平”“生成客户信函”等多个事务在基础设施团队眼里这些事务又可能被归并为“在线交易请求”。对齐表做完数量收集才有意义。4.3 给每一条非功能需求配一个可度量指标量化是 SRS 从“文档”升级为“契约”的关键。IBM 模板给出了一系列可借鉴的量化模式维度模糊写法模板倾向的写法可用性系统必须高可用按用户组时间段拆分纽约用户工作时段内事务成功率 ≥ 99.5%性能系统响应要快高峰时段订单提交事务平均响应 ≤ 2 秒95 分位 ≤ 5 秒恢复故障后要尽快恢复RTO ≤ 30 分钟RPO ≤ 5 分钟数据丢失服务中断影响中断影响很大按中断时长分级1 小时内损失 X 元4 小时损失 Y 元模板还特意区分了“希望”和“强制”两类可用性特征。比如 ATM 应用必须 24 小时能存取款这是强制账户余额查询允许偶尔中断但只能发生在凌晨 3 点到 4 点这是希望。混在一起写设计和测试都没法判断优先级。另外如果某个可用性目标没达成也不会直接影响用户完成业务目标那它就不适合作为需求写进 SRS更合适的做法是留在前景文档里。5. 避坑指南SRS 评审中常见的五个翻车现场与应对5.1 五个典型翻车现场现象、原因、解决我在评审和审计中见到的 SRS 翻车案例大部分集中在这五个点上。第一条SRS 里只有功能清单没有非功能项。现象是文档通篇是“用户能查询订单”“系统能生成报表”评审会上测试问“性能指标呢”才意识到没写。原因是模板只用了功能性需求部分忽略了数量、可用性、安全性章节。解决方法是把第 4、5、6 章作为强制项每条功能至少配套一条可度量的非功能需求。第二条“系统必须 7×24 小时可用”这类全局指标无人能挑战。现象是评审会上这句写在最前面所有人默认它很严格实际设计时发现根本没有可行方案。原因是粒度太粗业务并没有要求所有功能全天候可用。解决方法是按用户组和业务时段拆分写成“工作日 8:00-20:00财务人员必须能完成日终结算操作结算功能年可用性 ≥ 99.9%”。第三条假设与问题列表建了但不复审。现象是列表里有十几条未确认事项到了设计阶段才发现其中一条假设直接否定了选型方向。原因是列表没有设复审时点和负责人。解决方法是为每一条假设和问题分配 owner把复审绑定到阶段评审或里程碑会议问题列表必须和客户一起过。第四条现有数据没盘点就开始做迁移设计。现象是系统升级时对接旧数据库发现数据结构、编码规则和数据量和早前预估完全不符。原因是 SRS 的 2.4 现有数据小节空着。解决方法是写数据盘点表数据位于什么系统、结构是关系型还是平面文件、大小、当前用户、不可用时间段、是否可移动或复制。第五条封装包的性能特征没有提前获取。现象是选完软件包到容量规划时供应商才告知性能数据需要额外付费或专项测试项目等了三周。原因是模板 4.3 的警告被无视——第三方提供数字需要时间现在就该提出要求。解决方法是选型阶段就把性能特征作为技术附件写入合同或采购单。5.2 评审 CheckList把避坑经验沉淀进模板我建议把上述五条整理成 SRS 评审的检查项每次评审会逐条过检查项通过标准功能与非功能齐全每项功能可追溯到一个或多个可度量非功能需求可用性按粒度拆分不存在整系统全局式“7×24”表述有强制/希望之分假设与问题已复审列表条目有 owner、有复审日期、问题已与客户确认现有数据已盘点有数据盘点表结构与迁移方案匹配封装包数据已就绪供应商性能特征已拿到或已书面约定获取日期这套 check list 不依赖具体工具无论是 Word 模板、wiki 还是专门的 ALM 系统都能直接套用。6. 交付前把 SRS 变成验收工具自检脚本与 15 分钟检查习惯6.1 用一段脚本快速检查 SRS 章节完整度SRS 是文本型资源但章节完整性检查可以自动化。我平时会把 SRS 大纲导出成纯文本跑一段 Python 脚本确认六个核心章节都在避免评审会现场才发现有人把“安全性”整章删了。import re import sys # SRS 大纲章节自检脚本 # 用法: python check_srs.py srs_outline.txt required [概述, 指定, 标准, 数量, 可用性, 安全性] path sys.argv[1] if len(sys.argv) 1 else srs.txt with open(path, encodingutf-8) as f: text f.read() missing [] for key in required: # 匹配一级或二级标题中包含关键词的行 if not re.search(rf^#\s*.*{key}, text, re.MULTILINE): missing.append(key) if missing: print([缺失章节], 、.join(missing)) sys.exit(1) else: print([OK] 六个核心章节齐全)这段脚本的逻辑是逐行匹配以#开头的标题只要某个核心关键词在任何层级的标题中出现就判定该章节存在。required列表可以按项目裁剪比如把“安全性”拆成“安全需求”和“隐私需求”两个关键词。path默认读取当前目录的 srs.txt实际使用时改成你的大纲文件路径即可。脚本只是文字层面的完整性检查不验证内容质量但它能在一分钟内拦住最基础的结构缺失。6.2 15 分钟逐章追问把模板当验收工具脚本跑完我会再做一遍 15 分钟的人工检查。六个章节各对应一个追问概述部分的假设与问题是否还有未确认项指定部分有没有强绑定现有系统的约束被遗漏标准部分的技术架构和连接策略是否和实际基础设施矛盾数量部分是否每个评测单元都有业务量和性能目标可用性部分是否区分了强制和希望安全性部分是否所有保护对象都有对应的侵害场景。这套习惯是从一次失败的项目学来的。那年我们做的系统在开发阶段一切顺利上线前测试才发现可用性指标压根没法验收——因为 SRS 里写的是“系统必须稳定运行”没有量化测试用例只能靠猜。从那以后我每次交付前都强制走一遍六章节追问确保整份 SRS 的每一条内容都能被测试或评审直接使用而不是一段“看起来合理但无法验证”的文字。希望帮到你。本文还有配套的精品资源点击获取