產品經理應該熟悉的軟件需求工程

一、需求工程

需求分析的重要性毋庸置疑。在20世紀80年代，逐步形成了軟件工程的子學科——軟件需求工程。90年代後，需求工程成為軟件界研究的重點之一。從1993年起，每兩年舉辦一次需求工程國際研討會（ISRE）；1994年起，每兩年舉辦一次需求工程國際會議（ICRE）。一些關於需求工程的工作小組相繼成立，使需求工程的研究得到了迅速進展。

1.1 需求的定義

IEEE軟件工程標準詞彙對需求的定義：

• 用户解決問題或達到目標所需的條件或能力；
• 系統或部件要滿足合同、標準、規範或其他正式規定文檔所需具有的條件或能力；
• 反映上述的條件或能力的文檔説明（SRS，軟件需求規格説明書）。

業界對需求的通俗解釋 ：

• 需求來源於用户的一些“需要”；
• 這些“需要”被分析、確認後形成完整的文檔；
• 該文檔詳細地説明了產品“必須或應當”做什麼。

需要説明的是：並沒有一個清晰的、無二義的“需求”術語定義存在。真實的“需求”實際上在人們的腦海中，甚至在腦海深處自己都不知道。

我們需要確保的是所有項目風險承擔者（stakeholders，干係人）在描述需求的文字的理解上務必達成共識。

1.2 需求的三個層次

• 業務需求是高層用户（即客户）提出的，比較籠統、寬泛，在項目視圖與範圍文檔中説明。
• 用户需求是最終用户（實際使用者）提出的，已經比較具體了，在實例文檔或方案腳本中説明。
• 產品需求是開發團隊需要的（甲方監理也需要），定義了開發人員要實現的軟件功能，使得用户能完成他們的業務，從而滿足業務需求。

業務需求和用户需求都是用通俗語言描述的，即用户能看懂的語言；產品需求是用技術語言描述的，是開發人員能看懂的語言。用户和開發人員是在用不同的視角觀察需求的，他們看到的內容是不一樣的。就軟件而言，這裏的產品需求就是軟件需求。

這樣的解釋可能還不容易理解，我來舉個“咖啡店新老闆要更換定製咖啡杯”的例子。

業務需求：

咖啡店老闆要訂做一種咖啡杯。

找高層用户調查和確認需求是一件痛苦的事，因為他們不關注需求具體內容，甚至常常不知道具體需求，他們關注的是“高屋建瓴”的比較務虛的內容，例如：咖啡杯要好用、要漂亮之類的。

真正去調研需求，需要先識別出產品的最終用户羣，選出用户代表，對用户代表進行調研。這裏的用户代表為：消費者，喝咖啡；服務員，端咖啡；洗碗工，洗杯子。針對消費者調研可以採用問卷調查的方式來獲取用户需求；針對服務員和洗碗工可以採用用户訪談的方式來獲取用户需求。

用户需求：

• 消費者希望“杯子不能燙手”。消費者反饋：原來的杯子手柄很短，杯身隔熱效果很差，拿杯子的時候，手指容易被燙。
• 服務員希望“杯子在托盤上要穩，不容易滑倒”。服務員反饋：原來的杯子瘦且高，杯底很滑，用托盤端盛滿咖啡的杯子時，杯子在托盤上容易打滑或傾倒。
• 洗碗工希望“杯子要容易清洗”。洗碗工反饋：原來的杯子內壁不夠光滑，咖啡漬很難清洗。

這樣的用户需求似乎很清楚了，但是你得明白這只是針對用户側，對開發人員來説還是不清楚，因為這是自然語言描述的內容，不是技術語言描述的內容，開發人員無法針對此開展工作。

你還需要把以上內容翻譯成為技術語言描述的產品需求：

1. 採用隔熱材料，導熱率λ < 1.22 W/(m.K)，厚度> 5mm。經過原型測試，採用了這樣的材料和厚度做成的杯子，加入100℃的熱咖啡時，杯子外壁的温度大約50℃，輕微觸碰時不會感覺燙手。
2. 杯底的靜摩擦係數 µ > 0.5，滿杯的重心高度 h < 10cm。經過原型測試，符合這種要求的杯子在裝滿咖啡時，不容易打滑或傾倒。
3. 杯內壁表面粗糙度 Ra < 1.0。經過原型測試，符合這樣要求的陶瓷表面不容易附着咖啡液體，很容易清洗。

