26页软件需求规格说明书模板：骨架、功能拆解与评审避坑

简介：面向软件开发初学者、需求分析人员与项目文档编写者的软件需求规格说明书模板，用一份可直接套用的文档解决SRS章节无章可循、内容缺漏的问题。文档按工程化结构编排，引言部分含编写目的、需求分析理论与目标、参考文献；需求概述涵盖项目背景、条件与限制、移动办公系统结构与网络拓扑图；系统功能需求细到界面显示要求、待办公文列表与排序、公文详细信息界面元素、网站信息审批、会议申请、意见录入、移动邮件、会议管理、通知通告、通讯录管理，并延伸到车辆管理、电子公文预览与政务信息管理平台。另设用户界面、硬件、网络与接口需求章节，附版本更新记录及项目负责人审核签字表格。压缩包为1个doc文件，约1.34MB，目录层级与页眉页脚排版规范。已有1126人学习下载，可用于参照章节骨架、补齐非功能与数据需求，缩短从零起草文档的时间。

1. 从一次被打回的评审说起：这份 26 页模板到底解决什么

软件需求规格说明书模板这类东西，很多人是答辩前一周才开始找。见过一个小组，系统跑得挺顺，交上去的需求规格说明书只有五页，一条功能一句话。导师翻到第二页就问：「待办公文列表」开发照着做，长什么样、按什么排序、多大的附件不给预览？三问答不上，退回重写。

这份 26 页的模板照着重写正合适：封面有版本记录表和双方审核签字页，正文分引言、需求概述、功能需求、接口需求、非功能需求五章，还带着移动办公、车辆管理、电子公文预览、政务信息平台四条业务线的完整写法——两行显示规则、三种排序、5M 附件阈值、一车一档字段清单、公文交换五步流程和两级回执。做毕设、写课设、给甲方交需求文档，都能拿它当骨架改。

2. 文档骨架设计：版本记录表、审核签字页与五章目录的职责划分

需求文档最容易出的问题不是内容少，而是没有骨架——写到哪算哪，评审一问「这块需求是哪一版定的、谁确认的」就卡住。这份模板把骨架放在最前面：封面三件套定身份，五章目录定职责，功能编号定追溯路径。先把这三件事定下来，后面填内容才不会返工。

2.1 封面三件套：文档标识、版本更新记录、审核确认

封面顶部是文档标识区：项目名称、文档名称、文档 ID、文档说明里的版本号、作者、最后更新时间。这六个字段看着像走形式，实际是让「这份文档是哪一版」在整条链路上唯一。评审现场最常见的翻车是甲方拿着上一版打印稿，开发对着最新版讲，两边对不上，讨论半小时才发现说的不是同一份东西。

紧接着是版本更新概要表，四个字段：版本号、时间、更新人、更新摘要。这份模板里的三行记录很值得抄——第一版是移动 OA 与车辆管理模块的需求内容，第二版加了移动政务资源管理平台，第三版加了电子公文在线预览。注意每一行更新的是一整块业务需求，不是一个错别字或一次排版调整。这样评审时能一眼看出「某个模块的需求是从哪一版进来的」，也能反推「这一版为什么延期」。

再往下是审核与确认区，分供应商方和客户方两栏，字段是姓名、职位、审核时间、审核意见、签字。这一页是整个文档唯一的「后悔药」：双方签字即需求基线，签字之后的改动走变更单，不走变更单的改动在验收时不予承认。我一般要求每轮评审对应一次签字，历史签字页不删，作为附录保留，否则第三轮评审时没人说得清第一轮确认了什么。

2.2 五章目录的分工：每一章写给谁看

模板正文五章，不是随便排的，每章有明确的读者。引言（编写目的、软件需求分析理论、软件需求分析目标、参考文献）写给评审和接手的人，交代这份文档为什么存在、依据什么方法拆需求。需求概述（项目背景、需求概述、条件与限制、系统结构、网络拓扑）写给甲方和项目经理，用来确认范围与边界。系统功能需求是条目最多的一章，写给开发和测试。接口需求（用户界面、硬件、网络、接口、通信、运行环境）写给集成方和运维。非功能需求（性能、安全设施、安全性、扩展性、可移植性）写给验收方。

有个反常识的点：模板在引言里放了「软件需求分析理论」和「分析目标」两节，很多学生觉得是凑字数直接删掉。这两节其实是文档的自我辩护。评审问「你凭什么这么拆需求」，翻到这一页就有答案：需求分析要覆盖六类内容——功能需求、与硬件或其他外部系统的接口、非功能需求、反向需求、设计与实现上的限制、阅读支持信息。删了它，后面章节是否完整就没有依据可讲，评审只能凭感觉挑毛病。

