1. 项目背景与需求分析：用户故事、功能需求、非功能需求、需求文档编写

我们在做的每个项目，其实都是从一个模糊的想法开始的。团队坐在一起，有人说“咱们做个某某系统吧”，然后大家就开始画原型、敲代码。嗯，我见过太多次这样的场景了。结果呢？需求没对齐，开发完发现根本不是客户要的东西。这背后的根源，说白了就是需求分析没做好。

我在职业生涯早期就踩过这个坑。2009年给一家物流公司做车辆调度系统，产品经理说“要一个派单功能”，开发团队就按字面意思做了个手动派单面板。结果用户真正需要的是基于司机位置和货物重量的自动派单算法。那次返工让我记住了：需求分析不是听用户说了什么，而是搞清楚用户到底要什么。

用户故事：让每个需求都有“人”的视角

我个人习惯在项目启动后第一周，拉着产品和业务方一起写用户故事。用户故事的格式非常固定，但威力巨大：

作为 <用户角色>
我希望 <功能描述>
以便 <业务价值>

举个例子。我最近参与的一个电商后台重构项目，业务方最初提的需求是“要一个可以批量修改商品价格的页面”。这看起来很清楚对吧？但其实它隐含了很多假设。我们用用户故事重新梳理后，变成了这样：

• 作为 商品运营专员，我希望 按品牌筛选出所有商品，以便 统一对某个品牌的商品进行促销调价。
• 作为 价格管理员，我希望 看到每次调价的历史记录，以便 在出现价格异常时可以追溯责任人。
• 作为 财务审核人员，我希望 价格变更在生效前需要经过两级审批，以便 避免误操作导致毛利损失。

你发现了吗？原本一句话的功能，拆成了三个不同角色的故事。每个故事都有了“人”的温度。我曾经在另一个项目中，只写了一个“用户管理”的用户故事，结果开发出来的功能既不适合管理员，又不适合普通用户，最后谁都不满意。

功能需求：把故事变成可执行的任务

用户故事是“做什么”，功能需求是“怎么做”。这部分我最讨厌模棱两可的说法。比如“系统应该响应迅速”，这算需求吗？当然不算。迅速是多快？1秒？0.5秒？200毫秒？

功能需求需要具体到可以测试的程度。我通常会建一张表格，把每个用户故事中的隐含细节提取出来：

用户故事	功能需求编号	功能描述	验收标准
运营专员按品牌筛选商品	FR-001	商品列表页提供品牌多选筛选器，支持按品牌名称搜索	筛选后页面上只显示选中品牌商品；当选中品牌超过10个时，只提示“已选10个”，不展示全名
价格管理员查看调价历史	FR-002	商品详情页增加“调价日志”面板，按时间倒序展示每次变更	日志包含字段：变更时间、操作人、调前价格、调后价格、变更原因；支持按日期范围过滤
财务人员审批价格变更	FR-003	价格变更提交后进入待审批列表，审批通过后24小时自动生效	审批人收到系统消息通知；驳回时需填写原因，商品价格维持原值

这里的每一条功能需求，都对应着一个具体的用户操作场景。写功能需求时，我建议大家问自己三个问题：用户怎么触发？系统怎么响应？异常怎么处理？把这三个问题回答清楚，这个功能需求就扎实了。

非功能需求：那些不说就会出问题的隐形约束

非功能需求，说白了就是系统在质量维度上的要求。我经常和团队讲，功能需求决定了系统能不能用，非功能需求决定了系统好不好用、能不能持续用。

我曾经接手过一个项目，功能需求写得非常完整，但上线第一天就崩了。为什么？因为非功能需求里写了“支持1000人同时在线”，但实际的用户规模是5000人。需求里少写了一个零，后面整个架构都得重做。那是我职业生涯中最痛苦的一次复盘。

常见的非功能需求包括哪些维度？我习惯用这张表来和业务方对齐：

维度	描述	示例指标
性能	系统响应速度和并发处理能力	API响应时间P99 < 500ms；支持2000并发用户
可用性	系统在规定时间内正常工作	核心链路SLA 99.99%；年度计划内停机不超过30分钟
安全性	数据保护和访问控制	所有API需鉴权；用户密码使用bcrypt加密；传输层使用TLS 1.2
可维护性	系统修改和扩展的便利性	代码单元测试覆盖率 > 80%；模块间通过HTTP接口解耦
可伸缩性	系统随负载增长而扩展的能力	支持水平扩展至10个节点；数据库读写分离

在需求调研阶段，非功能需求往往容易被忽略。业务方会觉得“这个你们技术人员自己定就好了”。千万别信这句话。我建议的做法是：直接拿着上面的表格，让业务方在每一项上打分（1-5分），标注出哪些是他们死都不能放弃的。这样一来，技术决策就有了依据。

需求文档编写：把碎片拼成蓝图

用户故事、功能需求、非功能需求都梳理完毕后，最后一步是整理成一份结构化的需求文档。这部分很多人写成了“流水账”，其实完全不是。一份好的需求文档，应该像一本说明书——给不同的人读，能快速找到他们关心的内容。

我个人在项目中常用的需求文档结构是：

1. 项目背景与目标——一句话说清楚为什么要做这个项目，期待达到什么效果。
2. 用户角色定义——列出所有与系统交互的角色，每个角色给一个简短描述。
3. 用户故事清单——按模块或价值排序的用户故事，每个故事标记优先级（P0/P1/P2）。
4. 功能需求规格——与用户故事一一对应的功能需求，包含验收标准。
5. 非功能需求规格——按维度列出的质量指标，给出可度量的阈值。
6. 术语表——统一项目中的业务术语和缩写，避免沟通歧义。
7. 变更记录——记录每次需求变更的日期、内容、原因和影响范围。

你可能会问，需求文档要不要写得特别详细？我的答案是：该详细的地方详细，不该详细的地方留白。业务逻辑的边界、判断条件、异常流程，这些必须写清楚；但具体的UI布局、交互动效，这些可以交付给原型或设计稿去表达。

好了，说到这里，我们把本章的知识体系梳理一下。从项目启动时的模糊想法，到用户故事的角色化拆解，再到功能需求和非功能需求的细化落地，最后归档为结构化的需求文档。整个过程环环相扣，每一个环节的缺失，都可能导致后面开发的连锁反应。

看到这张图，你应该能理解需求分析在项目中的定位了。它是从“想法”到“可执行文档”的桥梁。很多人觉得写需求浪费时间，想直接跳过去写代码。我劝你千万别这么干。等到项目后期因为需求不清返工的时候，你会发现那点时间的成本根本不够看。