拿到這樣的產品需求，開發人員就可以開展工作了：

• 根據產品需求1，開發人員可以從工廠常用的陶瓷材料裏選擇符合要求的，然後把杯子設計為略高於指定厚度。
• 根據產品需求2，開發人員可以把咖啡杯的底座設計為條紋或其他形式來加大摩擦係數，然後把咖啡杯設計為較矮、較寬的外形，以滿足在滿杯時的重心要求。
• 根據產品需求3，開發人員可以對咖啡杯的內壁採用某種拋光或鍍釉的工藝來達到表面比較光滑的要求。

這就是需求的三個層次：高層用户關注業務目標的實現，最終用户關注業務執行的效率和使用體驗，開發人員關注產品需求是否準確和清晰。

產品經理就比較慘了，需要從多種角度去描述需求：高層用户視角的需求，即市場需求文檔MRD；最終用户視角的需求，即業務需求文檔BRD；開發人員視角的需求，即產品需求文檔PRD（或軟件需求文檔SRS）。

“需求”，這是所有人都可以説上幾句的話題。但最專業的，還是產品經理描述的需求，這正是產品經理的價值所在。

1.3 需求工程RE

應用已證實有效的技術、方法進行需求分析，確定客户需求，幫助分析人員理解問題並定義目標系統的所有外部特徵的一門學科，即需求工程。需求工程通過合適的工具和記號系統地描述待開發系統及其行為特徵和相關約束，形成需求文檔，並對用户不斷變化的需求演進給予支持。

通俗地説，需求工程就是把工程方法引入到需求領域，用工程方法開發清晰的、一致的，沒有衝突、重疊和遺漏的需求，用工程方法來管理需求和控制變更。

1.4 軟件需求工程SRE

軟件工程的子學科，一門分析並記錄軟件需求的學科，它把系統需求分解成一些主要的子系統和任務，把這些子系統或任務分配給軟件，並通過一系列重複的分析、設計、比較研究、原型開發過程把這些系統需求轉換成軟件的需求描述和一些性能參數。

需求工程是系統工程和軟件工程的分支，分為系統需求工程（針對由軟硬件共同組成的整個系統）和軟件需求工程（專門針對純軟件部分）。我們都知道軟件需求是指用户對目標軟件系統在功能、行為、性能、設計約束等方面的期望。軟件開發的最終目的是生產出滿足客户需求的軟件產品，滿足客户需求是軟件開發的本質。

1.5 為什麼有軟件需求工程

軟件需求是軟件開發中的關鍵問題，沒有需求就沒有軟件。

備註：Frederick P. Brooks，60年代初只有29歲時就主持了被稱為人類從原子能時代進入信息時代標誌的IBM/360系列計算機的開發工作，取得輝煌成功，名噪一時。他作為硬件和軟件的雙重專家和出色的教育家始終活躍在計算機舞台上，在計算機技術的諸多領域中都做出了巨大的貢獻，直到69歲才獲得遲來的榮譽——1999年的圖靈獎。

需求是軟件項目成功的核心，良好的需求可以減少開發後期的返工和整個維護階段的工作，做好需求等於項目成功了一半。

1.6 需求溝通是如此困難

需求是以交流為核心的工作，如果在開發過程的各個環節缺乏交流或交流不恰當，就會導致下圖（如果學計算機，你必定見過此圖）的效果。

