ARTICLE · 1292468
项目文档|搞定软件需求规格说明书:每章写什么、写到什么程度
写需求规格说明书，框架没搭对，后续返工成本往往很高。GB/T 9385-2008《计算机软件需求规格说明规范》和 GB/T 8567-2006《计算机软件文档编制规范》已经把“该写什么、怎么组织”讲得比较清楚。最近，笔者结合多个项目中的实际经验做了梳理，最终归拢为七章。下面和大家分享一下每章该写什么、写到什么程度，希望能给有需要的朋友们一些参考。
1 引言
引言的任务是交代清楚这份文档为谁写、管什么、谁来读、依据什么，让读者在进入正文前建立基本预期。
（1）编写目的：说明文档的编制意图、所针对的软件产品。
（2）范围：说明文档覆盖的功能范围与使用边界，说明它做什么、不做什么。
（3）预期读者：明确文档面向哪些读者，说明各类读者的阅读侧重与关注点，便于读者按需取用。
（4）术语与缩略语：收录全文出现的术语、简写和缩略语，确保同一概念前后叫法一致。
（5）引用文件：列出引用的标准、规范或项目文件。
2 总体描述
这一章描述影响产品及其需求的一般因素，不展开具体需求，为第 3 章提供背景。
（1）产品描述：说明产品在所处环境中的定位。独立则写明独立；是更大系统的组成部分，则说明软件功能与系统需求的关系及主要外部接口，可用框图辅助。
（2）产品功能：对主要功能做高层概括，让读者先建立整体认知。
（3）用户特点：描述预期用户群体的教育程度、经验水平、技术专长等一般特征，必要时说明可访问性考虑。
（4）约束条件：列出影响设计与实现的限制，如法规要求、硬件限制、接口约束、需遵循的标准、安全考量等。
（5）假设与依赖关系：写明被假定成立的前提和对外部系统或组件的依赖；这些前提若变化，哪些需求会受影响，也应指出。
3 功能需求
功能需求是 SRS 的主体，按业务模块或功能点组织，每条建议包含：唯一标识符、功能描述、输入与输出、概要处理逻辑、异常或错误处理。唯一标识符是后续追溯的基础，不可省略。
写法上遵循几条原则：用“应”表达强制需求，用“宜”表达期望，用“可”表达可选；每条需求只陈述一件事；不写实现方案，需求说“做什么”，不说“怎么做”。整体写到可开发、可测试、可验收的程度。避免“快速”“友好”“灵活”等无法验证的形容词，也不要把多条需求揉进一句话。
4 非功能需求
按性能、可靠性、安全性、可维护性、可移植性等类别组织。这一节最容易写成形容词堆砌，底线是每项指标都可量化、可验证。
性能写明响应时间、吞吐量、容量、资源占用上限；可靠性写明平均无故障时间、恢复时间、可用性指标；安全性写明访问控制、数据保护、审计要求；可维护性写明修改难易程度与文档要求；可移植性写明平台依赖与迁移条件。
5 数据需求
说明系统需要处理的数据类型、数据格式与数据量级。若涉及数据迁移，写明迁移范围、迁移方式与校验要求；若涉及数据存储，写明存储介质、容量规划与备份策略。数据需求与功能需求、非功能需求之间的关联应可追溯。
6 环境需求
说明运行所需的硬件、软件、网络及其他环境条件。软件环境应写明操作系统、数据库、中间件、运行时（如 JDK）及浏览器等类别与版本要求。版本号不能省——部署阶段的大量扯皮都源于此。
7 其他需求
（1）接口需求：描述产品对外提供的接口以及依赖的外部接口，包括用户界面、硬件接口、软件接口与通信接口；说明各类接口的逻辑特征与约束，不逐项展开技术细节。
（2）界面需求：描述界面风格、布局、交互的总体要求，可引用组织级 UI 标准；不逐页描述具体界面，那属于设计阶段的工作。
一句话概括：引言定边界与读者，总体描述定背景与约束，功能需求写到“三可”，非功能需求写到“可量化”，数据与环境写到“可落地”，其他需求写到“不越界”。
之前有朋友需要模板，因此给大家附了一份可直接套用的 Word 提纲模板。获取方式：关注本公众号，在后台私信回复关键词「需求规格说明书」，即可获取下载链接。
资料整理不易，如果对你有帮助，欢迎点赞、在看或转发给需要的朋友。
推荐阅读