引言里的「分析目标」三条也值得保留：全面描述功能，帮用户在开发启动前把需求想周全；描述实现所需的全部信息，作为设计、确认和验证的基准；为成本计价和开发计划编制提供依据。这三条对应三种读者——甲方、开发测试、项目经理，正好解释了为什么一份文档要写这么厚。

2.3 可复制的骨架与需求编号规则

把上面的结构落成文件，就是下面这个骨架。可以直接建一个 Markdown 文件，按标题层级填，导出成 Word 后再补封面和页眉页脚。

# 软件需求规格说明书（项目名） ## 第一章 引言 ### 1 编写目的 ### 2 软件需求分析理论 ### 3 软件需求分析目标 ### 4 参考文献 ## 第二章 需求概述 ### 1 项目背景 ### 2 需求概述 ### 3 条件与限制 ### 4 系统结构 ### 5 网络拓扑 ## 第三章 系统功能需求 ### 1 移动办公系统升级改造需求 ### 2 车辆管理模块升级改造需求 ### 3 电子公文预览需求 ### 4 政务信息管理系统平台功能需求 ## 第四章 软硬件或其他外部系统接口需求 ## 第五章 其他非功能需求

这个骨架的排序逻辑是「为什么做 → 做什么 → 和谁对接 → 做到什么程度」。第三章按业务模块分节，不按「增删改查」分节，因为读者是按模块找需求的，开发拿到「移动办公」这一节就能干完一整块活。如果按操作类型分，一个模块的需求会散落在四五个地方，改一处要翻半本。

编号规则要跟骨架一起定，否则写到一半就开始乱。功能条目统一用「前缀-模块缩写-三位序号」：

编号一旦分配就不再复用，需求删掉也保留空号，注明「已废弃，原因」。这条规矩看着较真，但后面测试用例、验收清单都要引用这个号，复用编号会造成追溯断链。

3. 需求概述与系统结构：四层安全域、三侧拓扑与条件限制的写法

第二章是整份文档的门面。评审通常只精读这一章和第三章开头，剩下的靠翻。这一章写不好的典型症状是：背景段落全是「随时随地、零距离、安全稳定」这类词，读完不知道系统服务谁、覆盖多少终端、和现有系统什么关系。模板给的解法是把概述拆成五块，每块只回答一个问题。

3.1 项目背景：把 4A 目标拆成四条可核对的边界

模板里的背景段落有个清晰的四句式结构，值得直接套用。第一句写动因：为进一步实现政务公开要求，方便各类政务信息准确、安全、快速地发布到指定移动终端。第二句写痛点：领导外出时无法方便安全地批阅公文、收发邮件、查询通讯录。第三句写技术前提：基于 3G 高速网络，采用手机适配技术实现移动办公应用，并通过 PKI/CA、VPDN、APN 等信息安全技术保证接入安全。第四句写覆盖范围：在 WCDMA、3G 网络覆盖的地方，用户可以访问 OA 办文、邮件、人事管理等办公系统。

这四句里，动因和痛点决定项目要不要做，技术前提和覆盖范围决定做不做得成，一句废话都没有。模板还提了 4A 目标（Any where / Any time / Any data / Any device），这四个词不能只当口号写在背景里，要各自落到后面的条目：Any device 落到终端适配清单，Any time、Any where 落到网络覆盖与断网重连策略，Any data 落到数据范围（公文、邮件、通讯录、会议、通知通告）。

背景段还要交代一件容易被忽略的事：这次是新建还是改造。模板写得很清楚——2007 年已建成基于 Windows Mobile 的移动办公系统，2010 年扩展到 iOS，本次是在原有系统上增加适配软件模块，要求支持 iOS 4.0、Android 2.0、Windows Mobile 6.1 以上。一句话就把「升级改造」的边界划出来了：原有流程全部保留，新增的是多终端适配层。不写这句，开发很可能把整个系统重做一遍，工期直接翻倍。

3.2 四层安全控制域：分层是给安全需求找落点

模板把移动 OA 划成四层安全控制域，并说明「网络安全设计以各域的工作特点为依据」。这句话是整章的方法论：分层不是为了画图好看，是为了让每一层都有独立的安全需求可写。