1. 客户如此描述需求：我有三個小孩，我需要一個能三個人用的鞦韆。它由一繩子吊在我家花園裏的樹上。
2. 項目經理如此理解：鞦韆這東西太簡單了，不就是一塊板子，兩邊用繩子吊起來，掛在樹的兩個枝椏上嘛。
3. 分析員如此設計：真是無知的項目經理，兩個樹枝掛上鞦韆哪還能蕩得起來？除非是把樹從中截斷再用支架支起來，這樣就滿足要求了。
4. 程序員如此編碼：哦，兩條繩，一塊板，一棵大樹，接在樹的中段。太簡單了，“啪啪啪（敲擊鍵盤的聲音）”，搞定！
5. 商業顧問如此詮釋：您的需求我們已經完成了，我們通過人體工學和工程力學等多方面研究，實現了本產品。本着為顧客服務出發，我們的鞦韆產品在使用時，將給您帶來如同遊樂園裏的過山車一樣刺激的感受，如同你在地面上坐沙發一樣的舒適與安全。
6. 資料員如此寫文檔：這麼小的工程沒有文檔很正常，只要有需求説明書與合同就可以了。
7. 實施人員如此交付：我們的產品用户自己都可以完成安裝，只要把繩子系在樹上就可以了。
8. 客户得到如此結果：花了建過山車的投資，得到個如此產品，也是醉了。
9. 維户人員如此支持：我們提供不了什麼技術支持，但我們態度很好，我們的隊伍在成長中。
10. 項目完成了，真實的需求也清楚了：客户需要一個跳圈，給三個小孩養的小狗訓練和玩耍。

很明顯，項目開始時客户也不知道真實的需求，他表述的只是他理解的需求（小孩曾經給他説過，但顯然他並沒有認真聆聽）。項目經理沒有認真調研需求，他甚至根本不知道最終用户是誰。項目經理和分析員之間，分析員和程序員之間，明顯沒有良好的交流和反饋。像漏斗一樣，每個環節都在遺失信息；像傳聲筒遊戲一樣，每個環節都在加入自己想當然的理解。所以，最終的結果必然的天差地別！最重要的是，他們缺一個打通各個環節的產品經理。

對於產品經理，有個常識你必須知道：

用户嘴裏説的，不一定是他腦子裏想的。他腦子裏想的，也不一定就是業務實際運行的情況。業務的現狀，不一定是合理的，也許正是客户需要你幫助改進的。

所以，我們要傾聽用户，但不能完全按照用户説的去做。我們要傾聽多方用户代表，特別是要關注那些互相沖突、需要妥協的部分。我們不光要聽用户怎麼説的，還要看他怎麼做的。我們要聽免費用户的免費意見，更要聽付費用户的付費意見。我們要聽用户的意見，更要聽決定付錢的客户的意見……等等，自己總結吧，自己總結的才是最適合自己的，我不想展開了。

1.7 軟件需求工程框架

CMMI對軟件需求的描述集中在兩個PA裏：需求開發RD（3級），需求管理REQM（2級）。

• 需求獲取：從用户獲取、挖掘需求。
• 需求分析：提煉用户需求，分析轉化，需求分析的過程重視用户參與。
• 需求定義：把分析得到的需求文檔化，編制需求規格説明書。
• 需求驗證：確定需求準確、完整，得到實現，對應測試活動。
• 需求變更控制：對需求的變更進行控制，降低影響。
• 需求跟蹤：監控需求在開發過程中不走樣、不遺漏。

二、需求開發2.1 CMMI關於需求開發的描述2.2 需求獲取方法

相比“需求獲取”，我個人更喜歡“需求挖掘”這個詞。因為“需求獲取”讓我感覺需求就是樹上的果子、地裏的莊稼，只要產品經理去採摘就可以了。這樣的描述，未免低估和輕視了得到需求的困難。反之，“需求挖掘”讓我感覺需求是地裏的金子等礦藏，需要產品經理去彎腰、埋頭挖掘，而且挖掘了也不一定有成果，因為你需要尋找正確的地方挖，否則只能是徒勞。另外，在很多人都挖過的地裏，你只有挖得更深才可能挖到礦藏。

常見的需求挖掘方法有：客户交流、競品分析、市場調研、問卷調查、技術引導及其他。

客户交流是最常用的需求挖掘方法。大多數情況下，用户雖然知道自己的需求，但他們並不一定能或者也不想準確表達他們的需求是什麼。如果用户第一次告訴你需求就是這些了，不要輕信，繼續刨根問底，直到你們都筋疲力盡。

產品經理作為一個需求分析者，所謂的聆聽客户需求，指必須透過客户所提出的表面需求理解他們的真實需求，避免理解不同會帶來的期望差異。儘量把客户所持的假設解釋清楚，特別是那些發生衝突的部分，甚至要逐字逐句去理解，以明確客户沒有表達清楚但又想加入的特性或特徵。

有經驗的產品經理能深入地理解客户的業務（可以提取做大量準備工作），這樣他才能通過詢問客户一些合適的問題（需要提前設計），從而挖掘出高價值的用户需求。

