4、需求分析与文档撰写：用户故事（User Story）编写、PRD（产品需求文档）结构、功能与非功能需求

说实话，需求分析这块，我见过太多产品经理栽跟头了。

我刚入行那会儿，也犯过同样的错——拿到一个需求就急着写文档，结果开发做到一半，业务方跑过来说「哎呀，不是这个意思」。嗯，那种感觉，就像你辛辛苦苦搭好了积木，人家说我要的是乐高城堡，不是你这个火柴盒。

所以今天咱们聊聊，怎么把需求这件事做扎实。

4.1 用户故事（User Story）编写

用户故事这东西，说白了就是一张「需求小卡片」。它不复杂，但特别容易写歪。

标准格式就一句话：

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

举个例子：

• 「作为普通用户，我想要用手机号注册，以便快速登录系统」
• 「作为运营人员，我想要查看每日新增用户数，以便评估拉新效果」

你看，三要素都有了：谁要、要什么、为什么。

写用户故事时，有个坑我踩过好几次——把实现细节写进去。

比如：「用户点击提交按钮后，调用API接口，返回200状态码...」

停！这是技术方案，不是用户故事。用户故事只关心「用户能做什么」，不关心「系统怎么实现」。

另外，用户故事要遵循 INVEST 原则：

• Independent（独立的）——不依赖其他故事
• Negotiable（可协商的）——细节可以讨论
• Valuable（有价值的）——对用户有实际价值
• Estimable（可估算的）——开发能估工作量
• Small（小的）——能在一次迭代完成
• Testable（可测试的）——有明确的验收标准

我曾经接手过一个项目，用户故事写了200多个，每个都又大又模糊。结果呢？开发估了半年工期，实际上线用了9个月。嗯，教训深刻。

4.2 PRD（产品需求文档）结构

PRD 这东西，每个公司都有自己的模板。但核心骨架其实差不多。

我个人习惯的结构是这样的：

章节	内容	说明
1. 文档信息	版本号、作者、日期、变更记录	方便追溯，别小看这个
2. 背景与目标	为什么要做？解决什么问题？	让所有人理解「为什么」
3. 用户角色	谁会用这个功能？	列出所有相关角色
4. 功能需求	用户故事 + 业务流程图	核心内容，要详细
5. 非功能需求	性能、安全、兼容性等	容易被忽略，但很重要
6. 数据需求	字段定义、数据字典	后端开发最需要这个
7. 交互说明	页面流转、异常处理	配合原型图使用
8. 附录	术语表、参考资料	方便新人快速上手

你想想看，一份好的 PRD，应该是「开发看了能写代码，测试看了能写用例，业务看了能点头」。

写 PRD 时，我习惯先画流程图。为什么？因为流程图能帮你发现逻辑漏洞。

比如用户下单这个流程：

• 正常流程：选商品 → 加购物车 → 提交订单 → 支付 → 完成
• 异常流程：库存不足怎么办？支付超时怎么办？取消订单后库存怎么恢复？

这些异常情况，如果不提前想清楚，开发做到一半才发现，那返工成本就高了。

4.3 功能需求与非功能需求

功能需求，就是「系统要做什么」。

比如：

• 用户能登录
• 用户能查看订单
• 用户能修改密码

这些是功能需求，看得见摸得着。

非功能需求，是「系统做得怎么样」。

比如：

• 登录响应时间不超过2秒
• 系统支持1000人同时在线
• 密码传输必须加密

这些看不见，但直接影响用户体验。

举个例子，我之前做过一个电商项目。功能需求写得很详细，下单、支付、退款全都有。但非功能需求只写了「系统要稳定」四个字。

结果呢？双十一那天，系统直接挂了。因为并发量一上来，数据库扛不住。你说这是功能问题吗？不是。功能都能用，但性能不行。

所以，非功能需求一定要量化：

类型	指标	示例
性能	响应时间、吞吐量	页面加载 < 3秒
可用性	系统正常运行时间	99.9% 可用
安全性	数据加密、权限控制	密码使用 bcrypt 加密
可扩展性	支持用户增长	支持水平扩展
兼容性	浏览器、设备支持	支持 Chrome、Safari

最后说一句，需求分析这件事，没有捷径。多跟业务方聊，多跟开发对，多画图，多写文档。做得多了，自然就熟了。

我曾经连续三个月，每天跟业务方开半小时的站会，就为了把需求对齐。虽然累，但效果确实好——上线后几乎没有返工。

嗯，今天就聊到这儿。下一章咱们聊聊原型设计和交互规范，那个也很有意思。