按层写的好处很直接：安全需求不会只停在「要安全」三个字。终端用户层要写清客户端被反编译、缓存被拖走怎么办；运营商服务层要写清接入点白名单和传输通道；业务逻辑层要写清令牌校验、越权拦截、接口防重放；外部系统层要写清对接账号的权限边界。四层各写四条，一份能过评审的安全需求就有了。

这四层还有一个隐含作用：划定责任边界。终端层的问题归客户端团队，业务逻辑层的问题归服务端团队，外部系统层的问题要和 OA 厂商一起排。出故障时先按层定位，比一上来就翻日志高效得多——这是排查思路写进需求文档的典型例子。

3.3 三侧拓扑与条件限制：终端侧、网络侧、机房侧

模板里的网络拓扑图在纯文字文档里没法直接搬，但它的划分方式可以照抄成文字描述：终端侧是发起网络请求的终端设备和软件；网络侧是运营商的网络；机房侧是进行移动化改造的 IT 系统和管理通信设备的移动 OA 服务器。三句话把请求从手机到服务器的路径切成了三段，每段都能单独提需求和排故障。

具体到写作，拓扑这节建议配一张自画的图（用任意画图工具都行），图下面用文字补三件事：一是每段之间的协议与端口，二是跨段传输是否加密、在哪一段解密，三是任一环节不可用时系统表现如何（是排队重试还是直接报错）。第三件事最容易被漏，但它直接决定用户在地铁里点开会话时看到的是「加载中」还是「网络异常，请稍后重试」。

条件与限制在模板里标了「可选」，实际不能省。它包含六类内容：输入数据的范围与格式；必须使用或必须避免的特定技术、工具、编程语言和数据库；企业策略、法规或行业标准；硬件限制，比如定时需求或存储器限制；经费限制与开发期限；对外部组件的依赖。这份模板在系统结构、拓扑各占一节之后仍然保留这一节，就是为了兜住那些「不属于功能、但会卡住开发」的约束。

我一般把条件与限制写成一个两列表：左边写约束，右边写原因和影响。比如「必须使用国产数据库」要配原因（合规要求）和影响（SQL 方言要适配，不能用某些特性）。只写约束不写影响，开发会在踩坑之后回来质问为什么早不说。

4. 功能需求拆解：移动办公、车辆管理、电子公文三条业务线的可验收条目

第三章是整份文档的主体，26 页里占了将近一半。它示范了一件事：功能需求写到什么颗粒度才算合格。判断标准很朴素——开发和测试拿着这条需求，不需要再问任何人就能动手。下面拆三条业务线看模板是怎么做到的。

4.1 移动办公：显示规则、排序规则和附件阈值

移动办公这一章条目最多，从登录、收文审批、发文审批、内办文审批、合同处理审批，到待办待阅、督办、会议、公文查询、会议通知、移动邮件、通讯录、通知通告、领导批示、代理授权、机关名片、消息、短信中心，一张功能表列了三十多项。这张表本身不是需求，它只是目录；真正的需求在后面每个功能点的展开里。

模板展开的第一个功能点就极具代表性——待办公文列表。它没有停在「展示待办公文」这一句，而是写了三件事：

显示规则：两行显示。第一行是公文速级图标、业务种类、接收时间；第二行是公文标题。

排序规则：支持按业务种类排序、按速级排序（特急、急件、平件三种）、按接收时间排序。

详情字段：收文写来文单位、紧急程度、标题、内容摘要、意见；外发文写主办单位、主送单位、抄送单位、事由、紧急程度、拟稿人、密级、意见；内办文在此之外还要有历史意见；督办写事项名称、承办部门、会办部门、密级、紧急程度、督字号、督办类别、要求完成时间、历史意见。

这三件事凑在一起，开发做出来的界面才不会变成「一个列表 + 一堆字段全堆上去」。两行显示是硬约束，因为它决定了手机屏幕上一屏能放几条；三种排序必须写默认值和切换方式，否则开发自己定一个，验收时甲方说不对，返工两天。字段清单里的「历史意见」「密级」「督字号」这类字段，是业务方真正关心的，不写进去，做出来的详情页就是空壳。

附件策略是这段里最能体现「降级思维」的部分：公文正文的文件类型为 Tif、Doc 和 ceb；附件的文件类型无限制，其中 Office 系列、图片格式、Tif 可直接在手机端浏览；提供附件下载功能；超过 5M 的文件提供下载但不能在手机端直接预览。四句话把「什么能看、什么只能下、多大的不给看」全定了，还留了降级路径。这类阈值必须写死，不写就会出现「测试拿了个 8M 的 PDF，开发说预览不了，甲方说这不是应该能看吗」的扯皮。

