尧图网站建设 
简介《软件需求规格说明书模板通用版》是一份面向软件项目团队、需求分析师与产品经理的规范文档范本用于在项目初期明确开发目标、范围与验收依据解决需求描述模糊、文档结构混乱等问题。压缩包内仅含1个doc文件大小1.29MB模板共27页、超1万字章节按照引言、编写目的、需求分析理论与目标、需求概述、系统功能需求、接口需求、非功能需求等层层递进其中功能需求部分结合移动OA、车辆管理、电子公文预览、政务信息管理等典型场景给出示例性描述并配有版本履历、审核确认表单、网络拓扑图框架便于直接编辑复用替换案例数据即可快速生成项目所需的说明书。清晰标注了需求应具备的明确性、完整性、一致性、可追踪性与可验证性等编写原则适合交付前自查。目前已有10944人学习下载是研发新人或团队负责人起草、评审需求规格说明书时值得收藏的标准参考。1. 软件需求规格说明书模板把口头需求变成书面契约的那张纸需求评审会开到第三轮开发问“日志到底要不要记录”测试问“验收标准写在哪”业务方反问“你们怎么连这个都要问我”。这不是团队水平问题是缺了一份把口头约定变成书面契约的文档。软件需求规格说明书模板通用版就是干这个的它不负责替你写需求只负责逼你回答那些“最容易忘、但后来最贵”的问题。通用版模板的意义不在于每个字段都填满而在于让项目组在动工之前统一语言、统一范围、统一验收口径。这篇笔记适合项目经理、需求分析师、产品经理也适合想少返工的开发和测试——我按自己实际用过的结构、填写方法和踩过的坑来讲。2. 拆开通用版模板的骨架章节结构与职责边界2.1 为什么要“通用”模板的分层设计思路通用版模板最容易被人误解成“什么项目都能直接往里填的空白文档”真这么用多半会填出一份又空又泛的废纸。我理解的“通用”是分层骨架固定、业务内容留白骨架解决“该问什么问题”留白解决“这个项目自己的答案”。骨架层包括编号规则、术语表、需求条目结构、验收标准写法、变更记录表。这些内容跟业务无关任何项目都用同一套所以叫通用。可变层包括业务背景、用户场景、功能清单、数据字典、外部接口协议。这些内容每个项目不同模板只给位置和提示不给内容。这样分的好处是团队评审模板本身时只评审一次后续项目复用骨架把精力放在可变层上。类比一下施工图里的图框、图层命名、尺寸标注规范是通用的平面图每栋楼单独画。SRS 模板的通用层就是图框和标注规范可变层就是平面图。如果骨架不稳定每个项目都重新发明一次编号规则和文档结构那才真的浪费时间。2.2 从引言到附录逐节拆解模板字段与书写要领业内搭 SRS 模板时最常参考的是 IEEE 830 的思路新版对应 ISO/IEC/IEEE 29148 的结构。通用版不必照抄全部章节但下面这些主节必须有否则后面一定缺东西。表格通用版 SRS 模板主节清单章节用途关键字段常见错误引言说清文档目的、读者对象、版本基线编写目的、读者范围、参考文献写成公司介绍或项目背景流水账范围界定做与不做系统目标、包含功能、明确不做的项只写做什么不写不做什么术语与定义统一语言避免歧义术语名称、英文名、缩写、定义业务方和开发对同一词理解不同总体描述交代干系人、用户场景、运行环境干系人清单、用户特征、部署环境把设计架构写进来越界了功能需求逐条列出系统行为需求编号、描述、输入、输出、异常流把“怎么做”写成“做什么”非功能需求约束系统质量属性性能、安全、可用性、合规参数只写“性能要好”这种空话外部接口需求描述系统间边界接口名称、协议、数据格式、频率等联调时才补导致排期失控数据需求定义核心数据实体数据字典、字段规则、保留期限字段取值范围没人确认验收标准规定可验证的完成条件功能验收项、性能指标、通过条件复制需求描述没法验证附录放上下文材料原型图、参考文档、会议纪要把原型贴正文替代文字需求逐节填写时最需要注意的是范围一章。范围里只写两件事这个版本上线后用户能做什么这个版本明确不做什么。我一般会在“明确不做”里写上版本号比如“移动端 App 不在 V1.0 范围内见 V1.1 规划”这样需求蔓延时至少有一个文字依据去挡业务方。数据需求这一节是新手最容易糊弄、老手最容易翻车的地方。字段名、字段类型、长度、取值范围、默认值、是否必填、保留周期这七项必须在模板里给出行否则开发建表时一定会来追问而那时已经进入编码阶段改字段等于返工。2.3 一个可以直接抄的 Markdown 模板骨架如果团队不是强制要求 Word 交付我更推荐用 Markdown 维护 SRS理由只有一条可 diff可评审可进 Git。下面这个骨架我在多个项目里直接用过标题层级和必填项都按 2.2 的表设计可以直接复制去用。# 项目名称 软件需求规格说明书 | 文档编号 | 版本 | 编写日期 | 编写人 | 评审状态 | |---|---|---|---|---| | PRJ-SRS-001 | v0.1 | 2026-01-01 | 需求组 | 未评审 | ## 1. 引言 - 编写目的一至两句话说明本文档要解决的问题 - 读者对象注明哪些角色需要读哪些章节 - 参考文献列出业务方案书、既有合同、标准文档编号 ## 2. 范围 - 系统目标一句话说清本版本要交付的核心价值 - 本版本包含列表记录用户可见的功能项 - 本版本不包含列表记录明确不做的事项及原因、计划版本号 ## 3. 术语与定义 | 术语 | 英文/缩写 | 定义 | 备注 | |---|---|---|---| | 管理员 | Admin | 拥有系统全部配置权限的角色 | 区别于业务审核员 | ## 4. 总体描述 - 干系人业务方、运营、最终用户、IT运维、第三方合作方 - 用户场景每个角色 2-3 条高频场景描述 - 运行环境部署形态、操作系统、浏览器版本要求 ## 5. 功能需求 ### 5.1 功能编号规则 - 编号格式FR-模块代码-三位序号示例 FR-LOGIN-001 - 每条需求必须包含描述、输入、处理逻辑、输出、异常处理、验收标准 ### 5.2 功能需求条目 #### FR-LOGIN-001 账号密码登录 - 描述用户使用账号和密码登录系统 - 输入账号必填、密码必填 - 处理逻辑校验账号存在性、校验密码正确性、锁定策略 - 输出登录成功进入首页失败提示具体原因 - 异常处理连续输错 5 次锁定 30 分钟 - 验收标准见 8.1 ## 6. 非功能需求 | 类别 | 指标 | 目标值 | 验证方式 | |---|---|---|---| | 性能 | 登录接口 P95 响应时间 | ≤ 2 秒 | 压测报告 | ## 7. 外部接口需求 | 接口名称 | 方向 | 协议 | 数据格式 | 调用频率 | 负责人 | |---|---|---|---|---|---| ## 8. 验收标准 - 功能验收逐条对应第 5 章需求编号列出可测试的通过条件 - 性能验收注明压测场景、并发量、数据量级 ## 9. 附录 - 原型图、字段清单、会议纪要等支撑材料骨架说明每个功能需求条目都保留了“输入、处理逻辑、输出、异常处理”四个占位字段这是让需求描述完整的最小集合。验收标准不放在功能需求里重复写而是集中到第 8 章统一引用避免同一个标准在两处维护导致版本不一致。如果团队用 Word按同样层级建标题即可但别用文本框和自选图形否则后续维护和模板复用会非常痛苦。3. 把模板落到项目上填表、编号、验收标准与文档管理3.1 建版本目录与文件名约定让模板成为协作基线模板文件本身需要一套管理约定。很多团队把 SRS 放在共享盘里文件名就叫“需求文档最终版 v2 真最终版.docx”光看文件名没人知道哪份有效。我一般会在项目根目录下建 requirements 目录结构与命名固定。docs/ └── requirements/ ├── templates/ # 通用模板跨项目复用 │ └── srs_template.md └── prj-demo/ # 具体项目目录 ├── PRJ-DEMO_SRS_v0.1.md # 初稿 ├── PRJ-DEMO_SRS_v0.2.md # 评审修改稿 └── PRJ-DEMO_SRS_v1.0.md # 评审通过后的基线版命名规则是“项目代号_SRS_版本号.md”版本号 vX.YX 在评审通过发布基线时递增Y 在评审意见修改、小范围调整时递增。正文头部有一张文档信息表记录当前版本、编写日期、编写人、评审状态每次改动都要同步更新这张表否则版本历史无从追溯。注意一个实践细节模板文件不要塞进个人电脑的 Word 模板目录。很多人遇到过 Word 提示“无法将更改后的内容保存到共用模板中”根因是模板文件被其他进程占用或者当前账号对该目录没有写入权限。把模板放进项目的 docs/requirements/templates 目录并纳入版本管理既不依赖某台机器的 Word 环境也让全组看到同一份模板。在开始填内容之前先做一次“结构评审”只评审章节是否齐全、编号规则是否确定、术语表是否建立不评审业务需求内容。结构评审通常半小时结束但能避免后续填到一半发现缺章节、需要整篇返工的问题。3.2 需求条目化编号规则与原子性约定SRS 最容易让人失去耐心的地方是几十条需求不知道该写到多细。我的经验是一个需求条目只描述一个可验证的行为并且给它一个永不重复的编号。编号规则从模板层就固定下来所有项目通用。表格需求编号规则示例字段取值示例说明类型前缀FR功能需求NFR非功能需求FR区分需求类别模块代码LOGIN、ORDER、REPORT 等英文缩写LOGIN对应业务模块模板中维护清单序号三位数字从 001 起001同模块内顺序递增具体编号示例FR-LOGIN-001、FR-ORDER-037、NFR-PERF-001。NFR 的模块代码用质量域替换比如 PERF 表示性能、SEC 表示安全、AVAIL 表示可用性。编号规则定死后有三条纪律第一编号一经创建永久保留哪怕需求被砍编号也不回收在条目里标记“已废弃”即可第二修改需求时保留原编号新增需求分配新编号不允许在原条目上“打补丁式修改”以免影响追溯第三同一份文档里编号不允许跳到子级比如不使用 5.1.3.2 这种层级编号层级编号在多级列表里非常容易错乱。下面是一条填写完整的需求条目示例可以作为填写时的参照标准FR-LOGIN-001 账号密码登录 描述 用户使用注册过的账号和密码登录系统。 输入 - 账号字符串长度 6-32 位必填 - 密码字符串长度 8-64 位必须含字母和数字必填 处理逻辑 1. 系统校验账号是否存在不存在则提示“账号不存在” 2. 系统校验密码是否正确错误则提示“账号或密码错误” 3. 连续失败 5 次锁定该账号 30 分钟锁定期间禁止登录 输出 - 登录成功跳转系统首页写入登录日志 - 登录失败显示对应错误提示输入框内容保留 异常处理 - 数据库连接超时提示“系统繁忙请稍后重试”记录错误日志 验收标准 - 见 8.1 节 FR-LOGIN-001 对应验收项这条示例体现了原子性的含义一个条目只说登录这一个行为不把注册、找回密码、第三方登录混进来。每条需求都对应一组明确的输入、处理、输出和异常测试人员拿到条目后可以直接设计用例不需要再猜。3.3 用可验证的验收标准反向倒逼需求描述填写 SRS 时一个常见错觉是“需求写完了后面再补验收标准”。补出来的验收标准多数是需求描述的复读比如“系统应正确完成登录”这种句子没法验证。我在模板里会强制为每条需求预留验收标准字段并要求按“可度量、可判定、可测试”三要素自查。看一组改写示例错误写法 系统应支持用户快速登录。 正确写法 在标准测试环境4 核 CPU、8G 内存、千兆网络下 使用有效账号密码登录从点击登录按钮到页面跳转完成 P95 响应时间不超过 2 秒且失败率不超过 0.1%。 验证方式使用 JMeter 模拟 500 并发用户循环登录 30 分钟 记录响应时间分布与失败率。区别在三个点正确写法给出了环境参数让测试条件可复现给出了量化指标2 秒、0.1%让结果可判定给出了验证工具和场景让测试可执行。这三个要素缺一个验收标准就只是装饰品。经验是优先写验收标准的项目需求描述本身也会变清楚。因为要写出可验证的指标就必须把模糊词全部换掉这比任何评审意见都管用。我在模板的每个功能需求条目后面放一行“验收标准是否可测试无法测试则返回修改需求描述”。3.4 模板里必须显式书写的非功能需求清单非功能需求是通用版模板里最容易空着不填的部分但它恰恰是上线后最难补的部分。运行慢了、被攻击了、数据丢了这些都不是靠开发后期加班能救回来的。模板至少要列六类非功能需求性能响应时间、吞吐量、并发数、安全认证方式、权限模型、数据加密、审计日志、可用性可用性指标、故障恢复时间、备份策略、兼容性浏览器、操作系统、移动端型号、可维护性日志规范、监控指标、部署方式、合规性数据保留期限、隐私要求。每一条都要带目标值不能只写“系统需要保证安全”。我一般的写法是NFR-PERF-001 核心接口性能 - 条件4 核 8G 标准环境500 并发用户 - 指标P95 响应时间 ≤ 2 秒吞吐量 ≥ 200 TPS NFR-SEC-001 账号安全 - 密码存储使用加盐哈希禁止明文存储 - 登录失败锁定策略见 FR-LOGIN-001 NFR-AVAIL-001 可用性 - 系统可用性目标 99.9%单次故障恢复时间 ≤ 30 分钟 - 数据全量备份每天 1 次增量备份每 6 小时 1 次非功能需求应该在项目启动时写明因为它的验证依赖测试环境和压测工具等到上线前才补测试排期根本接不住。模板里放这张表就是在提醒每个项目组开发前不过问性能和安全上线后一定出事故。4. SRS 常见问题避坑评审必翻车的五个场景与处置办法4.1 把“怎么做”写成了“做什么”现象SRS 里出现“系统通过 Redis 缓存用户 Token利用 Spring AOP 实现登录拦截”“数据库采用分库分表方案存储订单数据”。需求评审会上业务方看不懂开发觉得写得很清楚测试不知道以什么为准。原因写需求的人把设计实现混进了需求文档。需求描述的是行为设计描述的是实现方式。写进 SRS 的设计方案一旦被评审通过就成了“需求”后续哪怕有更好的技术方案也不能改否则会被扣上“需求变更”的帽子。解决碰到这类句子逐字删掉实现部分改写行为描述。比如上面的例子改成“系统应在服务端保存用户登录状态登录状态有效期为 30 分钟用户未登录访问受保护页面时应跳转到登录页面并提示‘请先登录’”。如果团队有独立的软件设计文档把实现细节挪到那边去。我一般会在 SRS 模板里加一句提示语“本节只描述做什么不描述怎么做实现细节请写进设计文档”。4.2 把界面原型截图直接当作需求现象SRS 正文里贴满页面截图每条需求只有一行字“见上图”。评审会上大家对着截图争论按钮颜色和间距上线前开发才发现某个异常分支在截图里根本没画出来。原因截图表达的是视觉布局表达不了逻辑规则。按钮位置可以看图但“点击保存时如果网络中断怎么办”这种问题截图永远回答不了。把截图当需求等于把异常流程全部交给开发临时决定。解决截图放进附录做参考正文必须用文字描述交互行为、状态流转和异常分支。比如“当用户填写完表单点击保存时系统先校验必填项为空则保存失败并提示‘请填写账号’保存成功后跳转列表页并弹出‘保存成功’提示”。模板里可以保留“界面参考”字段但必须在字段说明里写清楚截图仅用于理解业务不作为验收依据。4.3 出现不可验证的词“良好”“友好”“按需”现象需求写着“系统应具备良好的用户体验”“界面应友好”“报表应支持按需导出”。评审时没人反对测试时全部卡住因为“友好”没有测量方法。原因自然语言里的形容词默认带进了 SRS但没有转化成可测量指标。越抽象的词每个人脑补的标准差异越大评审会开着开着就会变成“我觉得这个绿色不够友好”这类无效争论。解决模板里放一张禁用词表把“良好、友好、快速、稳定、按需、合理”列为强制替换词。每条需求写完做一次自查能不能写成一个可执行的测试用例。替换办法见下面这组对比禁用写法 系统应支持常见浏览器的良好兼容。 可验证写法 系统应支持 Chrome 110、Edge 110、Firefox 105 三个版本 正常运行核心业务流程占比不低于 95%。 验证方式使用 Selenium 在三个浏览器上执行核心流程回归用例。这个例子说明把模糊词替换成版本号和覆盖率开发和测试立刻知道怎么干活。“按需导出”这类词也一样必须写明按什么条件筛选、导出什么格式、最大导出行数限制。4.4 需求编号在变更后错乱现象SRS 正文里出现“5.1.3.2.1”这种五级编号而且编号与目录对不上。需求变更时在原编号附近插了一个“5.1.3.2.1b”过两周没人知道 b 是什么意思追溯矩阵也彻底失效。原因用 Word 多级列表手动维护编号增加或删除条目后没有自动更新有些人在原需求上打补丁用字母后缀一样的内容编号。编号一旦和内容脱节需求变更影响分析就做不了。解决启用 3.2 的固定编号规则并把变更记录独立出来。模板里建一张变更记录表每次变更登记四列变更日期、涉及的编号、变更内容描述、版本号。下面是一张实际用过的表结构表格需求变更记录表变更日期需求编号变更内容新版本号2026-01-10FR-LOGIN-001锁定次数从 5 次改为 3 次锁定时间 30 分钟不变v0.22026-01-15FR-ORDER-037新增优惠券使用规则需求编号不变v0.3规则坚持两条一是编号不回收废弃的需求做标记保留在文档里二是变更后发布新版本不在原版本上无声无息地改。老版本留档新版本发布谁改了什么一查便知。4.5 术语表缺失同一个词三种理解现象需求里大量出现“管理员”业务方理解是“能审核订单的业务主管”开发理解是“拥有系统全部权限的 IT 管理员”测试不知道按哪个口径设计用例上线后才发现权限模型完全错位。原因组织内部对同一个词长期存在不同口径平时靠口头沟通掩盖了差异落到 SRS 里没有统一定义就成了定时炸弹。解决模板第 3 章术语表按 2.3 的表格填写每个术语给出定义和备注。上面这个例子的正确写法是| 管理员 | Admin | 拥有系统全部配置权限的角色用户管理、参数配置、日志查看 | 区别于业务审核员业务审核员仅能审核订单 |。写 SRS 前先花半天把项目里可能产生歧义的词全部过一遍成本最低后面改权限模型那是几周工作量。5. 让通用模板持续产生价值版本演化与复用技巧通用版模板最有价值的状态不是“写完一次永久使用”而是每个项目结束后都能往里沉淀一条规则。我做事的习惯是每次 SRS 评审会结束时把会上吵得最凶的句子记下来回填到模板的备注列里。比如这次评审因为“轮询”定义吵了四十分钟下次模板的术语表里就直接预置“轮询表示客户端每 10 秒向服务端请求一次状态”这个条目。模板就是这样一年一年长出肉来的。两个具体技巧推荐给团队。第一个是需求追溯矩阵模板里加一张表横向是需求编号纵向是设计文档章节、测试用例编号、代码模块这个矩阵在项目结束时用来核对“每条需求有没有设计、有没有测试、有没有实现”。没有追溯矩阵的 SRS评审通过后很快就会和实际代码脱节。第二个是模板与需求管理工具字段对齐。如果团队用 Jira、禅道之类的工具管理需求模板里的每个字段应该和工具里的自定义字段一一对应比如“验收标准”对应工具的“验收标准”字段“编号”对应用户故事编号。这样 SRS 文档评审通过后录入工具时不需要做二次翻译减少一次出错机会。给新手最后一个操作建议新项目拿到模板不要急着填内容先花一小时按 3.1 做结构评审再花半天把术语表和编号规则定下来最后才开始写需求条目。省下的返工时间通常是这几小时的十倍。我自己的项目模板已经迭代到第五版里面还能看到三年前某次上线事故留下的教训。希望帮到你。本文还有配套的精品资源点击获取 软件需求规格说明书模板：从口头需求到书面契约的完整指南
简介《软件需求规格说明书模板通用版》是一份面向软件项目团队、需求分析师与产品经理的规范文档范本用于在项目初期明确开发目标、范围与验收依据解决需求描述模糊、文档结构混乱等问题。压缩包内仅含1个doc文件大小1.29MB模板共27页、超1万字章节按照引言、编写目的、需求分析理论与目标、需求概述、系统功能需求、接口需求、非功能需求等层层递进其中功能需求部分结合移动OA、车辆管理、电子公文预览、政务信息管理等典型场景给出示例性描述并配有版本履历、审核确认表单、网络拓扑图框架便于直接编辑复用替换案例数据即可快速生成项目所需的说明书。清晰标注了需求应具备的明确性、完整性、一致性、可追踪性与可验证性等编写原则适合交付前自查。目前已有10944人学习下载是研发新人或团队负责人起草、评审需求规格说明书时值得收藏的标准参考。1. 软件需求规格说明书模板把口头需求变成书面契约的那张纸需求评审会开到第三轮开发问“日志到底要不要记录”测试问“验收标准写在哪”业务方反问“你们怎么连这个都要问我”。这不是团队水平问题是缺了一份把口头约定变成书面契约的文档。软件需求规格说明书模板通用版就是干这个的它不负责替你写需求只负责逼你回答那些“最容易忘、但后来最贵”的问题。通用版模板的意义不在于每个字段都填满而在于让项目组在动工之前统一语言、统一范围、统一验收口径。这篇笔记适合项目经理、需求分析师、产品经理也适合想少返工的开发和测试——我按自己实际用过的结构、填写方法和踩过的坑来讲。2. 拆开通用版模板的骨架章节结构与职责边界2.1 为什么要“通用”模板的分层设计思路通用版模板最容易被人误解成“什么项目都能直接往里填的空白文档”真这么用多半会填出一份又空又泛的废纸。我理解的“通用”是分层骨架固定、业务内容留白骨架解决“该问什么问题”留白解决“这个项目自己的答案”。骨架层包括编号规则、术语表、需求条目结构、验收标准写法、变更记录表。这些内容跟业务无关任何项目都用同一套所以叫通用。可变层包括业务背景、用户场景、功能清单、数据字典、外部接口协议。这些内容每个项目不同模板只给位置和提示不给内容。这样分的好处是团队评审模板本身时只评审一次后续项目复用骨架把精力放在可变层上。类比一下施工图里的图框、图层命名、尺寸标注规范是通用的平面图每栋楼单独画。SRS 模板的通用层就是图框和标注规范可变层就是平面图。如果骨架不稳定每个项目都重新发明一次编号规则和文档结构那才真的浪费时间。2.2 从引言到附录逐节拆解模板字段与书写要领业内搭 SRS 模板时最常参考的是 IEEE 830 的思路新版对应 ISO/IEC/IEEE 29148 的结构。通用版不必照抄全部章节但下面这些主节必须有否则后面一定缺东西。表格通用版 SRS 模板主节清单章节用途关键字段常见错误引言说清文档目的、读者对象、版本基线编写目的、读者范围、参考文献写成公司介绍或项目背景流水账范围界定做与不做系统目标、包含功能、明确不做的项只写做什么不写不做什么术语与定义统一语言避免歧义术语名称、英文名、缩写、定义业务方和开发对同一词理解不同总体描述交代干系人、用户场景、运行环境干系人清单、用户特征、部署环境把设计架构写进来越界了功能需求逐条列出系统行为需求编号、描述、输入、输出、异常流把“怎么做”写成“做什么”非功能需求约束系统质量属性性能、安全、可用性、合规参数只写“性能要好”这种空话外部接口需求描述系统间边界接口名称、协议、数据格式、频率等联调时才补导致排期失控数据需求定义核心数据实体数据字典、字段规则、保留期限字段取值范围没人确认验收标准规定可验证的完成条件功能验收项、性能指标、通过条件复制需求描述没法验证附录放上下文材料原型图、参考文档、会议纪要把原型贴正文替代文字需求逐节填写时最需要注意的是范围一章。范围里只写两件事这个版本上线后用户能做什么这个版本明确不做什么。我一般会在“明确不做”里写上版本号比如“移动端 App 不在 V1.0 范围内见 V1.1 规划”这样需求蔓延时至少有一个文字依据去挡业务方。数据需求这一节是新手最容易糊弄、老手最容易翻车的地方。字段名、字段类型、长度、取值范围、默认值、是否必填、保留周期这七项必须在模板里给出行否则开发建表时一定会来追问而那时已经进入编码阶段改字段等于返工。2.3 一个可以直接抄的 Markdown 模板骨架如果团队不是强制要求 Word 交付我更推荐用 Markdown 维护 SRS理由只有一条可 diff可评审可进 Git。下面这个骨架我在多个项目里直接用过标题层级和必填项都按 2.2 的表设计可以直接复制去用。# 项目名称 软件需求规格说明书 | 文档编号 | 版本 | 编写日期 | 编写人 | 评审状态 | |---|---|---|---|---| | PRJ-SRS-001 | v0.1 | 2026-01-01 | 需求组 | 未评审 | ## 1. 引言 - 编写目的一至两句话说明本文档要解决的问题 - 读者对象注明哪些角色需要读哪些章节 - 参考文献列出业务方案书、既有合同、标准文档编号 ## 2. 范围 - 系统目标一句话说清本版本要交付的核心价值 - 本版本包含列表记录用户可见的功能项 - 本版本不包含列表记录明确不做的事项及原因、计划版本号 ## 3. 术语与定义 | 术语 | 英文/缩写 | 定义 | 备注 | |---|---|---|---| | 管理员 | Admin | 拥有系统全部配置权限的角色 | 区别于业务审核员 | ## 4. 总体描述 - 干系人业务方、运营、最终用户、IT运维、第三方合作方 - 用户场景每个角色 2-3 条高频场景描述 - 运行环境部署形态、操作系统、浏览器版本要求 ## 5. 功能需求 ### 5.1 功能编号规则 - 编号格式FR-模块代码-三位序号示例 FR-LOGIN-001 - 每条需求必须包含描述、输入、处理逻辑、输出、异常处理、验收标准 ### 5.2 功能需求条目 #### FR-LOGIN-001 账号密码登录 - 描述用户使用账号和密码登录系统 - 输入账号必填、密码必填 - 处理逻辑校验账号存在性、校验密码正确性、锁定策略 - 输出登录成功进入首页失败提示具体原因 - 异常处理连续输错 5 次锁定 30 分钟 - 验收标准见 8.1 ## 6. 非功能需求 | 类别 | 指标 | 目标值 | 验证方式 | |---|---|---|---| | 性能 | 登录接口 P95 响应时间 | ≤ 2 秒 | 压测报告 | ## 7. 外部接口需求 | 接口名称 | 方向 | 协议 | 数据格式 | 调用频率 | 负责人 | |---|---|---|---|---|---| ## 8. 验收标准 - 功能验收逐条对应第 5 章需求编号列出可测试的通过条件 - 性能验收注明压测场景、并发量、数据量级 ## 9. 附录 - 原型图、字段清单、会议纪要等支撑材料骨架说明每个功能需求条目都保留了“输入、处理逻辑、输出、异常处理”四个占位字段这是让需求描述完整的最小集合。验收标准不放在功能需求里重复写而是集中到第 8 章统一引用避免同一个标准在两处维护导致版本不一致。如果团队用 Word按同样层级建标题即可但别用文本框和自选图形否则后续维护和模板复用会非常痛苦。3. 把模板落到项目上填表、编号、验收标准与文档管理3.1 建版本目录与文件名约定让模板成为协作基线模板文件本身需要一套管理约定。很多团队把 SRS 放在共享盘里文件名就叫“需求文档最终版 v2 真最终版.docx”光看文件名没人知道哪份有效。我一般会在项目根目录下建 requirements 目录结构与命名固定。docs/ └── requirements/ ├── templates/ # 通用模板跨项目复用 │ └── srs_template.md └── prj-demo/ # 具体项目目录 ├── PRJ-DEMO_SRS_v0.1.md # 初稿 ├── PRJ-DEMO_SRS_v0.2.md # 评审修改稿 └── PRJ-DEMO_SRS_v1.0.md # 评审通过后的基线版命名规则是“项目代号_SRS_版本号.md”版本号 vX.YX 在评审通过发布基线时递增Y 在评审意见修改、小范围调整时递增。正文头部有一张文档信息表记录当前版本、编写日期、编写人、评审状态每次改动都要同步更新这张表否则版本历史无从追溯。注意一个实践细节模板文件不要塞进个人电脑的 Word 模板目录。很多人遇到过 Word 提示“无法将更改后的内容保存到共用模板中”根因是模板文件被其他进程占用或者当前账号对该目录没有写入权限。把模板放进项目的 docs/requirements/templates 目录并纳入版本管理既不依赖某台机器的 Word 环境也让全组看到同一份模板。在开始填内容之前先做一次“结构评审”只评审章节是否齐全、编号规则是否确定、术语表是否建立不评审业务需求内容。结构评审通常半小时结束但能避免后续填到一半发现缺章节、需要整篇返工的问题。3.2 需求条目化编号规则与原子性约定SRS 最容易让人失去耐心的地方是几十条需求不知道该写到多细。我的经验是一个需求条目只描述一个可验证的行为并且给它一个永不重复的编号。编号规则从模板层就固定下来所有项目通用。表格需求编号规则示例字段取值示例说明类型前缀FR功能需求NFR非功能需求FR区分需求类别模块代码LOGIN、ORDER、REPORT 等英文缩写LOGIN对应业务模块模板中维护清单序号三位数字从 001 起001同模块内顺序递增具体编号示例FR-LOGIN-001、FR-ORDER-037、NFR-PERF-001。NFR 的模块代码用质量域替换比如 PERF 表示性能、SEC 表示安全、AVAIL 表示可用性。编号规则定死后有三条纪律第一编号一经创建永久保留哪怕需求被砍编号也不回收在条目里标记“已废弃”即可第二修改需求时保留原编号新增需求分配新编号不允许在原条目上“打补丁式修改”以免影响追溯第三同一份文档里编号不允许跳到子级比如不使用 5.1.3.2 这种层级编号层级编号在多级列表里非常容易错乱。下面是一条填写完整的需求条目示例可以作为填写时的参照标准FR-LOGIN-001 账号密码登录 描述 用户使用注册过的账号和密码登录系统。 输入 - 账号字符串长度 6-32 位必填 - 密码字符串长度 8-64 位必须含字母和数字必填 处理逻辑 1. 系统校验账号是否存在不存在则提示“账号不存在” 2. 系统校验密码是否正确错误则提示“账号或密码错误” 3. 连续失败 5 次锁定该账号 30 分钟锁定期间禁止登录 输出 - 登录成功跳转系统首页写入登录日志 - 登录失败显示对应错误提示输入框内容保留 异常处理 - 数据库连接超时提示“系统繁忙请稍后重试”记录错误日志 验收标准 - 见 8.1 节 FR-LOGIN-001 对应验收项这条示例体现了原子性的含义一个条目只说登录这一个行为不把注册、找回密码、第三方登录混进来。每条需求都对应一组明确的输入、处理、输出和异常测试人员拿到条目后可以直接设计用例不需要再猜。3.3 用可验证的验收标准反向倒逼需求描述填写 SRS 时一个常见错觉是“需求写完了后面再补验收标准”。补出来的验收标准多数是需求描述的复读比如“系统应正确完成登录”这种句子没法验证。我在模板里会强制为每条需求预留验收标准字段并要求按“可度量、可判定、可测试”三要素自查。看一组改写示例错误写法 系统应支持用户快速登录。 正确写法 在标准测试环境4 核 CPU、8G 内存、千兆网络下 使用有效账号密码登录从点击登录按钮到页面跳转完成 P95 响应时间不超过 2 秒且失败率不超过 0.1%。 验证方式使用 JMeter 模拟 500 并发用户循环登录 30 分钟 记录响应时间分布与失败率。区别在三个点正确写法给出了环境参数让测试条件可复现给出了量化指标2 秒、0.1%让结果可判定给出了验证工具和场景让测试可执行。这三个要素缺一个验收标准就只是装饰品。经验是优先写验收标准的项目需求描述本身也会变清楚。因为要写出可验证的指标就必须把模糊词全部换掉这比任何评审意见都管用。我在模板的每个功能需求条目后面放一行“验收标准是否可测试无法测试则返回修改需求描述”。3.4 模板里必须显式书写的非功能需求清单非功能需求是通用版模板里最容易空着不填的部分但它恰恰是上线后最难补的部分。运行慢了、被攻击了、数据丢了这些都不是靠开发后期加班能救回来的。模板至少要列六类非功能需求性能响应时间、吞吐量、并发数、安全认证方式、权限模型、数据加密、审计日志、可用性可用性指标、故障恢复时间、备份策略、兼容性浏览器、操作系统、移动端型号、可维护性日志规范、监控指标、部署方式、合规性数据保留期限、隐私要求。每一条都要带目标值不能只写“系统需要保证安全”。我一般的写法是NFR-PERF-001 核心接口性能 - 条件4 核 8G 标准环境500 并发用户 - 指标P95 响应时间 ≤ 2 秒吞吐量 ≥ 200 TPS NFR-SEC-001 账号安全 - 密码存储使用加盐哈希禁止明文存储 - 登录失败锁定策略见 FR-LOGIN-001 NFR-AVAIL-001 可用性 - 系统可用性目标 99.9%单次故障恢复时间 ≤ 30 分钟 - 数据全量备份每天 1 次增量备份每 6 小时 1 次非功能需求应该在项目启动时写明因为它的验证依赖测试环境和压测工具等到上线前才补测试排期根本接不住。模板里放这张表就是在提醒每个项目组开发前不过问性能和安全上线后一定出事故。4. SRS 常见问题避坑评审必翻车的五个场景与处置办法4.1 把“怎么做”写成了“做什么”现象SRS 里出现“系统通过 Redis 缓存用户 Token利用 Spring AOP 实现登录拦截”“数据库采用分库分表方案存储订单数据”。需求评审会上业务方看不懂开发觉得写得很清楚测试不知道以什么为准。原因写需求的人把设计实现混进了需求文档。需求描述的是行为设计描述的是实现方式。写进 SRS 的设计方案一旦被评审通过就成了“需求”后续哪怕有更好的技术方案也不能改否则会被扣上“需求变更”的帽子。解决碰到这类句子逐字删掉实现部分改写行为描述。比如上面的例子改成“系统应在服务端保存用户登录状态登录状态有效期为 30 分钟用户未登录访问受保护页面时应跳转到登录页面并提示‘请先登录’”。如果团队有独立的软件设计文档把实现细节挪到那边去。我一般会在 SRS 模板里加一句提示语“本节只描述做什么不描述怎么做实现细节请写进设计文档”。4.2 把界面原型截图直接当作需求现象SRS 正文里贴满页面截图每条需求只有一行字“见上图”。评审会上大家对着截图争论按钮颜色和间距上线前开发才发现某个异常分支在截图里根本没画出来。原因截图表达的是视觉布局表达不了逻辑规则。按钮位置可以看图但“点击保存时如果网络中断怎么办”这种问题截图永远回答不了。把截图当需求等于把异常流程全部交给开发临时决定。解决截图放进附录做参考正文必须用文字描述交互行为、状态流转和异常分支。比如“当用户填写完表单点击保存时系统先校验必填项为空则保存失败并提示‘请填写账号’保存成功后跳转列表页并弹出‘保存成功’提示”。模板里可以保留“界面参考”字段但必须在字段说明里写清楚截图仅用于理解业务不作为验收依据。4.3 出现不可验证的词“良好”“友好”“按需”现象需求写着“系统应具备良好的用户体验”“界面应友好”“报表应支持按需导出”。评审时没人反对测试时全部卡住因为“友好”没有测量方法。原因自然语言里的形容词默认带进了 SRS但没有转化成可测量指标。越抽象的词每个人脑补的标准差异越大评审会开着开着就会变成“我觉得这个绿色不够友好”这类无效争论。解决模板里放一张禁用词表把“良好、友好、快速、稳定、按需、合理”列为强制替换词。每条需求写完做一次自查能不能写成一个可执行的测试用例。替换办法见下面这组对比禁用写法 系统应支持常见浏览器的良好兼容。 可验证写法 系统应支持 Chrome 110、Edge 110、Firefox 105 三个版本 正常运行核心业务流程占比不低于 95%。 验证方式使用 Selenium 在三个浏览器上执行核心流程回归用例。这个例子说明把模糊词替换成版本号和覆盖率开发和测试立刻知道怎么干活。“按需导出”这类词也一样必须写明按什么条件筛选、导出什么格式、最大导出行数限制。4.4 需求编号在变更后错乱现象SRS 正文里出现“5.1.3.2.1”这种五级编号而且编号与目录对不上。需求变更时在原编号附近插了一个“5.1.3.2.1b”过两周没人知道 b 是什么意思追溯矩阵也彻底失效。原因用 Word 多级列表手动维护编号增加或删除条目后没有自动更新有些人在原需求上打补丁用字母后缀一样的内容编号。编号一旦和内容脱节需求变更影响分析就做不了。解决启用 3.2 的固定编号规则并把变更记录独立出来。模板里建一张变更记录表每次变更登记四列变更日期、涉及的编号、变更内容描述、版本号。下面是一张实际用过的表结构表格需求变更记录表变更日期需求编号变更内容新版本号2026-01-10FR-LOGIN-001锁定次数从 5 次改为 3 次锁定时间 30 分钟不变v0.22026-01-15FR-ORDER-037新增优惠券使用规则需求编号不变v0.3规则坚持两条一是编号不回收废弃的需求做标记保留在文档里二是变更后发布新版本不在原版本上无声无息地改。老版本留档新版本发布谁改了什么一查便知。4.5 术语表缺失同一个词三种理解现象需求里大量出现“管理员”业务方理解是“能审核订单的业务主管”开发理解是“拥有系统全部权限的 IT 管理员”测试不知道按哪个口径设计用例上线后才发现权限模型完全错位。原因组织内部对同一个词长期存在不同口径平时靠口头沟通掩盖了差异落到 SRS 里没有统一定义就成了定时炸弹。解决模板第 3 章术语表按 2.3 的表格填写每个术语给出定义和备注。上面这个例子的正确写法是| 管理员 | Admin | 拥有系统全部配置权限的角色用户管理、参数配置、日志查看 | 区别于业务审核员业务审核员仅能审核订单 |。写 SRS 前先花半天把项目里可能产生歧义的词全部过一遍成本最低后面改权限模型那是几周工作量。5. 让通用模板持续产生价值版本演化与复用技巧通用版模板最有价值的状态不是“写完一次永久使用”而是每个项目结束后都能往里沉淀一条规则。我做事的习惯是每次 SRS 评审会结束时把会上吵得最凶的句子记下来回填到模板的备注列里。比如这次评审因为“轮询”定义吵了四十分钟下次模板的术语表里就直接预置“轮询表示客户端每 10 秒向服务端请求一次状态”这个条目。模板就是这样一年一年长出肉来的。两个具体技巧推荐给团队。第一个是需求追溯矩阵模板里加一张表横向是需求编号纵向是设计文档章节、测试用例编号、代码模块这个矩阵在项目结束时用来核对“每条需求有没有设计、有没有测试、有没有实现”。没有追溯矩阵的 SRS评审通过后很快就会和实际代码脱节。第二个是模板与需求管理工具字段对齐。如果团队用 Jira、禅道之类的工具管理需求模板里的每个字段应该和工具里的自定义字段一一对应比如“验收标准”对应工具的“验收标准”字段“编号”对应用户故事编号。这样 SRS 文档评审通过后录入工具时不需要做二次翻译减少一次出错机会。给新手最后一个操作建议新项目拿到模板不要急着填内容先花一小时按 3.1 做结构评审再花半天把术语表和编号规则定下来最后才开始写需求条目。省下的返工时间通常是这几小时的十倍。我自己的项目模板已经迭代到第五版里面还能看到三年前某次上线事故留下的教训。希望帮到你。本文还有配套的精品资源点击获取