这次来聊需求工程，但是由于内容太多，打算分两次讲。这次先说“用户与用户需求”。
- 需求工程与系统工程
需求工程可以说是系统工程的起始点，是项目确立后要做的第一件事。其承上启下，向上对接系统对应的业务模式，向下牵引系统设计。正如我在系统工程溯源中所说，系统工程的核心目标就是保证项目盈利，而好的需求工程管理不但能够节约经常性支出，还能够有效控制项目的规模与方向，避免项目“跑偏”或“膨胀”。
其最典型的反面例子就是F-22当年的竞标对手YF-23，抛开美军扶持Lockheed-Martin等因素不谈，YF-23由于误读美军ATF项目的需求，间接导致了诺斯洛普与道格拉斯的命运转折。
（虽然目前网络上能找到的关于ATF项目竞标始末的材料几乎为零，但由于过于强调超音速巡航造成的机动性差等问题被认为是YF-23失败的重要因素之一）。
事实上，需求工程被认为是“对复杂系统设计进行严格控制的有效工具”（MIT，System Engineering Fundamental）。
首先，需求的错误分析、分解与追溯管理，已经成为开发项目中最容易造成超支的因素之一，“有超过70%的设计错误来自于需求的错误”（ISAE，Requirement Engineering）。而70%~85%的rework支出被花在了修正错误的需求上。毕竟，有70%的预算在需求工程结束就已经被确定。
其次，高度竞争的市场已经不允许反复冗长的更改与迭代，这已经是上个世纪的设计模式。从下图中可以看出，随着技术进步，各种科技产品从开发到占有主要市场（一般认为市场占有率超过40%即可认为是“标杆”级的产品）越来越短，这一论断在航空产品上也同样成立。X-32败北F-35的重要原因就是其反复更改的垂直起降系统与失控的项目开发周期（据报道，直至JSF项目竞标结束，X-32都没能完成所有试飞科目）。
2. Stakeholder与stakeholder needs的5W1H
a. 谁参与？
在捕获Stakeholder needs（为了与stakeholder requirements，即需求区分，这里采用英文原文）的阶段，所有对项目的技术、财务、与周期相关的人与组织都应参与进来，以确定stakeholder（以下简称STH）与其needs。这个过程中的参与者包括但不限于：系统工程师，市场人员，用户，技术人员，项目经理，财务人员，维护服务人员等等。
特别是潜在用户的参与，纵览所有USAF的项目包括之前提到的ATF、JSF，LRS-B等等，在竞标阶段，几个主要的供应商都邀请了资深飞行员参与设计，这还不包括波音、Lockheed-Martin等公司长期养着一大批美军退役飞行员作为顾问。
（这里我把系统工程师与技术人员分开说，主要因为在整个系统工程期间，系统工程师的作用与传统我们理解上的技术人员定位并不相同，以后细说。）
b. what?
按照ISO-15288与SE Handbook的说法，这一阶段主要就是定义与维护STH与STH requirements（STH REQs）。
这里要关注的一个问题就是STH及其STH REQ的范围。
与我们传统理解的技术行为不同的是，在定义STH、STH REQs的过程中，需要考虑的不仅仅是技术因素，而是跟系统相关的所有因素（包括进度、财务、法规等等），这一点在我们日常工作中往往被忽略的。正如我在系统工程溯源中说的，系统工程的一切都是围绕着“make money”而产生的，单独谈技术层面自然就是舍本逐末、缘木求鱼了。
我们的系统工程师往往聚焦在纯技术层面（当然，这与我国理工科教育内容相关，此处不展开）。这也是为什么在日常工作中，我们按照合理的逻辑套路展开思维时，往往发现得到明显错误的结论。而凭直觉得到结论，却看起来更合理。其实很简单，从错误的初始点出发，采用正确的“路径（方法）”往往去不到正确的终点，而采用错误的方法，却常常误打误撞。
这也导致了我们日常工作中常常缺少严谨的推理与论证，在做“可行性分析”时常常落入要么感觉发虚，没东西好分析，要么论证一番，得到没法支持结论的论证。这也是我们的设计体系一直无法讲可行性分析（feasibility）做实的原因之一。
c. why?
为什么要分析STH与STH REQs？
我们做这个工作的驱动因素在哪？其实其中的逻辑很简单，如果不捕获STH就无法获得完全的STH REQ。不获得完整的STH REQs，还记得吗，前面说的70%的预算？
更甚，随着整个航空系统的复杂程度提高，甚至未来会出现航空系统的SOS（system of system）。仅凭直觉进行的系统设计，后续只会面临大量的更改与反复。这种项目和公司的结局大概也只有破产一途了。
d. when?
关于STH捕获与分析的时间点，虽然没有明确说明，但是可以想象，在项目启动前的opportunity study阶段就要开始。只有这样，才能够为业务部门的business分析提供可靠的“弹药”，确定项目立项与否。同样的，在支持业务部门的过程中，随着对业务模型的理解，也有助于系统工程师更好的捕获STH与系统设计的各种非技术性约束，以航空系统为例就包括财务、适航、法律、区域文化等等。
这个过程的结束以建立完整的STH REQs为结束的标志。相信大家都看出来了，在STH REQs中不仅仅是技术性需求，还包括法律法规、维护、财务、项目周期、管理、甚至环保等等全部可能影响系统设计的因素。
e. where?
（这一点没什么好说的，ISO-15288也没有特殊的规定）
g. how?
如何捕获STH与STH REQs是一个很大、很复杂的话题，各种手册中也都有详细的说明。
在这一点上，我想说的是PMO，也就是Purpose，Mission and Objectives。因为这牵涉到一个“伪需求”的概念。
举个例子，人对车的需求是什么？这个问题交给19世纪的人回答，大部分人的回答是“更快的马！”这一结论让这个时代的我们看起来就很可笑，因为我们知道马再快也不可能快过飞机、高铁。但是19世纪的思维惯性让大部分人将“马车”这个solution潜在的带进了答案里，因此很自然的找到solution就是选更好的马种，更轻的车身。但是，其实以现代人的眼光看，这其实就是一个“伪”需求。
因为我们的需求不是更快的马，而是更快、廉价的完成点对点的运输。这就是需求工程中说的Purpose。当我们“think big”一点，很快就会发现用机械能完成运输人、货是个更好的选择。当我们站的高一点，就会发现很多需不过是“伪”需求，而伟大的产品往往是从发现伪需求开始的。无论是Iphone还是汽车，皆是如此。
这大概和古人说的“会当凌绝顶，一览众山小”异曲同工吧。
3. 结语
这次我们仅仅浅谈了我对STH与STH REQs的一些想法，实际上，需求工程是一门及复杂的综合性学科，其中有很多思维的工具与方法受限于篇幅无法与大家分享，有兴趣的可以与我讨论，网络上也有很多相关资源。推荐“A FRAMEWORK FOR REQUIREMENT ENGINEERING”给有兴趣的同学，看完之后对需求工程会有一个全方位的认识。
下次我们聊需求工程的下半部分——“Requirements Analysis”
也欢迎关注我的个人公众号“胡言乱语话春秋”，获得我最新的系统工程学习体会。
閱讀更多 timzhang 的文章
