這次來聊需求工程，但是由於內容太多，打算分兩次講。這次先說“用戶與用戶需求”。
- 需求工程與系統工程
需求工程可以說是系統工程的起始點，是項目確立後要做的第一件事。其承上啟下，向上對接系統對應的業務模式，向下牽引系統設計。正如我在系統工程溯源中所說，系統工程的核心目標就是保證項目盈利，而好的需求工程管理不但能夠節約經常性支出，還能夠有效控制項目的規模與方向，避免項目“跑偏”或“膨脹”。
其最典型的反面例子就是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 的文章
