简介：软件需求规格说明书模板（通用版）面向产品经理、需求分析师与项目初期团队，用于在开发启动阶段明确目标、范围与验收边界，缓解需求表述含糊、接口与非功能项遗漏等常见问题。整份文档共27页、逾一万字，按引言、编写目的、需求分析理论与目标、参考文献、需求概述、系统功能需求、用户界面、硬件与网络需求、接口需求及其他非功能需求组织，并附版本更新记录与审核确认栏，示例覆盖移动办公、车辆管理、电子公文预览等场景，便于直接套用章节结构与表述口径。压缩包内含1个doc文件，约1.29MB，适合作为需求评审、课程作业或企业文档规范的参照底稿。已有10955人学习下载，可作为中初级需求岗位与软件工程学习者快速建立文档框架的实用范本。
1. 一份 27 页的需求规格说明模板，到底能省掉多少返工
评审会上最常见的一幕：开发指着需求文档问「这条到底要不要做」，写文档的人翻回去，那一页只有一句「提供附件下载功能」。这类争执表面上是在沟通上出了岔子，实际上是需求文档缺少可判定的边界。手头这份软件需求规格说明书模板（通用版）就是用来堵这个缺口的：27 页、17 章，正文前带版本更新表和供应商与客户方双栏审核确认页，功能章节里保留了移动办公升级、车辆管理、电子文档预览、门户信息发布四组真实细分程度的示例。它适合两类人：第一次要交需求文档、不知道每一章该写多细的开发者，以及需要把乙方交付物卡在评审线上的甲方接口人。需求模板好不好用，不看章节多不多，要看它能不能逼你把「谁在什么条件下做什么、做到什么程度算完成」写清楚。
2. 拆开 27 页骨架：17 章怎么裁成能签字的 8 章
2.1 章节分五段：哪些是门面，哪些是骨头
把目录通读一遍，17 章其实分成五段，每段承担的验收责任完全不同。先把这张表看明白，再决定砍谁：
| 段落 | 包含章节 | 承载什么 | 裁剪建议 |
|---|---|---|---|
| 元信息 | 第一章至第五章：引言、编写目的、软件需求分析理论、软件需求分析目标、参考文献 | 文档定位、方法论依据、引用来源 | 理论章可并入编写目的；编写目的与参考文献建议保留 |
| 需求概述 | 第六章：项目背景、需求概述、条件与限制、系统结构、网络拓扑图结构 | 范围边界、系统组成、外部依赖 | 全部保留；条件与限制最容易被写成空话 |
| 功能需求 | 第七章：系统功能需求（四个模块） | 可验收的功能清单 | 全部保留，且必须从两列扩成四列 |
| 外部接口与环境 | 第八至十三章：用户界面、硬件、网络、接口、通信、运行环境 | 系统与外部世界的接触面 | 按项目类型裁，纯软件项目可把硬件与通信合并成一节 |
| 非功能 | 第十四至十七章：性能、安全设施、安全性、扩展性（含可移植性） | 质量属性与约束 | 全部保留，但每条必须有数字或可判定条件 |
选型理由值得说一下。这份模板把「软件需求分析理论」和「软件需求分析目标」单列成两章，不是凑页数，而是给评审方看的方法论依据，大规模定制项目、集成类项目在评审时经常被要求回答「你按什么方法做的需求分析」。但如果是内部产品团队自用，这两章可以直接合并进「编写目的」的一段话里，把省下来的篇幅让给接口和非功能章节。
真正反直觉的判断是：前五章占了篇幅却几乎不承载验收信息，删掉它们不会让文档质量下降；而第八到十七章这些外部接口与环境、非功能章节，最容易被一句「满足业务需要」带过去，偏偏它们才是上线后争议最集中的地方。裁剪顺序应该从支撑性内容往核心内容砍，反过来砍，就等于把最关键的支撑部分削掉了。
2.2 版本更新表：三行记录决定需求基线可不可信
模板正文前那张表有四列：版本号、时间、更新人、更新摘要。示例里三行分别对应 V1.0 的移动办公与车辆管理模块需求、V1.1 的平台需求、V1.2 的电子文档在线预览需求。这个粒度的摘要就是合格线，它能让别人不打开正文也知道哪块动了。
我一般按这四条规则填：
- 版本号用主.次两段。范围发生变化，也就是加了模块、删了模块、改了验收口径，升主版本；只是条目措辞修订、补边界值，升次版本。
- 时间以评审通过日为准，不以起草日为准。起草日写进去，后面追溯变更时对不上任何一次会议记录。
- 更新人写具体责任人，不写部门。部门会调整，人也会换岗，但至少要能追到当时是谁改的。
- 更新摘要写到「模块 + 需求类型 + 编号区间」这一层。
给一个填好的样子：
| 版本号 | 更新轮次 | 更新人 | 更新摘要 |
|---|---|---|---|
| V1.0 | 第 1 次评审 | 某开发者 | 移动办公、车辆管理模块功能需求，REQ-OA-001～REQ-OA-024、REQ-CAR-001～REQ-CAR-018 |
| V1.1 | 第 2 次评审 | 某开发者 | 新增门户信息发布平台需求，REQ-GOV-001～REQ-GOV-012 |
| V1.2 | 签字冻结 | 某开发者 | 新增电子文档在线预览需求，REQ-DOC-001～REQ-DOC-008 |
提示：更新摘要写「修改若干需求」，等于没写。半年后有人问「5M 附件不预览这条是什么时候加的」，你只能整本翻。
2.3 页眉页脚、编号与占位符：交稿前的三项机械检查
模板里页码是「第 X 页 共 27 页」的形式。这个「27」如果是手敲的，只要中间插一页就全错，而且错得很隐蔽——目录页码对得上，页脚全错。
Word 里的正确做法是用域，不是手打：
- 双击页脚进入编辑态，按 Ctrl+F9 插入域标记，在花括号里写
PAGE，得到当前页；再插一个写NUMPAGES，得到总页数。写成第 { PAGE } 页 共 { NUMPAGES } 页。 - 章节编号不要手敲。把「第一章」这一级关联到「标题 1」样式，把「1. 2. 3.」这一级关联到「标题 2」样式，用多级列表把编号和样式绑死。模板里第六章用「1. 2. 3.」，第七章又从「1.」重新起编，绑完样式后要在每章第一个二级标题上设置「重新开始于 1」，否则会一直累加下去。
- 目录用「引用 → 目录 → 自动目录」，不要手工敲点线。交稿前按 Ctrl+A 全选，再按 F9，选「更新整个目录」。
- 模板里多处保留了【说明……】这样的方括号占位符，起草阶段留着当填写提示是好事，交稿前必须清空。查找「【」逐个确认，比通读一遍快得多，也不会漏。
审核确认页是这张文档的另外半条命。模板把它分成供应商方和客户方两栏，各含姓名、职位、审核时间和审核意见（签字）。两栏分开的意义在于：一份需求文档背后有两个责任主体，一方说「我要的就是这个」，另一方说「我做的就是你要的」，签字页是未来争议时唯一能拿出来的凭据。签字之前必须冻结版本号，签字之后再改，就得走变更记录，不能偷偷改正文再换个日期。
3. 功能需求写到可测：把「模块 + 功能」两列拆成四列
3.1 两列功能表的局限与四列改造
模板第七章第 1 节那张表，是全篇最典型也最需要改的地方。它的结构是「功能模块 | 实现功能」两列，二十多行，从登录、待办待阅、收文审批一路写到短信中心。作为范围清单它很清楚，作为验收依据它是不够的：每一行都不可判定。「待办」到底做到什么程度算完成？「车辆费用管理」登记到什么字段算合格？没人知道。
我会把它扩成四列：
| 编号 | 行为描述（触发 → 动作 → 结果） | 前置与约束 | 验收判据 |
|---|---|---|---|
| REQ-OA-003 | 用户登录后进入待办待阅列表，列表按速级与接收时间倒序展示未办结文档 | 仅展示本人及已授权范围内的条目 | 登录后进入列表不超过 3 秒；条目数与 OA 端一致；点击进入详情 |
| REQ-OA-011 | 用户提交审批意见时选择下一环节与人员，提交后生成流转记录 | 下一环节数量 1～4 个；默认环节默认人员时不弹选择框 | 选择 4 个环节可正常提交；选 5 个时阻断并提示；流转记录可在详情查看 |
| REQ-CAR-006 | 驾驶员登记加油记录，保存后自动计入车辆费用台账 | 车牌号必填且必须存在于车辆档案 | 保存后台账金额累加正确；车牌不存在时阻断保存并给出提示 |
四列的划分逻辑是：编号负责可追踪，行为描述负责可理解，约束负责可复现，验收判据负责可判定。第三列最容易被漏，但它是测试同学唯一能拿来构造用例的东西。比如「仅展示本人及已授权范围内的条目」这一句，背后对应的是权限矩阵和越权用例，没有它，开发按「全部展示」实现也说得过去。
验收判据要写成第三方拿着文档就能执行的样子。「体验流畅」「操作便捷」这种词直接删掉，换成可观察的结果：页面上出现什么、多久之内出现、数量对不对、错误时提示什么。
3.2 界面级需求：两行显示、排序键与 5M 阈值
模板第七章里有一段写得很细，值得当作范例来抄：待办文档列表采用两行显示，第一行是速级图标、业务种类、接收时间，第二行是文档标题；排序按业务种类、速级（特急、急件、平件）、接收时间。这种写法比「列表要清晰美观」强一百倍，因为它把元素集合和排列顺序都固定了。
但它还差一口气：三个排序键之间的优先级和升降序没写。业务种类和速级谁优先？同速级怎么排？这些留给开发，就是三套实现。补全的写法是「先按速级降序（特急 > 急件 > 平件），同速级按接收时间降序，业务种类作为分组表头而非排序键」。
界面需求我一般按六个断言来组织：
| 断言类型 | 要写清什么 | 例子 |
|---|---|---|
| 元素集合 | 有且仅有哪些字段 | 收文详情：来文单位、紧急程度、标题、内容摘要、意见 |
| 排列顺序 | 从上到下的字段顺序 | 标题在第二行，独占一行 |
| 排序规则 | 排序键、优先级、升降序 | 速级降序 → 接收时间降序 |
| 空态 | 无数据时显示什么 | 显示「暂无待办」并保留刷新入口 |
| 超长处理 | 截断还是换行，截断几位 | 标题超过 20 字省略号截断，详情页完整显示 |
| 权限差异 | 不同角色看到的差异 | 普通用户不显示「督办」入口 |
边界值则用「四件套」写：阈值、行为、提示文案、例外。模板里关于附件的描述就是现成素材——文档正文支持 Tif、Doc、ceb 三类；附件类型不设限，其中 Office 系列、图片、Tif 可在手机端直接浏览；超过 5M 的文件提供下载但不能在手机端预览。把它整理成表格：
| 边界项 | 阈值 | 行为 | 提示与例外 |
|---|---|---|---|
| 正文格式 | Tif / Doc / ceb | 直接渲染 | 非上述格式拒绝上传 |
| 附件预览 | ≤ 5M 且属于 Office/图片/Tif | 直接打开 | 无 |
| 附件下载 | > 5M 或类型不在白名单 | 只提供下载 | 提示「文件超过 5M，请下载后查看」 |
| 附件类型 | 不设限 | 允许上传 | 不可预览的类型仅显示图标 |
这四行写进去，测试用例基本就自动生成出来了：5M 整、5M 加 1 字节、刚好不在白名单的格式、上传后预览失败的回退路径。模板原文写的是「超过 5M 的文件将提供下载功能但不能在手机端直接预览」，差的就是把「5M」这个数字和提示文案固化下来——数字在，判据就在。
3.3 时序类需求：交换五步与两类回执
模板第七章第 3 节电子文档交换那段，是整份文档里最有工程价值的部分。它描述的不是一个界面，而是一条跨系统的消息链路：OA 交换、OA 前置、交换接口、交换核心、CA 认证五个参与者，数据从生成、签名加密、传输、验签解密到入库五个步骤，中间穿插两类回执。
这类需求不能按功能点写，要按「谁在什么时候给谁发什么」写：
| 步骤 | 责任方 | 输入 | 输出 | 失败分支 |
|---|---|---|---|---|
| 1 生成与签名 | 发送方 OA 交换 | 原始交换对象 | 带签名的交换 XML | 签名失败则本地报错，不发出 |
| 2 提交前置 | OA 前置 | 交换 XML | 按同步或异步通道投递 | 通道不可用则返回失败回执 |
| 3 路由与拆分 | 交换核心 | 解密后的明文 | 按接收单位数 N 拆成 N 份并分别加密 | 路由查不到则返回失败回执 |
| 4 投递 | 交换接口 → 接收方前置 | 单接收方密文 | 送达接收方 | 网络超时则重试，超限返回失败回执 |
| 5 入库与回执 | 接收方 OA 交换 | 密文 | 解析入库成功回执 | 解析、解密、验签、入库任一失败均返回失败回执 |
这张表补上了模板原文没写但必须写的三样东西。第一是超时与重试：第 4 步网络超时后重试几次、间隔多久、超过次数怎么处理。第二是幂等：同一交换件被重复投递时不能重复入库，所以要有一个交换件唯一标识做去重键，这条不写，生产环境一定会出现重复待办。第三是回执闭环：模板原文把回执分成送达回执和解析入库回执两类，失败时还有失败回执，这个设计的关键在于——发送方知道「送到了」不等于知道「对方能看了」，两段确认必须分开写，否则验收时没法证明系统真的闭环。
注意：时序类需求的验收判据不是「功能可用」，而是「断网、超时、重复投递、验签失败这四种异常下，回执状态是否正确」。写需求时就把这四种异常列进验收条目，测试阶段能省一轮返工。
4. 非功能与接口：把「稳定、安全、快」写成可验收的数字
4.1 性能需求：五个必须写死的维度
模板第十四章性能需求只有一页，这是整份文档里最容易写空的一章。常见的填法是「系统响应速度快、支持多用户并发」，这种句子写完等于没写，因为没有任何一方能拿它来判定合格与否。
我按五个维度拆：
| 维度 | 定义 | 必须附带的测量条件 | 写法示例 |
|---|---|---|---|
| 并发 | 同时在线并产生操作的用户数 | 峰值时段、操作类型分布 | 工作日 8:30–9:30 峰值并发 300，其中 60% 为列表查询 |
| 响应时间 | 从触发到首屏可见 | 终端档位、网络制式、数据量 | 中档终端、WLAN 环境下，待办列表首屏 ≤ 3 秒，详情页 ≤ 2 秒 |
| 吞吐 | 单位时间处理的消息量 | 消息大小、批处理还是实时 | 文档交换峰值 500 件/小时，单件平均 800KB |
| 批量窗口 | 定时任务的允许运行时长 | 起始时间、与在线业务的隔离方式 | 通讯录同步每日 02:00 起，单次不超过 20 分钟 |
| 可用性 | 允许的中断时长 | 服务时段、维护窗口 | 工作日 7:00–22:00 可用，单次中断不超过 15 分钟 |
测量条件是这五行的核心。同一句「列表 3 秒内打开」，在中档终端加 WLAN 下成立，在低端终端加弱网下可能 15 秒都出不来。所以性能需求必须绑定三要素：终端档位、网络环境、数据量级。移动端还要单独加一条弱网条款——网络切换时是否重试、重试几次、超时时间多少、已加载数据是否本地缓存。这条不写，验收时在电梯里打开一次就算「不达标」，双方都说不清。
还有一个倒推技巧：性能指标不要凭空定，从业务场景倒推。这份模板的场景是「外出时批阅文档、收发邮件、查通讯录」，那就从「掏出手机到看见待办列表」这条最短路径定指标，而不是从服务器 CPU 利用率定指标。前者用户能感知，后者只有运维关心。
4.2 接口需求：六要素表加同步与异步双通道
模板第十一章接口需求同样只有一页，但它的重要性不低于功能章节——集成类项目出问题，十次有八次在接口。我按六要素写：
| 要素 | 要写清什么 | 示例 |
|---|---|---|
| 接口名与用途 | 一句话说清干什么 | 通讯录增量同步 |
| 方向 | 谁调谁、主动还是被动 | OA 主动推送至移动平台 |
| 协议与端口 | 协议、端口、是否加密 | HTTPS 443、Web Service（SOAP） |
| 数据格式 | 编码、时间格式、字段长度、空值语义 | UTF-8；时间 yyyy-MM-dd HH:mm:ss；空值传空串不传 null |
| 频率与时延 | 定时还是实时、允许的最大延迟 | 每 10 分钟增量一次，延迟 ≤ 15 分钟 |
| 失败与重试 | 重试次数、退避策略、幂等键 | 失败重试 3 次，间隔 1/5/15 分钟，以人员 ID 为幂等键 |
模板正文里其实给了两条很典型的接口线索，可以直接拿来当范例。一条是邮件：移动平台通过 Pop3/Smtp 访问邮件服务器，实现收取、列表、正文、附件、发送、转发、回复、删除。另一条是文档交换：交换接口同时具备消息队列（异步）和 Web Service（同步）两类通道。
为什么同一个系统要留两条通道？因为选型依据不同。跨单位的文档交换，网络不可靠、单件体积大、还要求回执，必须走异步消息队列，发送方不必等对方处理完；而查询类操作，比如查某个交换件当前状态，用户点一下就要看到结果，走同步 Web Service 更合适。邮件则相反，Pop3/Smtp 本身就是拉取模型，只能定时轮询，所以需求里要写清轮询间隔和单次拉取上限，否则用户会问「为什么对方发了十分钟我还没收到」。
接口需求里最容易漏的四项：字符编码、时间格式、字段长度上限、幂等键。前三个决定对接当天能不能通，第四个决定出问题后能不能安全重放。
4.3 运行环境与安全：设施清单不等于安全需求
模板第十三章运行环境、第十五章安全设施需求、第十六章安全性需求，三章挨着，很多人会写成同一件事。它们的区别是：运行环境写「跑在什么上面」，安全设施写「买了什么、部署了什么」，安全性需求写「系统必须做到什么」。
运行环境按四栏列清单：
| 层 | 要写的内容 | 注意点 |
|---|---|---|
| 客户端 | 操作系统及版本下限、屏幕分辨率下限 | 模板写法是「支持 iOS 4.0、Android 2.0、WindowsMobile 6.1 及以上」，关键是「及以上」和不支持时的降级行为 |
| 服务端 | 操作系统、CPU/内存/磁盘、部署形态 | 单机还是集群，是否要求双机热备 |
| 数据库 | 类型、版本、字符集、容量规划 | 字符集与接口编码不一致是经典事故源 |
| 中间件 | 应用服务器、消息队列、Web 服务器 | 版本要与开发环境一致 |
安全性需求按四层拆，每层都要有可验证结果：
| 层 | 需求写法 | 验证方式 |
|---|---|---|
| 终端 | 首次使用需绑定设备并安装证书 | 换设备登录被拒绝并记录 |
| 网络 | 传输全程加密，禁止明文通道 | 抓包无非加密业务流量 |
| 应用 | 身份鉴别、按角色分级授权、关键操作留审计日志 | 越权访问被拒绝并产生日志；日志留存不少于约定期限 |
| 数据 | 敏感字段存储加密、关键数据签名验签、定期备份 | 直接读库看不到明文；验签失败的数据被拒收 |
区分清楚的好处是采购和开发不会互相甩锅。安全设施是采购与部署清单，验收时看设备清单和部署图；安全性需求是系统行为，验收时看测试报告和日志。模板把「安全设施」和「安全性」分成两章，正是这个意思，别为了省页数把它们合并。
至于扩展性与可移植性，写在最后但别写成一句话。扩展性要写触发条件：数据量增长到什么量级、并发到什么量级时，通过加节点还是分库来扩，扩的时候要不要停机。可移植性要写约束：依赖了哪些平台特性、换数据库或换中间件时需要改哪一层。这两条写实了，后面接手的人能少走很多弯路。
5. 避坑清单：这份模板落地时最容易出问题的五处
5.1 目录页码全乱、章节号跳号
现象：交稿前一天更新目录，发现第六章的页码指向第七章，二级标题编号在第七章从「6.」接着往下排，而不是从「1.」重新开始。手工改完第二天又乱了。
原因：编号是手敲的，不是绑定样式的自动编号；页码是手打的数字，不是域；目录是手工敲的点线，不是自动目录。三者互相独立，任何一处增删都会让另外两处失效。
解决：把多级列表绑定到标题样式，每章第一个二级标题设「重新开始于 1」；页脚用PAGE和NUMPAGES域；目录用自动目录。交稿前固定动作：Ctrl+A 全选，按 F9，选「更新整个目录」，然后从头翻一遍确认每章首页页码正确。这套动作做三次就会形成肌肉记忆。
5.2 功能表只有两列，评审过了照样返工
现象：需求评审一次通过，开发两个月后交付，验收时甲方说「这个功能不是我要的」，乙方说「文档里就写了这几个字」。翻回第七章，那一行确实只有「车辆费用管理」五个字。
原因：两列功能表只能证明「范围里有这个东西」，不能证明「做到什么程度算完成」。评审会上没人较真，是因为大家都在看范围；验收时较真，是因为要判定合格与否。
解决：功能条目一律扩成四列——编号、行为描述、前置与约束、验收判据。评审时逐条过第四列，凡是写不出可观察结果的条目，当场标红退回。这一步会拖慢评审，但能省掉后面整轮返工。
5.3 排序规则没写优先级，三套实现同时存在
现象：同一个待办列表，iOS 端按速级排，Android 端按时间排，Web 端按业务种类分组，三方都声称「按文档实现的」。
原因：文档写了「按业务种类、速级、接收时间排序」，但没写这三个键谁优先、各自升降序。三个键可以组合出十几种排法，开发各取所需。
解决：排序规则必须写成一条确定的链：「先按速级降序（特急 > 急件 > 平件），同速级按接收时间降序；业务种类作为分组表头，不参与排序」。多端项目还要补一句「三端排序结果必须一致」，并把它写进验收判据。
5.4 阈值留白，测试无法判定
现象：需求写「大文件不支持在线预览」，测试同学传了一个 4M 的 PDF 打得开，传了一个 6M 的打不开，问「4.5M 算不算大文件」，没人答得上来。
原因：把设计决策留给了开发和测试，文档只给了方向没给数字。这类留白在附件、分页条数、超时时间、字符长度上极其常见。
解决：所有阈值按「阈值、行为、提示文案、例外」四件套写全。5M 就写 5M，写清 ≤5M 且类型在白名单内直接预览，>5M 只下载，并给出提示原文。写完自查一遍：文档里所有出现「较大」「较多」「尽快」「适当」的地方，都是待补的数字。
5.5 签字后才改需求，版本表原地不动
现象：审核确认页签完字，甲方口头提了三条变更，乙方直接在正文里改了，版本号还是 V1.2 没动。三个月后双方对「当时到底定的什么」各执一词，谁也拿不出证据。
原因：把签字页当成了流程终点，而不是基线起点。版本更新表只在起草阶段用过，签字后就成了摆设。
解决：签字即冻结，冻结版本单独存档一份不可编辑的副本。之后任何改动都升版本号，更新摘要写清模块与编号区间，变更条目在文末附变更记录表（变更人、变更日期、变更前后内容、影响范围）。哪怕只改一个标点，也走这个流程——流程的价值不在于这次改了什么，而在于下次争议时你能拿出证据。
6. 变成基线：编号规则加一次自动核对
文档写到能签字，只完成了一半。真正让这份需求规格说明变成基线的是两件事：一套编号规则，和一次不依赖人眼的核对。
编号规则我固定用REQ-模块缩写-三位序号，模块缩写取 2～4 个大写字母，序号从 001 起连续。规则本身不重要，重要的是全文档统一，且编号一旦分配就不再复用——删掉的需求留空号，不拿后面的号补上，否则追踪矩阵会指向错误的历史。
追踪矩阵用最简单的 CSV，三列：需求编号、设计文档章节、测试用例编号。把 Word 里全选复制出来的纯文本存成srs.txt，再跑一遍下面这段：
import re from collections import Counter from pathlib import Path # 只匹配行首的编号，避免正文里的交叉引用被当成重复定义 DEF = re.compile(r"^\s*(REQ-[A-Z]{2,4}-\d{3})", re.M) ANY = re.compile(r"REQ-[A-Z]{2,4}-\d{3}") srs = Path("srs.txt").read_text(encoding="utf-8") # Word 全选复制出的纯文本 matrix = Path("trace_matrix.csv").read_text(encoding="utf-8") # 一行一条需求 defined = Counter(DEF.findall(srs)) # 条目定义处的编号出现次数 in_matrix = set(ANY.findall(matrix)) # 已登记进追踪矩阵的编号 all_ids = set(ANY.findall(srs)) # 正文出现过的全部编号 print("重复定义:", [k for k, v in defined.items() if v > 1] or "无") print("未进矩阵:", sorted(defined.keys() - in_matrix) or "无") print("矩阵孤儿:", sorted(in_matrix - all_ids) or "无")匹配逻辑上，只有行首的编号才算条目定义，这样「见 REQ-OA-003」这类引用不会被误判成重复；参数上，模块缩写限 2～4 位大写字母、序号固定三位，是为了让正则足够严格，宁可漏报也不要误报，漏报还能人工扫一遍，误报会让人直接放弃这个脚本。三个输出里，最该盯的是「未进矩阵」——它几乎总是意味着某条需求写完就忘了登记测试用例。
从那以后我每次交稿前都会把文档全选复制成纯文本跑一遍，再手工扫一眼「未进矩阵」那一行输出，十有八九是我漏了条目或者编号敲错了。这个习惯不高级，但它把「凭记忆检查」换成了「按规则检查」，后者不会累。希望帮到你。
本文还有配套的精品资源，点击获取
