1. SRS概述：什么是SRS、SRS在项目中的价值、SRS与用户故事的区别

1.1 什么是SRS？说白了就是一份“契约”

SRS，全称是 Software Requirements Specification，中文叫《软件需求规格说明书》。

我个人习惯把它理解成一份“契约”。

你想想看，一个项目里，产品经理、开发、测试、客户，大家脑子里的想法肯定不一样。产品经理觉得“做个登录功能很简单”，开发觉得“登录要支持OAuth2.0”，客户觉得“我要能微信扫码登录”。

如果没有一份白纸黑字的东西，最后肯定吵翻天。

SRS就是干这个的。它把所有的功能、性能、约束条件，一条一条写清楚。谁也别含糊。

我在项目中遇到过最典型的情况：客户口头说“报表要快”，结果上线后嫌加载慢。我翻出SRS，上面写着“报表加载时间不超过3秒”，客户没话说了。你看，这就是SRS的价值——它是个保护伞。

1.2 SRS在项目中的价值——不只是文档

很多人觉得写SRS就是走形式，浪费时间。我以前也这么想。

直到有一次，一个项目做了三个月，开发快写完了，客户突然说“我要的不是这个功能”。我们翻出当初的聊天记录，发现需求理解完全跑偏了。嗯，那次返工的成本，够写十份SRS了。

SRS的价值，我总结为三点：

• 沟通的桥梁：让客户、产品、开发、测试说同一种语言。避免“我以为你知道”。
• 项目的基线：所有设计、编码、测试、验收，都以SRS为准。变更需求？可以，先改SRS，再谈工期和成本。
• 历史的存档：项目做完后，SRS就是最宝贵的知识资产。新人接手、系统维护，全靠它。

1.3 SRS与用户故事的区别——一个是蓝图，一个是便签

这个问题经常有人问。我直接说结论：SRS是完整的蓝图，用户故事是敏捷的便签。

用户故事（User Story）是敏捷开发里的概念。格式很简单：

作为<角色>
我想要<功能>
以便<价值>

比如：

作为普通用户
我想要用手机号注册
以便快速体验产品

你看，用户故事很轻量，几句话就说完了。它强调的是“沟通”，而不是“记录”。团队拿到用户故事后，会面对面讨论细节。

但SRS不一样。SRS要把所有细节写死。比如注册功能，SRS里会写：

• 手机号格式：11位数字，以1开头
• 验证码有效期：5分钟
• 密码规则：8-16位，包含字母和数字
• 错误提示：手机号已注册时，显示“该手机号已注册”

我做个对比表格，你一看就明白：

对比维度	SRS	用户故事
详细程度	非常详细，每条需求精确到细节	很简略，只描述核心意图
使用场景	传统瀑布模型、需要严格合同的项目	敏捷开发、快速迭代的项目
变更成本	高，需要走变更流程	低，随时可以调整
文档长度	几十页到几百页	几句话到几段话
主要读者	客户、项目经理、开发、测试、运维	开发团队、产品经理

1.4 什么时候用SRS，什么时候用用户故事？

这个问题没有标准答案。我个人的经验是：

• 项目规模大、周期长、客户明确：用SRS。比如银行系统、医疗系统、政府项目。这些项目容不得半点含糊。
• 项目小、需求变化快、团队内部使用：用用户故事。比如创业公司的MVP、内部工具。
• 折中方案：先用用户故事快速沟通，再整理成SRS存档。我很多项目就是这么干的。

说白了，工具是死的，人是活的。别被方法论框死。

1.5 本章小结

这一章我们聊了：

• SRS是什么——一份精确的“契约”
• SRS的价值——沟通、基线、存档
• SRS与用户故事的区别——蓝图 vs 便签

下一章，我会带你手把手拆解SRS的标准结构。嗯，到时候你会看到，一份好的SRS长什么样。