本文講述軟件過程中的ICONIX方法，面向企業客戶（To B）的需求工程，以及如何把握老板需求。

文章一開始先介紹了ICONIX的相關背景知識，之后緊接著介紹了“ICONIX過程有什么特點”和“ICONIX過程中如何完成需求開發工作”。然后在詳細介紹需求工作方法之前，簡單地闡述了為什么“需求是軟件成功的基礎”。既然是面向企業客戶的需求工程，那么分析的下一個問題就是“客戶為什么要花錢購買軟件”。當我們真正步入一家企業做需求時，又需要解決“如何把握以下三類人（老板、中層經理、一線員工）的需求”的棘手問題。最終，我們通過一個案例描述需求分析工作的第一步：定義愿景，也就是如何把握老板需求。

背景知識

ICONIX方法的介紹及相關說明：

ICONIX是一種軟件開發方法。提倡盡早進入編碼階段，縮短分析設計周期。ICONIX提供充足的需求和設計文檔，但不過度分析設計。 從把需求文檔變成可運作的代碼過程只需四步，使用四張UML圖（下面會有介紹）。

從圖中可以看出擴展ICONIX過程可分為：愿景、業務建模、需求分析、健壯性分析、關鍵設計、最終設計和實現這幾步。它又分為兩個大的部分，分別是需求階段和系統的設計和實現階段，又可分為四個階段：需求分析階段、初步設計階段、詳細設計階段和部署階段。它基于極限編程和敏捷軟件開發的思想，提倡在項目開始階段構建域模型和用例模型，其中用例模型驅動整個動態模型，而域模型驅動整個靜態模型。ICONIX過程是一種以最小步驟實現用例到代碼的方法學，覆蓋了軟件過程中所有關鍵的環節。

問題列表

• ICONIX過程有什么特點？
• ICONIX過程中如何完成需求開發工作？
• 為什么說“需求是軟件成功的基礎”？
• 客戶為什么要花錢購買軟件？
• 思考如何把握以下三類人的需求？
• 如何做好需求分析第一步：定義愿景？

ICONIX過程有什么特點？

在百度百科上對ICONIX的定義中，有這樣一段話：“ICONIX提供充足的需求和設計文檔，但不過度分析設計。 ICONIX過程從把需求文檔變成可運作的代碼過程只需四步，使用四張UML圖?！笨偨Y下來就是上面這張圖。其中利用基于UML圖表的具體方法本文不予介紹，此內容很重要，以后作者會出專題介紹。

ICONIX過程中如何完成需求開發工作？

想象一下這樣的場景：你去企業客戶那里進行需求調研，跟老板談、跟中層經理談、跟一線員工談，談完之后根據記錄的內容進行分析，這過程中用到了一系列的方法和工具，最后生成了一個需求規格說明書，上面記錄了軟件所要具備的功能，這一階段的任務就算完成了。具體思考點請看上圖。

But，do you know why？

很多人都知道如何做需求分析以及做出來的需求長相如何，但我們經常遺忘為何做需求。

為什么說“需求是軟件成功的基礎”？

從兩個維度考慮：一是不做需求產品容易失敗，二是因為需求不好做，所以我們做需求。

那么，接下來請考慮——

客戶為什么要花錢購買軟件？

在真正考慮這個問題的時候，一定不單是站在老板角度考慮（開源節流），還要考慮中層經理和一線員工，這兩者同樣是企業客戶中很重要的組成部分。請看下面。

思考如何把握以下三類人的需求？

假如讓你到一家企業去談需求，你會找誰談？小白說找老板，因為“老板不出錢，其余都扯淡”；小紅說找經理，業務流程只有經理最清楚；小黃說找員工，員工干不出績效遭吐槽，再費心設計的軟件都玩完。此外，還有若干版本的小白、小紅和小黃?，F在，我們把目光投放到問題根本上來，需求要解決什么問題？假設我們知道系統要改善哪個組織的業務流程，以及該組織中最有權力的是誰，那我們就可以去拜訪這位老大，詢問他對項目的期望如何，并描述出愿景的度量指標。單說起來會讓人感到不解，請看下面。

如何做好需求分析第一步：定義愿景？

案例：某市人才交流中心計劃舉辦線上招聘活動，依托招聘網站開展人才交流活動，讓求職者與HR能夠隨時隨地發布和查詢招聘信息，從而減少人才交流中心的現場服務人員數量，縮短求職者與HR的等候時間，消除招聘活動的時間和空間限制，等等。

案例至此，我們首先來找到軟件項目——招聘網站，其次是軟件項目的老大——人才交流中心，并得到人才交流中心對招聘網站的期望——讓求職者與HR能夠發布和查詢招聘信息，最后用可度量的指標描述愿景——減少人員數量、縮短等候時間、消除時空限制。

以上案例僅是拋磚引玉，還希望大家能夠舉一反三，并付諸實踐。

未完待續，敬請期待。歡迎在下方留下您的寶貴意見。

本文由 @巴戈 原創發布于人人都是產品經理。未經許可，禁止轉載。