2.3 需求分析方法

需求分析方法大致分為兩類：模型法和原型法，都可以從不同角度説明需求，把一些模糊的需求變得清晰，便於理解，減少返工。不管是模型，還是原型，都是用來增強自然語言描述的需求規格説明，而不是代替。

模型一般分為面向過程的模型和麪向對象的模型兩類。建立需求模型的分析過程，稱為“需求建模”。建模的目的是把模糊的東西搞清晰，把複雜的東西搞簡化，而不是把簡單的東西搞複雜（這是商務人員做的事，比如：電信運營商的話費套餐）。

原型法是一種減少軟件項目失敗風險的技術，它可以加快開發進度，增加用户滿意度，減少需求錯誤和用户界面缺陷。

2.4 需求建模

常用的面向過程的需求建模方法（結構化分析）：

• 功能模型：數據流圖DFD
• 行為模型：流程圖Flow Chart
• 狀態模型：狀態遷移圖STD
• 數據模型：實體關係圖ERD

常見的面向對象的需求建模方法：

• 功能模型：用例圖
• 行為模型：活動圖
• 狀態模型：狀態圖
• 交互模型：時序圖（也叫“順序圖”）

2.5 原型設計

建立原型的目的是為了解決在產品開發早期需求不確定的問題，利用這些不確定來判斷系統中那一部分需要建立原型和希望從用户對原型的評價中獲得什麼信息。其優點是能減少軟件項目失敗風險，加快開發進度，增加用户滿意度，減少需求錯誤，尤其是界面錯誤。其風險是當用户或項目經理看到一個正在運行的原型，會以為產品即將完成。

對於發現和解決需求中的二義性，原型是一種很好的方法。關於原型，不在這裏贅述了，後面會另起一文。

常用的原型設計方法：草圖（手繪圖）、線框圖、交互原型、高保真原型。

原型法不僅是需求分析方法，同時是需求驗證方法。

2.6 需求定義的方法

• 採用需求文檔模板。
• 指明需求的來源。
• 為每項需求建立編號。
• 設定需求優先級。
• 記錄業務規範。
• 創建需求跟蹤矩陣。
• 其他方法。

2.7 好需求的標準

• 清晰：不同的讀者只能從需求文檔中得到唯一的解釋説明，沒有二義。所以表述中不要出現“也許、大概、可能、左右”之類的表述模糊的詞語，比如：響應時間5秒左右，寬度大概10米。
• 完整：一個不能少，所有功能都要描述。
• 一致：上下文一致，局部與整體一致。
• 可行：每一項需求必須在已知系統和環境的限制範圍內可以實現，不能是空中樓閣。
• 可驗證：每一項需求必須能夠用測試用例或其他方法來驗證是否按定義實現了。
• 可跟蹤：每一項需求必須能與HLD、LLD、Code、UT、IT、ST等各階段工作產品對應跟蹤。

三、需求管理3.1 CMMI關於需求管理的描述3.2 需求管理的方法

• 確定需求變更控制過程，建立CCB（需求變更控制委員會）。
• 進行需求變更影響分析，跟蹤變更影響的工作產品。
• 建立需求基準版本和需求控制版本文檔。
• 維護需求變更的歷史記錄，跟蹤每項需求的狀態。
• 使用需求管理工具，衡量需求穩定性。
• 其他方法。

3.3 需求變更控制

大師説：“沒有不變的需求，世上的軟件都改動過3次以上，唯一隻改動過兩次的軟件的擁有者已經死了，死在去修改需求的路上。”

需求變更是正常的，但不加控制的需求變更是不正常的。所以，不怕需求變更，但要嚴格控制，要讓客户知道變更的代價（影響和成本），客户在理解變更的代價後再拍板會理智很多。

需求變更的原因：客户説不清楚需求；需求自身經常變動；分析人員或客户理解有誤。

需求變更控制不是為變更設置障礙，而是建立一個渠道和過濾器，保護客户和開發者雙方的權益，減低變更的影響。

參考資料：

CMMI-DEV 1.3

作者：叔寶，微信公眾號“叔寶説”，專注產品設計和PPT設計。

本文由 @叔寶 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Pexels，基於CC0協議。