一、需求工程导论：需求的定义与层次、需求工程的目标与挑战、MBSE概述

1.1 需求到底是什么？——先聊聊我的理解

做了这么多年系统架构，我经常被问到同一个问题：「需求不就是用户想要什么吗？」

嗯，这话对，但不全对。

我习惯把需求看作一道「翻译题」。用户说「我想要一辆跑得快的车」，你不能直接扔给他一台F1赛车——他可能只是想上下班代步，顺便周末能超个车。你看，这里就有两层意思：用户表达出来的，和他真正需要的。

在MBSE（基于模型的系统工程）里，我们管这个叫「需求层次」。说白了，需求不是一句话，而是一个金字塔。

你想想看，如果这三层没对齐，后面做出来的东西大概率要返工。我在一个航空项目中就吃过这个亏——业务说要「提高飞行安全」，用户说要「减少飞行员告警疲劳」，结果我们直接上了个更灵敏的告警系统。最后呢？飞行员被吵得关了告警。嗯，这就是典型的层次错位。

1.2 需求工程的目标：不只是「写文档」

很多人以为需求工程就是写需求文档。我刚开始也这么想，直到有一次项目延期了三个月，原因竟然是「需求里没写系统要支持中文输入」。

从那以后，我意识到：需求工程的目标是「减少不确定性」。

具体来说，有四个核心目标：

1. 获取真实需求——不是用户说的，而是用户真正需要的。我常用「场景推演法」：让用户描述一个完整的工作日，而不是直接问「你要什么功能」。
2. 达成共识——所有干系人对需求的理解一致。这很难，我建议用模型（比如UML用例图）代替文字描述，因为「一张图胜过千言万语」。
3. 管理变更——需求一定会变。别想着一次冻结，要建立变更控制流程。我记得有个项目，客户每周改一次需求，后来我们用了「变更影响分析矩阵」，他才意识到每次改动都要花多少钱。
4. 验证与确认——「我们做对了系统吗？」（验证）和「我们做的是对的系统吗？」（确认）。这两个问题不一样，我经常在评审会上问团队：「你确定这是客户要的，还是你猜的？」

1.3 需求工程的挑战：为什么这么难？

说实话，做了十几年需求，我觉得最难的不是技术，而是「人」。

常见的挑战有这几个：

挑战	表现	我的应对
需求模糊	「系统要易用」——什么叫易用？	用可量化的指标定义，比如「新员工培训时间≤2小时」
干系人冲突	市场部要功能多，研发部要工期短	用优先级矩阵，让所有人一起打分
需求蔓延	做着做着，客户不断加新功能	设立「需求冻结点」，之后只接受变更请求
沟通鸿沟	业务人员和技术人员「鸡同鸭讲」	用模型作为共同语言，比如SysML图

我曾经在一个项目中，客户说「系统要稳定」，我们理解成「不宕机」。结果验收时，客户说「我说的稳定是指界面布局不要变来变去」。你看，同一个词，两种理解。从那以后，我要求所有关键术语都要在词汇表里明确定义。

1.4 MBSE概述：从文档到模型的转变

好了，聊了这么多传统需求工程的痛点，现在说说MBSE。

MBSE（基于模型的系统工程），说白了就是用模型代替文档来管理需求、设计、验证等所有信息。

为什么要有MBSE？我举个例子。

传统方式下，需求在Word里，设计在Visio里，测试在Excel里。它们之间有没有矛盾？不知道。改了需求，设计要不要改？得人工去查。这就像用一堆散落的拼图，每次都要重新拼一遍。

而MBSE把所有信息集中在一个统一的模型里。需求变了，模型自动告诉你哪些设计元素受影响。这才是真正的「可追溯性」。

MBSE的核心要素，我总结为三点：

• 单一数据源——所有信息都存储在模型中，没有「多个版本」的问题。
• 语义一致性——模型里的每个元素都有明确的含义，不会出现「稳定」这种歧义词。
• 自动化分析——模型可以自动检查一致性、完整性。比如，你可以让工具自动检查「每个需求是否至少对应一个设计元素」。

当然，MBSE不是银弹。它需要工具（比如IBM Rhapsody、MagicDraw、Capella），更需要团队改变工作习惯。我建议不要一下子全面铺开，先选一个子系统做试点，让大家尝到甜头再说。

1.5 小结：我的三点建议

讲到这里，我想给你三个最实用的建议：

1. 别把需求当「填空题」——需求是探索出来的，不是收集来的。多问几个「为什么」，你会发现用户真正要的东西往往藏在第三层。
2. 模型比文字靠谱——哪怕你还没用MBSE工具，画个用例图、活动图，也比写1000字的需求描述强。因为图是「可执行的思考」。
3. 接受需求会变——别试图一次搞定。建立变更管理流程，让变更变得「可预测、可控制」。我见过太多团队因为害怕变更而拒绝沟通，最后反而出了大问题。

嗯，这一章就到这里。下一章我们会深入聊聊「需求获取技术」——怎么从干系人嘴里挖出真正的需求。到时候我会分享一些我踩过的坑，保证让你少走弯路。