意见录入这段复杂度最高，也最值得抄。用户可以直接输入意见，也可以从常用词条里选，词条分公用和个人两类。审批意见发送到文秘处长、领导批示、承办、会办等环节；发送时先选环节，环节排序与 OA 中保持一致；如果要选 N 个下一关环节（1≤N≤4），用多级下拉联动菜单实现，上一级选完后，下一级自动过滤不可选环节或自动选中必选环节；当意见发往默认环节的默认人员时，不再出现环节和人员选择界面，直接发送；环节选完后，可以分别对每个环节选人员（含组），全部选完才能发送。

这段文字里藏了五个约束：词条分类、排序与 OA 一致、N 的范围、联动过滤规则、默认路径直发。任何一个不写，开发都会做出一个「能选但选不对」的界面。写需求的人如果只写「支持意见录入和环节选择」，那这份文档基本等于没写。

移动邮件这块写的是实现方式和功能清单：通过 Pop3/Smtp 访问邮件服务器，提供收取、查看列表、查看内容、查看附件、发送、转发、回复、删除功能，并特别注明「删除不同步删除 OA 邮件」。最后这句是典型的边界条款——不写，用户删了邮件以为 OA 里也没了，第二天发现还在，就是一次投诉。

会议管理和通知通告的写法可以归成一类模板：手机端操作流程（登录 → 列表 → 详情）、列表显示规则（两行：标题 + 时间地点或发布时间）、排序规则（按会议时间由新到旧，只显示一周，可查询上周及下周）、详情字段清单、附件处理规则。通讯录则是树形结构、只按部门分类、人员字段五项（姓名、办公电话、手机号码、电子邮件、备注），并与 OA 保持同步，管理员可在 Web 管理页启用或停用用户。

把这些条目落成可追溯的编号，大概长这样：

FR-MOA-012 待办公文列表 触发：用户登录后进入待办页 显示：两行。第一行 公文速级图标 + 业务种类 + 接收时间；第二行 公文标题 排序：默认按接收时间倒序；可切换按业务种类、按速级（特急/急件/平件） 分页：每页 20 条，上拉加载更多 异常：空列表展示空态文案；接口超时 10s 后重试一次并提示

每条功能需求固定四段：触发条件、界面或数据表现、边界与分页、异常处理。前两段决定做出来是什么样，后两段决定出问题时是什么样。只写前两段的文档，测试阶段会被问爆。

4.2 车辆管理与电子公文预览：档案型需求与中间层需求

车辆管理是典型的档案型需求，写法和移动办公完全不同。它不关心界面长什么样，关心的是「记哪些字段、谁来改、改完留不留痕」。模板把模块拆成十块：车辆资料管理、驾驶员档案、车辆费用管理、维护维修记录、车辆申请记录、合格供应商维护、车辆维修计划、车辆安全检查记录、统计分析、权限管理。

档案型需求的写法有个口诀：字段、唯一键、留痕、关联。字段写全，唯一键写清（车牌号、驾驶证号、供应商编号），留痕写明谁在什么时候改了什么，关联写清模块之间的引用关系（费用记录关联车辆，维修计划关联车辆，用车申请关联审批单）。四样齐了，数据库表结构基本就出来了，开发不用再问。

模板还写了部署关系：车辆管理服务器及数据库与 OA 服务器及数据库部署在同一局域网内，通过系统接口实现与 OA 的统一登录认证。这句话把「单点登录」这个模糊需求变成了可验证的事实——同一局域网、走接口、统一认证，测试时就知道该验什么。

电子公文预览是完全不同的一类：它要解决的是「不改动现有系统」的集成问题。模板给出的方案是在两个系统之间搭一个中间层组件，只做三件事：把移动办公访问电子公文的请求重定向到中间层；把电子公文交换及认证平台中的公文转换成移动办公能识别的格式（一般为扫描件格式）；把转换后的文件以文件流形式返回终端显示。三句话把职责卡死，也把「最小改动」这个原则落到了具体动作上。

电子公文交换网络这一节，模板用五个组件把整条链路讲透了：

流程分五步：OA 端生成交换对象并由 CA 签名加密，生成交换 XML 提交给前置；前置按同步或异步走消息队列或 Web Service 提交给交换接口；核心分析路由、解密、按接收单位拆成 N 份分别加密转发；交换接口把数据发往对应前置；前置通过 Web Service 提交给目标 OA 交换。

