第二章 需求分析实战：用户需求的捕获与分析方法、功能需求与非功能需求的权衡、需求文档的编写规范
各位工程师朋友，欢迎来到实战手册的第二章。说实话，需求分析这活儿，看着简单，做起来全是坑。我见过太多项目，设计图纸画得漂漂亮亮，结果装车一跑，运营方骂娘、乘客投诉、维修方摔扳手。为什么？需求没吃透。
这一章，我就把我在车门系统项目里摸爬滚打的经验，掰开了揉碎了讲给你听。咱们不聊虚的，直接上干货。
2.1 三类用户的需求捕获：谁才是真正的“甲方”？
车门系统不是给一个人用的。它的用户至少有三类：运营方、乘客、维修方。这三类人的诉求，有时候是冲突的。你想想看，运营方要效率，乘客要舒适，维修方要方便——这三者能完全一致吗？不可能。
所以，第一步就是搞清楚：谁的需求优先级更高？我的经验是，安全永远是第一位的，在这个前提下，再去平衡效率、舒适和可维护性。
2.1.1 运营方的需求：安全、可靠、高效
运营方是谁？地铁公司。他们最关心什么？说白了就三件事：别出事、别晚点、别多花钱。
- 安全需求：车门防夹功能必须可靠，不能夹人。我记得有一次，某个项目在试运行阶段，车门防夹力阈值设得太高，结果夹住了一个背包带，列车直接紧急制动。运营方当时就炸了。所以，安全相关的需求，必须量化，比如“防夹力不超过150N”。
- 可靠性需求：车门系统平均无故障时间（MTBF）要达标。我建议，这个指标不能低于100万次开关门循环。为什么？因为地铁每天开关门几百次，一年下来就是几十万次。你想想看，如果MTBF只有50万次，那半年就得大修一次，运营方能接受吗？
- 效率需求：开关门时间要短。比如，从收到开门指令到门完全打开，时间不能超过3秒。关门也一样。这个时间直接影响列车停站时间，进而影响发车频率。
核心要点：运营方的需求，必须用数字说话。不要写“车门要可靠”，要写“MTBF ≥ 100万次”。
2.1.2 乘客的需求：舒适、便捷、安全
乘客是最终用户。他们的需求其实很朴素：别夹到我、别关太快、别太吵。
- 舒适性需求：开关门动作要平顺，不能有顿挫感。关门时的蜂鸣器声音要适中，不能太刺耳。我曾经遇到过，某个供应商把蜂鸣器音量调到了90分贝，结果乘客投诉说“像火警一样”。后来我们改成了65-75分贝，才没人投诉了。
- 便捷性需求：车门开启宽度要足够，方便携带行李的乘客上下车。一般要求净开宽度不小于1300mm。另外，车门附近的指示灯要清晰，让乘客知道哪边门会开。
- 安全性需求：乘客最怕的就是被夹。所以，防夹功能不仅要灵敏，还要有“二次尝试”机制——第一次没关上，自动再开一次，然后再关。这个逻辑，我建议一定要写在需求里。
小提示：乘客的需求，往往是通过投诉和调研得来的。我建议你在项目初期，就去地铁站蹲点，观察乘客上下车的行为。你会发现很多意想不到的细节。
2.1.3 维修方的需求：易维护、易诊断、易更换
维修方是“幕后英雄”。他们的需求如果没满足，最后吃苦的还是你自己——因为故障处理时间会很长。
- 易维护性需求：车门系统的关键部件，比如电机、控制器、丝杠，要方便拆卸和更换。我建议，更换一个车门控制器的平均时间，不能超过15分钟。这个指标，要在设计阶段就考虑进去。
- 易诊断性需求：系统要有自诊断功能。车门出了故障，维修人员插上诊断仪，就能看到故障代码和故障原因。比如“车门1：防夹力超限，故障代码E023”。没有这个，维修方就得一个一个排查，效率极低。
- 易更换性需求：备件要通用化。同一个型号的车门，部件要能互换。我记得有个项目，因为不同批次的车门电机接口不一样，维修方每次换件都得改线束，气得他们直接投诉到运营方那里去了。
避坑指南：我曾经见过一个项目，维修方需求完全被忽略。结果车门坏了，维修人员要拆掉整个门板才能换一个传感器。后来运营方要求我们重新设计，成本翻了三倍。所以，维修方的需求，一定要在需求文档里占一席之地。
2.2 功能需求与非功能需求的权衡：别让“完美”毁了项目
需求分析里，最难的不是写需求，而是做权衡。功能需求和非功能需求，经常打架。比如，你想要车门开关速度更快（功能需求），但电机功率就得加大，功耗和噪音就上去了（非功能需求）。怎么办？
我的做法是：先列清单，再排优先级。
2.2.1 功能需求清单
功能需求，就是系统“做什么”。对于车门系统，典型的功能需求包括：
| 功能需求 | 描述 | 优先级 |
|---|---|---|
| 开门功能 | 接收到开门指令后，车门在3秒内完全打开 | 高 |
| 关门功能 | 接收到关门指令后，车门在3.5秒内完全关闭 | 高 |
| 防夹功能 | 关门过程中，若检测到障碍物，立即停止并反向开门 | 高 |
| 紧急解锁功能 | 在紧急情况下，乘客可通过手动操作打开车门 | 高 |
| 蜂鸣器提示 | 关门过程中，蜂鸣器发出提示音 | 中 |
2.2.2 非功能需求清单
非功能需求，就是系统“做得怎么样”。包括：
| 非功能需求 | 描述 | 优先级 |
|---|---|---|
| 可靠性 | MTBF ≥ 100万次 | 高 |
| 可维护性 | 更换控制器时间 ≤ 15分钟 | 高 |
| 噪音 | 开关门噪音 ≤ 65分贝 | 中 |
| 功耗 | 单门平均功耗 ≤ 50W | 中 |
| 电磁兼容性 | 符合EN 50121标准 | 高 |
2.2.3 权衡的艺术
当功能需求和非功能需求冲突时，我一般遵循三个原则：
- 安全优先：任何与安全相关的需求，优先级最高。比如，防夹功能不能为了追求速度而牺牲灵敏度。
- 法规优先：行业标准（如EN 14752）里明确要求的指标，必须满足，没得商量。
- 成本与性能平衡：如果某个非功能需求（比如噪音）可以通过增加成本来实现，那就需要和运营方沟通，看他们是否愿意买单。
我的经验：有一次，运营方要求车门开关速度提升到2.5秒以内。但我们的电机和传动系统，如果提速，噪音会超过70分贝。最后我们和运营方开了三次会，最终达成一致：速度保持3秒，噪音控制在65分贝以下。这就是权衡。
2.3 需求文档的编写规范：写清楚，别让人猜
需求文档是项目的“宪法”。写得好，项目就成功了一半。写得不好，后面全是扯皮。
我个人习惯，需求文档必须包含以下几个部分：
2.3.1 需求编号与分类
每个需求都要有唯一的编号。比如：
REQ-FUNC-001：功能需求REQ-NFUNC-001：非功能需求REQ-INTER-001：接口需求
这样，后续的测试、变更管理，都能追溯到具体需求。
2.3.2 需求描述模板
我建议，每个需求都按这个模板来写：
需求编号：REQ-FUNC-001
需求名称：车门防夹功能
需求描述：在关门过程中，若车门遇到障碍物（如乘客身体、行李），系统应在100ms内检测到，并立即停止关门动作，反向开门至完全打开位置。
验收标准：
1. 防夹力峰值不超过150N。
2. 从检测到障碍物到反向开门启动，时间不超过200ms。
3. 反向开门后，车门保持打开状态至少3秒。
优先级：高
来源：运营方安全需求
小技巧：验收标准一定要可量化。不要写“防夹功能要灵敏”，要写“防夹力不超过150N”。这样，测试人员才知道怎么测。
2.3.3 需求变更管理
需求一定会变。我见过最夸张的项目，需求文档改了30多版。所以，一定要有变更管理流程：
- 任何需求变更，必须填写《需求变更申请单》。
- 变更必须经过评审，由运营方、设计方、测试方共同签字。
- 变更后，需求文档版本号要更新，并记录变更历史。
避坑指南：我曾经遇到过一个项目，运营方口头说“把关门时间缩短0.5秒”，我们工程师直接改了代码。结果测试时发现，防夹功能失效了。为什么？因为速度太快，传感器来不及响应。从那以后，我规定：任何需求变更，必须走书面流程，哪怕只是改一个数字。
2.4 本章小结
需求分析，说白了就是“搞清楚用户要什么，然后写下来”。但真正做好，需要经验、沟通和一点点“较真”的精神。
记住三点：
- 用户需求要分类捕获，运营方、乘客、维修方，一个都不能少。
- 功能需求和非功能需求要权衡，安全第一，法规第二，成本第三。
- 需求文档要规范，编号、描述、验收标准、变更管理，缺一不可。
下一章，我们会进入系统架构设计。到时候，我会带你看看，如何把这些需求，变成一张张架构图。咱们下章见。