需求规约与追踪矩阵：订单系统需求分析实战笔记

简介IBM需求规约SRS格式模板与完整案例文档面向软件需求分析师、产品经理及项目管理人员用于规范收集、组织和编写完整软件需求。文档基于IBM提供的SRS编写指南系统梳理了六大核心部分——概述、指定、标准、数量、可用性与安全性并分别给出子项说明同时详解功能性需求可通过用例模型和用例定义、非功能性需求记录于补充规约以及SRS作为项目经理参考标准、开发人员实施依据和测试QA输入的重要作用。压缩包仅含1个doc文件约150KB内容预览已展示SRS框架目录及详细编写建议便于直接套用修改。目前已有276人学习下载适合需要掌握规范需求文档编写方法的软件工程从业者参考使用。1. 需求规约不是写文档它是开发、测试与验收共用的一把尺子做软件交付最怕的场面是开发说做完了测试说没测明白业务方说不是我要的。三方各执一词谁也拿不出能裁决的依据。IBM 需求规约要求解决的就是这个痛点——它不要求你写一份更厚的文档去应付评审而是把每一项真实需求拆成可验证、可追踪、有优先级的规约条目让同一句话能被开发、测试、验收各自引用、各自兑现。这篇笔记用一套订单管理系统的需求规约案例讲完整做法从条目标注、非功能需求写法讲到追踪矩阵和覆盖检查适合正被需求含糊、验收扯皮困扰的团队参考。2. 看懂 IBM 需求规约要求的骨架从用户需求到需求规约的逐层拆解这一章先把骨架立起来。IBM 需求规约要求不是一套格式模板而是一套分层和追踪的思考方式。很多团队拿到模板就往上填填完发现文档和开发各说各话根子就在于没搞清分层、没建好追踪。2.1 用户需求与需求规约的边界在哪IBM 的需求工程实践里最先被反复强调的不是格式而是分层。用户需求User Requirement是业务视角的诉求比如我要能快速查到订单需求规约Software Requirements Specification是把这条诉求翻译成开发能直接落地、测试能直接取证的技术描述系统应支持按订单号精确查询输入为空时阻止查询并提示查询结果应在 2 秒内返回。这个翻译过程是需求分析的核心工作。常见做法是先收集用户需求清单逐条问三个问题谁会用、在什么条件下用、做完以后怎么证明它好用。能回答这三个问题用户需求才能升级为需求规约条目回答不了的就先标待确认绝不能为了让文档看起来完整而硬写。我在实际配合团队时见过最典型的反面做法把用户需求原文原样贴进需求规约再在后面加一句由开发自行评估。这等于把分析工作甩给了开发最后实现出来的东西一定是按开发理解来的而开发的理解往往只覆盖了主流程。所以第一步不是写文档而是先把每一条用户需求都过一遍上面三个问题。2.2 需求规约的四大组成功能、质量、约束与验收标准一份能落地执行的需求规约通常由四部分组成缺一不可。功能需求回答系统做什么质量属性回答做到什么程度约束条件回答受限什么验收标准回答凭什么算做完。四者不是并列的四章而是每条需求身上的四个侧面。组成回答的问题典型写法功能需求系统做什么系统应支持按订单号查询订单详情非功能需求质量属性做得有多好订单查询接口在 100 并发下的平均响应时间不超过 2 秒约束条件不能做什么、受限什么系统必须部署在现有 Linux 服务器使用内部统一认证服务验收标准凭什么算做完对应需求条目后列出的可验证条件有一种很容易拆错的情况把系统应支持导出订单报表这种功能需求和导出 1 万行数据的报表应在 10 秒内完成这种性能需求写进同一条。这样做的后果是功能能验收、性能无法验收或者反过来需求评审会上吵半天。我一般会要求一条需求只表达一个意图性能、安全、可用性统一拆到非功能需求章节并在属性里标注它挂在哪个功能模块下。约束条件往往被当成反正大家都知道而省略。比如认证方式、部署环境、浏览器兼容范围这些一旦不写开发和部署阶段每人都有一套自己的假设等集成测试时才发现环境不匹配返工成本非常高。所以规约的第四部分约束条件宁可多写不可不写哪怕只是目标浏览器为 Chrome 与 Edge 的最新两个主版本这一句也能砍掉大量兼容性扯皮。2.3 需求条目怎么编号、怎么追踪需求规约区别于普通文档的另一个要点是每条需求有唯一的永久编号。编号规则要稳定、可读、支持扩展。我一般用三段式类型前缀-模块-序号例如 FR-OMS-001 表示订单管理模块的第 1 条功能需求NFR-PERF-002 表示第 2 条性能类非功能需求。编号一旦发布不允许复用或篡改删除的条目编号作废保留新增的条目往后顺延。编号之后还要给每条需求加属性字段。IBM 的需求管理实践中通常包括来源、优先级、稳定性、风险、工作量估计等属性。来源字段记录这条需求是谁提的、出于什么场景稳定性标记它是已经确认的基线需求还是可能变动的候选需求。这些属性是后面做变更影响分析和验收追溯的基础。追踪的意思是让每条需求与上层来源用户需求和下层实现设计模块、测试用例形成可双向查找的关系。最常见的载体是需求追踪矩阵行是需求条目列是设计文档章节、代码模块、测试用例编号。这个矩阵不需要等全部文档写完才做而应该在需求评审通过、设计启动时同步建立之后每次变更都维护它。矩阵断链是后面要重点避的坑第 5 章会展开。3. 把需求改写成可验证的规约原子性、无歧义与可测试性3.1 从系统应支持…到系统应在 3 秒内…的改写需求规约案例评审时评审人最喜欢挑的就是描述里的玄学词汇友好、高效、及时、合理、尽可能。这些词在业务会议上没问题放进规约就是灾难因为它们不可测试。改写的核心动作是给每个模糊词换上可测量的约束。模糊写法问题可测试写法系统应支持快速查询订单快速没有量化系统应支持按订单号精确查询从提交查询到结果完全展示P95 响应时间不超过 3 秒系统界面应友好友好无法验证新用户从进入下单页到完成首次下单在无培训情况下不超过 5 分钟路径不超过 4 个页面数据库应高效存储订单高效指向不明订单表在 1 亿行数据量下按订单号索引查询的单次扫描时间不超过 500 毫秒系统应尽可能保证可用性尽可能没有下限系统月度可用性不低于 99.9%即自然月不可用时间不超过 43 分钟改写的原则是面向验证写描述。每条需求写完问自己一句测试拿到这条能不能设计出明确的通过、不通过步骤如果不能就继续补充条件、量级和边界。比如查询结果应在 2 秒内返回测试仍然会问多少数据量下的 2 秒1000 万行和 1 亿行的表现完全不同。所以完整写法要带上数据规模、并发数和统计口径。还有一种常见误用是滥用支持二字。系统应支持用户自定义导出字段听上去没问题但自定义的边界在哪里是任意字段组合还是预设字段多选这属于需求开口。我一般会要求功能描述必须写清楚输入、处理、输出三段输入含格式和范围处理含规则输出含内容和格式。写不出处理规则的说明需求还没分析透宁可标待确认。3.2 质量属性需求性能、可用性、安全性怎么写质量属性是需求规约里最容易被注水的一章。很多团队的非功能需求就两行字系统稳定运行响应及时。写了等于没写。质量属性要发挥约束力必须写成可度量、可验收的条目否则上线后性能崩了文档里一个字都查不到只能靠现场救火。性能需求的写法有三要素场景、量级、统计口径。比如订单列表查询接口支持 200 并发用户在 500 万订单数据量下P95 响应时间不超过 2 秒P99 不超过 5 秒。场景说明是什么操作量级说明数据和并发规模统计口径说明是平均还是分位数。分位数比平均值更有工程意义因为平均值会被少数慢请求拉高掩盖性能劣化这一点做性能压测的团队应该深有体会。可用性需求要写清计算方式和容忍窗口系统月度可用性不低于 99.9%单次计划内维护时间不超过 30 分钟计划外不可用时间单月累计不超过 43 分钟。安全需求不要只写系统应安全可靠要落到认证方式、口令策略、权限模型、操作审计系统登录必须使用统一身份认证平台口令长度不少于 12 位订单导出操作必须记录操作人、时间与数据范围。质量属性里面最容易翻车的是把实现方案当验收标准。比如系统应使用缓存中间件提升订单查询性能这是设计决策不是需求。正确写法是订单详情查询在 200 并发、历史订单量 500 万的条件下P95 响应时间不超过 2 秒至于用什么缓存、用不用缓存那是架构师的空间。需求只定义目标和边界不指定手段否则技术栈一换需求文档就得跟着改。3.3 需求优先级MoSCoW 还是别的需求规约里每条需求都带有优先级。IBM 的需求管理实践中优先级的设置服务于两个目的一是指导迭代排期二是在范围冲突时提供取舍依据。优先级不标产品经理和开发各按各的理解排最后砍需求全凭嗓门大那不叫管理那叫吵架。MoSCoW 是常见做法Must必须有缺了系统不可用、Should应该有可暂缓但有明确价值、Could可以有资源允许时做、Wont本次明确不做但记录下来。我给每条需求标优先级时不光标字母还加一句理由。比如FR-OMS-003 订单状态流转Must因为状态不准直接导致财务对账错误。理由字段让优先级不是拍脑袋将来变更评审时翻得出来。优先级和风险要联动。一条 Must 需求同时风险很高应该提前拆解、提前出方案一条 Could 需求风险很高基本可以直接移到 Wont。我见过有的团队把优先级标在需求描述后面的一对括号里改描述时括号里的优先级经常被误删所以我更建议优先级作为独立属性字段和编号、来源、状态放在一起而不是混在自然语言段落里。4. 需求规约案例实操一个订单管理系统的规约从 0 到 14.1 案例背景与范围界定用一个虚构的模拟项目 X 来说清楚某公司要做一个订单管理系统替换现在靠邮件和表格传递订单信息的现状。业务方最初的需求描述只有一句话让销售能下单、能查单、能导出报表。按 IBM 需求规约要求的做法第一步不是写功能而是界定范围。范围界定要回答三件事系统为谁服务、系统做什么、系统明确不做什么。这个案例的系统使用方是销售员、订单审核员、财务人员和系统管理员。有两个当初不清不楚的边界支付环节是否在范围内——经过确认支付对接第三方支付平台本系统只记录支付结果不处理支付流程库存校验是否实时——确认后采用下单时校验库存快照不锁定库存。这两个决策如果不写进规约后面开发和测试必然产生分歧。非目标列表同样重要。比如本系统不做自动补货、不做客户关系管理、不做多仓库调拨这些明确砍掉的内容写进规约能避免开发过程中业务方不断追加顺手加个功能的请求。范围章节产生的是界限界限越清楚需求变更时的口径越统一。另外术语表也要在这里建立比如下单和提交订单是不是一个动作、审核驳回和取消的区别是什么这些不统一后面每条需求都会带着各自的方言。范围确定后需求规约案例就进入了条目标注阶段。我对每一类需求都采用统一的模板字段确保每条需求的信息结构一致下面是这个案例里使用的条目模板后面所有条目都按它填写。需求条目模板每条需求一行记录编号全系统唯一 ID : FR-OMS-001 模块 : 订单创建 来源 : 用户需求 UR-003销售下单场景 优先级 : Must 稳定性 : 已确认 描述 : 系统应支持销售员提交订单订单包含商品、数量、 收货地址与备注提交成功后系统生成唯一订单号并 返回给提交人校验失败时系统拒绝提交并给出具体 错误原因不生成订单。 验收标准 : 1. 合法输入提交后 2 秒内返回订单号 2. 库存不足时提示库存不足当前可用 3 件且不生成订单 3. 收货地址为空时阻止提交并定位到地址输入框 4. 同一订单号在系统中唯一不允许重复。模板的意义在于强制每条需求都想清楚来源、优先级和验收标准。很多团队习惯用散文段落写需求十条需求写一大篇评审时谁也没法逐条核对。改成结构化条目后每一条都可以独立评审、独立测试、独立追踪哪条有问题就改哪条不用整篇返工。4.2 功能需求的规约条目实例订单管理系统最核心的功能需求围绕订单全生命周期展开。下面用表格列出这个案例里的关键功能需求条目和它们的验收标准这是整个需求规约案例中最常被测试和开发引用的部分。需求ID描述验收标准摘要FR-OMS-001销售员提交订单系统生成唯一订单号合法提交 2 秒内返回订单号库存不足或地址为空时拒绝并提示FR-OMS-002按订单号或客户名称查询订单输入为空时阻止查询查询结果在 500 万订单量下 P95 不超过 2 秒FR-OMS-003订单状态按规则流转待审核→已审核→已发货→已完成允许取消非法状态迁移被拒绝并提示取消仅限待审核与已审核状态FR-OMS-004审核员对订单进行通过或驳回操作驳回必须填写原因驳回后订单回到可编辑状态并通知提交人FR-OMS-005将指定订单导出为 Excel 报表单次导出最多 1 万行导出文件列与订单列表页一致导出操作写入审计日志FR-OMS-003 是最容易出问题的条目因为状态流转隐含了状态机的合法性规则。规约里如果不写限制条件开发可能做出任意状态跳转的系统测试也会漏掉非法迁移的用例。所以我在描述里明确写出允许的迁移路径把不允许的迁移变成可测试的拒绝场景。测试拿到这条需求直接按状态迁移图生成正例和反例比对着系统乱点要靠谱得多。FR-OMS-005 的审计要求来源于约束章节里的安全需求功能需求与非功能需求在这里产生了关联。这也是为什么规约要支持编号引用而不是孤立罗列。每条功能需求背后往往挂着质量属性或约束评审时如果发现一条功能需求没有任何关联的质量属性反而要警惕要么这条需求本身没分析透要么质量属性漏写了。4.3 非功能需求与接口需求的规约写法订单管理系统的非功能需求分四类落地性能、可用性、安全与兼容性。每一类都按第 3 章的可度量原则写避免出现响应及时稳定运行这类空话。编号类别规约条目NFR-PERF-001性能订单查询接口在 200 并发、500 万历史订单数据量下P95 响应时间不超过 2 秒P99 不超过 5 秒NFR-PERF-002性能报表导出 1 万行数据从点击导出到文件生成不超过 10 秒NFR-AVAIL-001可用性月度可用性不低于 99.9%单次计划维护时间不超过 30 分钟并需提前 48 小时通知NFR-SEC-001安全登录使用统一认证平台口令不少于 12 位订单导出操作必须记录操作人、时间、查询条件与数据量NFR-COMP-001兼容性支持 Chrome 与 Edge 最新两个主版本导出文件兼容 Excel 2016 及以上版本接口需求单独成一节因为订单系统依赖外部支付平台和内部 ERP 系统。接口需求要写清楚交互对象、触发时机、数据格式和异常处理。比如当用户选择在线支付时系统应向支付平台发起下单请求并在收到支付结果回调后更新订单支付状态回调超时 30 秒未收到时系统应主动查询支付结果并标记订单为待确认状态。接口需求最常见的问题是只写正常路径不写异常路径。支付回调丢失、ERP 同步失败、接口超时这些场景在规约里一字不提开发和测试就默认不发生等上线后第一个故障永远来自这里。所以接口需求我要求至少覆盖三种异常超时、重复请求、数据不一致每条都要给出系统应有的反应。写成系统应对支付结果回调做幂等处理重复回调不得重复更新订单状态比对接支付平台这种描述不知道高到哪里去了。5. 需求规约的避坑指南5 个高频翻车点与排查方法5.1 需求条目里掺了设计方案现象规约里出现系统应通过缓存中间件存储订单数据数据库应使用分库分表方案存储订单这类句子。评审时没人在意开发也照做但后面架构调整时发现需求文档与设计文档冲突谁改谁说不清。原因写需求的人把怎么办当成做什么写进了需求。需求描述的是问题空间设计方案属于解空间两者混淆会让需求失去稳定性。技术栈一换需求就得跟着改等于需求被实现绑架。解决把设计类描述从需求条目里剥离改写为目标和边界。使用缓存中间件改成订单详情查询在 200 并发、500 万数据量下 P95 不超过 2 秒具体技术方案留给架构评审。排查时用一条标准自检删掉这条需求里的技术名词如果描述依然成立它才是需求。5.2 验收标准写成一切正常现象需求条目末尾的验收标准是功能正常界面无异常数据正确。测试看到这种验收标准根本没法写用例最后只能凭感觉执行测完一片争议。原因验收标准是评审时后补的写的人不敢写死怕实现不了自己担责于是用模糊措辞给自己留退路。但需求一旦含糊责任就顺着交付链路传给了下游最后吃亏的是整个项目。解决每条验收标准必须满足可观察、可判定。可观察指有明确的输入和输出可判定指有一个客观的通过条件。改写示范功能正常→输入合法商品与地址点击提交后 2 秒内返回订单号且生成的订单号符合 18 位数字格式。排查时逐条问测试负责人这条标准你能不能演给我看演不出来就回去改需求。5.3 等字把需求开出天窗现象描述里出现系统应支持 Excel、PDF 等格式导出或者校验订单信息的合法性如金额、数量等。测试按已列出的格式做了用例验收时业务方提出等字里还包括 CSV于是扯皮。原因中文书面语习惯用等收尾写需求的人沿用口语习惯把枚举列表变成了开放列表。开放列表在合同性质的需求文档里等于没有定义边界测试永远测不完验收永远有借口。解决规约里的枚举必须关死。要么全列系统应支持 Excel(xlsx) 与 PDF 两种格式导出要么给判断规则系统应支持导出格式由后端配置中心动态控制默认开启 Excel(xlsx) 与 PDF。排查全文见到等例如类似三个词就停下来追问补全列表或改为规则描述。这一条可以写进规约评审的检查清单里。5.4 需求变更后追踪矩阵断链现象发布前测试发现某条需求没有对应测试用例查下去发现这条需求是一周前新增的加了需求条目却没人维护追踪矩阵测试压根不知道。原因追踪矩阵在评审通过后建了一次之后需求和用例各自演化矩阵没人负责更新。时间一长矩阵从管理工具退化成摆设文档甚至没人敢动它怕一更新就暴露大量缺口。解决把追踪矩阵的维护责任落到具体角色并在需求变更流程里加一道关卡任何需求条目变更必须同步更新矩阵关联。更有效的做法是让矩阵从文档变成可核对的数据表用脚本定期比对需求编号和用例编号。第 6 章会给一个可落地的检查脚本把断链从人眼没发现变成机器自动告警。5.5 非功能需求最后补补成摆设现象需求评审前才发现文档里没有非功能需求章节于是花十分钟补了一段系统应保证稳定、高效、安全全员通过。上线后大促流量一来系统响应从 2 秒变成 30 秒运维翻文档找不到任何性能指标可对照。原因非功能需求被当成讲课用的概念实际排期时没人牵头收集。性能、可用性、安全指标需要和业务方、运维、安全团队逐一确认是个需要提前约谈的活不是写文档时顺手填的。解决把非功能需求的收集提前到范围界定阶段和功能需求访谈同步进行。哪怕初期只有订单查询 P95 不超过 2 秒月度可用性 99.9%两条也要先定下来形成基线后续再补充。没有基线的非功能需求就是摆设有基线哪怕模糊后续也有修正的依据。6. 用需求追踪矩阵验证规约覆盖一个能落地的检查技巧追踪矩阵的价值在于让每条需求都被测试覆盖变成可核对的客观事实。矩阵维护到后期最怕的是靠人眼比对。我一般会把规约和矩阵存成统一的文本格式然后用脚本自动检查两类问题规约里有没有编号重复矩阵里有没有规约条目未被任何测试用例引用。下面这个检查脚本按固定命名规则提取需求编号适用于规约条目按 FR-xxx-001、NFR-xxx-001 这类模式编写的团队。脚本本身不复杂胜在把人工比对变成了每次发版前都能跑的检查项。import re from collections import Counter PATTERN r\b(?:FR|NFR|UR)-[A-Z]-\d{3}\b def extract(path): with open(path, encodingutf-8) as f: return re.findall(PATTERN, f.read()) srs extract(srs.md) # 需求规约文档 matrix extract(matrix.md) # 需求追踪矩阵文档 srs_dup {k: v for k, v in Counter(srs).items() if v 1} matrix_only set(matrix) - set(srs) uncovered set(srs) - set(matrix) print(规约编号重复:, srs_dup or 无) print(矩阵引用不存在的编号:, matrix_only or 无) print(未被矩阵覆盖的需求:, uncovered or 无)脚本逻辑分三步从需求文档提取全部需求编号从追踪矩阵文档提取被引用的编号然后做集合差运算。编号重复是规约维护中最容易犯的低级错误一旦两条需求共享一个编号追踪和测试引用就全部错乱矩阵引用不存在的编号说明需求被删过但矩阵没清理规约条目未被矩阵引用说明这条需求没有对应的设计或测试环节属于覆盖率缺口。用的时候要注意脚本默认规约和矩阵都是 Markdown 文件且编号格式严格统一。如果团队用 Word 或 Excel 维护先把内容导出为纯文本再跑或者改用表格工具的批处理功能。这个检查的频率我习惯放在每次需求基线确立和每次发版前跑一遍输出告警再按第 5 章的排查方法逐条处理。矩阵不是给评审做样子的它是给交付兜底的。需求规约写得好不好不看文档厚不厚就看这些检查和追踪能不能坚持做下去希望帮到你。本文还有配套的精品资源点击获取