第二章 需求文档撰写：用户故事编写技巧、功能需求与非功能需求的区分、需求优先级标注方法
需求文档这东西，说难不难，说简单也不简单。我见过太多项目，代码写得漂漂亮亮，最后却因为需求没对齐而翻车。说白了，需求文档就是整个信号系统的「宪法」——它决定了后续所有工作的边界和方向。
今天咱们就聊聊需求文档撰写的三个核心技能：用户故事怎么写才接地气、功能需求和非功能需求到底怎么分、以及优先级怎么标才不打架。
2.1 用户故事编写技巧
用户故事不是写作文，更不是列清单。我刚开始带项目时，也犯过「把用户故事写成功能说明书」的毛病。后来踩了几次坑才明白，用户故事的核心是「沟通的桥梁」，而不是「需求的枷锁」。
2.1.1 标准模板：As a... I want... So that...
这个模板大家应该都见过：
作为【用户角色】
我想要【功能目标】
以便于【业务价值】举个例子，咱们做雷达信号处理系统：
作为【雷达操作员】
我想要【实时查看目标回波信号的频谱图】
以便于【快速判断目标类型和运动状态】你看，这个描述里没有写「用FFT算法计算频谱」，也没有写「采样率设为10MHz」。为什么？因为用户故事关注的是「用户要什么」，而不是「系统怎么做」。
2.1.2 编写技巧：INVEST原则
我在项目中用过一套很实用的检查标准，叫INVEST。每个字母代表一个维度：
| 字母 | 含义 | 说明 |
|---|---|---|
| I | Independent（独立的） | 故事之间尽量不依赖，可以独立开发和测试 |
| N | Negotiable（可协商的） | 不是铁律，团队可以讨论细节 |
| V | Valuable（有价值的） | 对用户或业务有明确价值 |
| E | Estimable（可估算的） | 团队能大致评估工作量 |
| S | Small（小粒度的） | 能在一次迭代内完成 |
| T | Testable（可测试的） | 有明确的验收标准 |
嗯，这里要注意——很多新手容易把用户故事写得太「大」。比如「作为用户，我想要一个完整的信号分析平台」，这故事大到没法估算了。我建议拆成多个小故事，比如「查看时域波形」、「查看频谱」、「导出数据」等等。
2.1.3 验收条件：别让故事变成空话
光有故事还不够，还得有验收条件。我曾经吃过这个亏——故事写完了，开发也做完了，结果测试说「这不对啊，用户要的是实时显示，你这延迟了2秒」。你看，问题出在验收条件没写清楚。
验收条件一般用「Given... When... Then...」格式：
Given（给定）：雷达处于正常工作状态，目标在探测范围内
When（当）：操作员点击「开始频谱分析」按钮
Then（那么）：系统应在1秒内显示目标回波的频谱图，频率分辨率不低于1kHz2.2 功能需求与非功能需求的区分
这个区分，说实话，很多做了两三年的工程师都搞不太清楚。我见过有人把「系统要稳定运行」写在功能需求里，也有人把「支持WiFi连接」写在非功能需求里。咱们今天把它理清楚。
2.2.1 功能需求：系统「做什么」
功能需求描述的是系统应该提供的具体行为或功能。说白了，就是用户能用系统「干哪些事」。
信号系统里常见的功能需求：
- 系统应支持采集ADC数据，采样率可配置为1MHz、10MHz、100MHz
- 系统应提供FIR滤波器，截止频率可调
- 系统应支持将处理后的数据导出为CSV格式
- 系统应显示实时波形，支持缩放和平移
你看，这些都是「做什么」——采集、滤波、导出、显示。每个功能需求都对应一个具体的操作或输出。
2.2.2 非功能需求：系统「做得怎么样」
非功能需求描述的是系统的质量属性或约束条件。它不关心「做什么」，而是关心「做得好不好」或者「在什么条件下做」。
常见的非功能需求分类：
| 类别 | 示例 |
|---|---|
| 性能 | 信号处理延迟不超过50ms |
| 可靠性 | 系统连续运行72小时无故障 |
| 安全性 | 数据传输采用AES-256加密 |
| 可维护性 | 代码注释覆盖率不低于30% |
| 兼容性 | 支持Windows 10/11和Ubuntu 20.04/22.04 |
2.2.3 区分技巧：问自己两个问题
如果你不确定某个需求是功能还是非功能，问自己两个问题：
- 这个需求描述的是「一个操作」还是「一个属性」？操作→功能需求，属性→非功能需求。
- 去掉这个需求，用户还能不能用系统？能用但体验差→非功能需求；不能用→功能需求。
举个例子：「系统应在5秒内完成启动」。去掉它，系统还能启动吗？能，只是慢一点。所以它是非功能需求（性能）。而「系统应支持用户登录」，去掉它，用户根本进不去系统，所以它是功能需求。
2.3 需求优先级标注方法
需求永远做不完，资源永远不够用。你想想看，哪个项目不是这样？所以优先级标注就成了需求文档里最关键的一环。
2.3.1 MoSCoW方法：最实用的优先级模型
我个人最常用的是MoSCoW方法，简单粗暴：
| 优先级 | 含义 | 说明 |
|---|---|---|
| M - Must have | 必须有 | 没有这个需求，系统无法上线或无法满足核心业务 |
| S - Should have | 应该有 | 很重要，但暂时没有也能接受，可以后续迭代 |
| C - Could have | 可以有 | 锦上添花的功能，有最好，没有也不影响核心 |
| W - Won't have | 不会有 | 明确本次不做，但记录下来供未来参考 |
举个例子，一个信号采集系统的需求优先级：
M - 支持ADC数据采集，采样率可配置
M - 实时显示采集波形
S - 支持波形回放功能
S - 导出数据为MAT文件
C - 支持多通道同时显示
C - 波形颜色可自定义
W - 支持远程控制采集
W - 集成AI自动识别功能2.3.2 Kano模型：从用户满意度角度思考
除了MoSCoW，我还偶尔用Kano模型来辅助判断。Kano模型把需求分为三类：
- 基本型需求：用户觉得「理所当然」的功能。比如信号采集系统必须能采集数据。这类需求优先级最高，不做就完蛋。
- 期望型需求：用户明确提出的功能。比如「我想要一个频谱分析功能」。这类需求做得好，用户满意度会线性提升。
- 兴奋型需求：用户没想到的功能。比如「系统能自动识别异常信号并报警」。这类需求做出来会让用户惊喜，但优先级可以放低。
你想想看，如果基本型需求没做好，用户会直接骂娘。但如果兴奋型需求没做，用户也不会觉得少了什么。所以优先级排序应该是：基本型 > 期望型 > 兴奋型。
2.3.3 优先级标注的常见误区
我见过太多项目在优先级上翻车，这里列几个常见的坑：
- 全是Must have：如果所有需求都是最高优先级，那等于没有优先级。我一般要求Must have不超过总需求的20%。
- 优先级和难度混淆：「这个功能很难做，所以优先级高」——这是错的。优先级应该由业务价值决定，不是由技术难度决定。
- 优先级一成不变：需求是会变的。我建议每个迭代开始前重新审视一次优先级，别让三个月前的优先级决定今天该做什么。
2.4 小结
需求文档撰写这件事，说到底就是三个字：对齐、量化、排序。
用户故事帮你对齐用户和开发团队的理解，功能需求和非功能需求的区分帮你量化系统的边界和质量，优先级标注帮你排序哪些先做哪些后做。
嗯，今天就聊到这里。下一章咱们聊聊系统架构设计文档怎么写——那可是整个项目的骨架，比需求文档还要命。