第四章：需求工程优化：需求获取与管理的常见陷阱、如何提升需求可追溯性、工具链整合实践

4.1 需求获取：那些年我们踩过的坑

需求获取，听起来简单吧？不就是跟客户聊聊天，把要求记下来嘛。

我刚开始做项目时也这么想。结果呢？项目做到一半，客户突然说「这不是我要的」。那种感觉，就像你辛辛苦苦做了道菜，对方说「我其实想吃面」。

为什么会这样？因为需求获取有几个典型的陷阱，我一个个说。

陷阱一：只听「显性需求」，忽略「隐性需求」

客户说「我要一个报警功能」。你做了个蜂鸣器，客户却说「太吵了」。其实他想要的是「静默报警」——仪表盘上闪个灯就行。

我在项目中遇到过类似情况。客户说「车速超过120要提醒」，我们做了个声音报警。结果客户试驾后说：「我老婆在睡觉，别吵她。」你看，隐性需求是「不打扰乘客」。

我的经验：需求获取时，多问一句「为什么」。客户说「要A」，你问「A解决了什么问题？」往往能挖出真正的需求。

陷阱二：需求「说清楚」不等于「写清楚」

口头沟通效率高，但容易失真。我记得有一次，客户在会议上说「这个功能要快」。大家点头说「明白」。结果开发做了100ms响应，客户说「我要的是50ms」。

你看，「快」这个字，每个人理解都不一样。我现在的习惯是：任何模糊的描述，必须量化。比如「响应时间≤100ms」「支持1000个并发用户」。

陷阱三：需求「冻结」太早或太晚

太早冻结，客户后面提新需求，你改起来痛苦。太晚冻结，开发团队天天改需求，项目永远做不完。

我个人习惯的做法是：设定一个「需求基线」时间点。在此之前，需求可以随意变更。在此之后，变更要走正式的变更控制流程。这样既灵活又可控。

避坑指南：我曾经有个项目，客户在开发阶段频繁改需求。团队疲于奔命，最后交付质量很差。后来我强制要求：所有变更必须填写《需求变更申请单》，由CCB评审。虽然流程变重了，但项目反而顺利了。

4.2 需求可追溯性：从「一团乱麻」到「清晰脉络」

需求可追溯性，说白了就是「从客户的一句话，到代码里的一行，你都能找到对应关系」。

你想想看，如果没有追溯性，客户问「这个功能对应哪个需求？」你翻半天文档找不到。或者测试发现一个bug，你不知道它影响了哪些需求。

为什么追溯性这么难？

我总结了几点原因：

  • 需求粒度不一致：有的需求写得很粗，有的写得很细。粗的需求没法直接对应到代码。
  • 需求变更后，追溯关系没更新：需求改了，但对应的设计、测试用例还是旧的。
  • 工具链割裂：需求在Word里，设计在Visio里，代码在Git里，测试在Excel里。怎么追溯？

如何建立有效的追溯性？

我的做法分三步：

  1. 统一需求编号：每个需求必须有唯一ID。比如「REQ-SYS-001」「REQ-SW-002」。不要用「需求1」「需求2」这种。
  2. 建立追溯矩阵：用表格记录需求与设计、代码、测试用例的对应关系。
  3. 工具自动维护：手动维护太累，而且容易出错。后面我会讲工具链整合。
小技巧：我习惯在代码注释里直接写需求ID。比如 // REQ-SYS-001: 车速超过120时报警。这样代码和需求直接关联，查起来特别方便。

追溯矩阵示例

需求ID 需求描述 设计文档 代码模块 测试用例
REQ-SYS-001 车速超过120km/h时，仪表盘显示报警图标 SDD-03-仪表报警设计 speed_alarm.c TC-ALARM-001
REQ-SYS-002 报警图标为红色三角形，闪烁频率1Hz SDD-03-仪表报警设计 icon_display.c TC-ALARM-002

4.3 工具链整合实践：让工具为你工作

工具链整合，说白了就是让需求管理工具、设计工具、代码管理工具、测试工具之间「说同一种语言」。

我见过太多团队：需求在DOORS里，设计在Enterprise Architect里，代码在GitLab里，测试在JIRA里。每次追溯需求，要打开四五个工具，手动查来查去。效率低不说，还容易漏。

我的工具链整合方案

我推荐一个轻量级的方案，适合中小团队：

  • 需求管理：用JIRA或Polarion。这两个工具都支持需求结构化存储和追溯。
  • 设计建模：用Enterprise Architect或PTC Integrity。它们可以导出需求到JIRA。
  • 代码管理：用GitLab。在commit message里写需求ID，比如 git commit -m "REQ-SYS-001: 实现车速报警功能"。
  • 测试管理：用TestRail或JIRA的插件。测试用例直接关联需求ID。
关键点：所有工具必须支持「双向追溯」。也就是说，从需求能查到代码，从代码也能查到需求。这样才叫真正的整合。

实际操作示例

假设你在JIRA里有一个需求 REQ-SYS-001。开发人员提交代码时，在commit message里写上 REQ-SYS-001。GitLab会自动把这个commit关联到JIRA的需求上。

测试人员创建测试用例时，也关联 REQ-SYS-001。这样，你打开JIRA里的这个需求，就能看到：

  • 对应的代码commit
  • 对应的测试用例
  • 测试结果（通过/失败）

是不是很方便？

避坑指南：我曾经有个项目，工具链整合做得很好，但没人维护。需求变了，代码commit没更新关联。测试用例也没更新。结果追溯矩阵全是错的。所以，工具链整合不是一次性工作，需要持续维护。

4.4 总结：需求工程优化的三个关键

好了，说了这么多，我总结一下需求工程优化的三个关键点：

  1. 需求获取：多问「为什么」，量化模糊描述，设定需求基线。
  2. 需求可追溯性：统一编号，建立追溯矩阵，用工具自动维护。
  3. 工具链整合：选择支持双向追溯的工具，持续维护关联关系。

你想想看，如果这三个点都做到了，需求工程还会是瓶颈吗？

嗯，下一章我会讲「设计阶段如何避免返工」，到时候见。

← 上一章 📖 返回目录 下一章 →