流程之后是两级回执，这部分是我认为整份模板最有价值的设计之一：前置提交成功后，反向发送送达回执，发送方由此知道哪些单位已送达；任一环节出问题，前一系统自动反向发送失败回执；OA 交换解析来文并入库后，自动向原发文单位发送成功入库回执，解析失败、解密失败、验签失败或入库失败则发解析失败回执。两级回执把「公文到底送没送到、对方能不能看到」从黑匣子变成了可查状态——没有它，用户只能打电话问对方收到没有。

4.3 接口与非功能：把「安全稳定」写成能测的条目

第四章接口需求列了六项：用户界面、硬件需求、网络需求、接口需求、通信需求、运行环境。第五章非功能需求列了五项：性能需求、安全设施需求、安全性需求、扩展性需求、可移植性需求。模板里这两章基本是空架子，只给了标题和填写提示，但这恰恰是最需要补的地方——很多文档写到这儿就没词了，最后交上去两页纸全是「响应快、可用性高」。

我一般的做法是先给基线，再跟甲方确认，确认完写死。下面这套数值可以直接拿去改成自己项目的版本：

写这些指标有个技巧：每条都配「测量方法」和「不达标怎么处理」。只写指标不写测量方法，验收时双方各拿一套标准；不写处理方式，性能差一点就只能靠吵。比如列表首屏超时的处理可以是「优化索引与接口合并，仍不达标则改为骨架屏 + 分片加载」，写在需求里，后面就有得谈。

安全需求分两层写：安全设施是「有什么」，安全性是「防什么」。安全设施写 PKI/CA、传输加密、接入通道、日志审计这些具体组件；安全性写越权访问、重放攻击、暴力登录、敏感数据外泄这些具体场景，每个场景配一条拦截规则。扩展性和可移植性则要落到可验证的动作上——不是「系统易于扩展」，而是「新增一个业务模块，公共组件代码改动为零」。

5. 避坑与常见问题：需求文档写成宣传稿的五种翻车现场

这一章的五条，全是我在评审现场见过的真实翻车。共同点是：写的时候觉得没问题，评审时被一句话问穿。每条按「现象 → 原因 → 解决」写，照着改基本能躲过去。

现象一：背景段落写成宣传稿。整段是「随时随地、零距离、安全稳定、打破时空局限」，读三遍不知道系统服务谁、有多少用户、覆盖哪些终端。评审问「你说的随时随地，地铁里没信号算不算」，当场卡住。

原因：把愿景当需求。愿景是给领导和市场看的，需求文档的读者是开发和测试，两者语言完全不同。

解决：背景段只写四件事——动因、痛点、技术前提、覆盖范围，每句话都要能指到后面某条功能需求。写完自查一遍：这段里每个形容词，后面有没有对应条目。没有就删掉。

现象二：功能条目只有名词没有判定条件。整章是「待办公文列表」「公文详情」「会议管理」「通讯录」，一条一行，看着挺整齐。开发照着做，做出来和甲方想的完全不是一回事。

原因：把菜单当需求。菜单是入口名，需求是入口点进去之后的所有规则。

解决：每条功能至少写清四样——显示什么、怎么排序、字段有哪些、边界在哪里。拿待办公文列表举例，两行显示、三种排序、字段清单、5M 附件阈值，四样齐了才算写完。写不出来的，说明这块业务还没搞清楚，先去问，不要硬编。

现象三：附件与格式需求漏写。上线第一周用户反馈「有个公文打不开」，一查是 ceb 格式，客户端根本没做适配。开发说需求里只写了「支持公文预览」，没说哪几种格式。

原因：默认「预览」是个通用能力，没意识到格式是有限集合，更没意识到大文件需要降级策略。

解决：列格式白名单（正文 Tif、Doc、ceb；附件不限但 Office 系列、图片、Tif 可直接预览），写清大小阈值（超过 5M 提供下载不给预览），写清降级后的界面表现（按钮置灰还是点击提示下载）。三样一起写，后面就不会有人问「这个格式为什么不支持」。

现象四：接口只写「与 OA 对接」。集成阶段两个团队互相等，一个说你先给接口文档，一个说你先定字段。最后拖了两周，靠拉会解决。

原因：接口需求被当成一句话的事，没写协议、方向、频率、失败处理。

解决：每个接口写五要素——协议（Web Service 还是消息队列）、

本文还有配套的精品资源，点击获取