需求分析可以說是每個從事需求分析工作的人，不管其級別是初中高級亦或是產品總監工作中的重中之重。把需求進行分析進而分解成核心組件是一種必須掌握的強分析技術，每個產品經理應該形成這種意識，甚至是遇到需求后條件反射的本能。今天，我們就來說說需求分析的核心組件，希望能幫助大家的工作和應用到實踐中。

一、需求的核心組件的定義，需求的核心組件是什么，為什么需要掌握核心組件！

需求核心組件即：構成需求的核心要素，其在產品經理和需求分析師對需求分析過程并轉化為功能需求至關重要，也是一種強大的分析手段。

需求的核心組件構成：對象（Object）、數據（Data）、過程（Process）、規則（Rule），四大組成部分。

應用需求核心組件我們來舉一個例子：系統發送消息。那么應用需求核心組件如何進行分解。

• 對象（需求涉及實體）：系統；

• 過程（完成的動作或活動）：發送消息；

• 數據（信息）：消息內容；

• 規則（業務規則）：什么時候發，滿足什么條件才能發。

這么簡單的需求分解出來，其實就轉化為了具體問題，沒有解決的問題或者不清晰的元素，我們就需要去弄明白，這樣才不會疏漏任何細節。

需求是復雜的，產品經理在進行需求分析中，如果沒有合適的方法去分析和分解需求，那么會造成關系對象的疏漏、信息的缺失、架構的不完整亦或是系統支撐性不足等問題。理解和掌握需求中的核心組件，能讓產品經理在需求分析時準確把握核心要素，讓業務需求轉化成功能需求時的邏輯分析和思路更加清晰，思維更加縝密。

二、需求分析組件的概念和簡述

1. 對象（Object）

對象是與業務過程有交互、有關系的人、事物，或者其他軟件系統、模塊。

沒有哪個業務過程是不涉及多個對象進行運轉的，當我們進行需求分析時一定要分析出其中涉及的對象，這些對象具象化有可能是你的軟件系統、你的用戶、你的用戶的客戶、上下游的軟件系統。對象分得越清晰，越能站在不同的對象角度去思考和分析需求的使用場景和衍生場景。

2. 過程（Process）

過程是業務完成的動作或者活動。它是構成需求核心組件的第二大組件，也可以描述為流程。

有些人認為流程都是工作流，審批流等復雜性流程，其實簡單的一個動作也叫流程，這里統一稱過程吧。過程或流程是一個對象到另一個對象之間涉及的動作或者活動，其通常是由動詞加名詞進行構成描述，我們常常說的，行為、任務、流程和用例皆可代表過程。

3. 數據（Data）

數據是業務過程中所涉及到的所有信息，我們常說的信息系統和信息技術、信息通信，都無時無刻不在提醒我們軟件系統中信息的重要性。

無論你做成的軟件功能是自動化完成的活動還是需要手工進行錄入完成的活動，盡管活動的形式可以千變萬化千姿百態，技術可以千變萬化，遺漏了數據需求將造成嚴重的需求疏漏，對于信息化時代，這種遺漏無疑是致命的。再好的軟件，再精美的界面，再牛逼的技術架構，如果客戶無法管理、呈現、使用他們需要的業務信息，開發完成也是一場徒勞。所以，數據需求更需要我們詳細分析和挖掘。

4. 規則（Rule）

規則定義了業務過程的約束和規則，它代表系統、模塊、功能在滿足什么樣的約束下做出什么樣的反應，從而使整個業務過程按照邏輯和我們事先定義的準則進行流轉和做出響應。

常常聽到幾個詞：“驗證”、“確認”、“檢查”、“決定”或者“評估”，這幾個動詞常常都需要涉及到規則和約束，來判斷后續過程的走向和處理過程，因此規則可以說代表了系統的決策點，也是整個需求的關系鏈邏輯。

三、四大組件深度理解和掌握

清晰了四大組件的基本概念和含義，我們需要掌握每一個組件要素，它們為我們分析需求提供了專業的角度，有助于你分析復雜業務領域。因為每個需求都是由它們進行構成，你拆解分析得越深入，無疑你對需求的把控更加準確。

1. 掌握和理解需求核心組件——對象（Object）

對象是業務涉及到的實質性對象和抽象性對象，其可以是一個人、系統、組織、模塊、接口，清晰地分清楚需求涉及的對象非常重要，它是決定產品經理需求范圍意識的核心。

對象涉及到內部對象和外部對象，內部對象常常是自己的公司架構、軟件系統本身涉及的對象，外部對象主要有其他系統或者接口，主要來自于公司的外部。

這些干系對象都能成為需求分析中的重要角色，都可以包含重要的功能需求。產品經理需要在項目初期進行充分地識別，并分析哪些是主要對象，哪些是次要對象，分清其中的對象從屬關系。

通常對象越多，產品經理分析的工作難度也越大，項目的范圍和關系也就越復雜，因為這些對象可能都與你的軟件最終成果息息相關。比如當考慮到外部對象時，我們就要考慮我們解決方案的數據的公開性和安全性，盡可能地識別出對象與對象之間的關系，能讓后續的軟件功能更加符合用戶的期望。

需求分析時劃分外部和內部對象，這也是必要的。開發一個軟件，自己的公司和流程很可能可以進行變化，但是外部的對象、政府、客戶、其他公司，它們不會受到軟件開發項目的影響，因此對象的分析能讓我們的軟件符合它們的技術環境和架構。

2. 掌握和理解需求核心組件——過程（Process）

過程，比較專業化的描述，指的是，把一個輸入的數據轉化為輸出數據的活動。從大多數的需求分析來看，過程是最重要的的需求要素，非業內人士常常不明白業內人士描述的過程，這就是專業和行業的差異造成的對過程的理解偏差。

過程比數據更難定義。數據是具體的，過程是需要更多的描述性信息來描述其準確含義的活動。

舉例：“接收數據”，“記錄數據”，接收是被動，記錄是主動，那么在系統中采用哪種活動更符合客戶需要呢？這就要我們產品經理結合實際場景和更多的需求調研來確認。

過程描述對于產品經理的需求分析非常重要，因此常常需要一些圖來詳細分析過程的實現形式。我們可以常常使用流程圖、數據流圖，或者用例來分析系統的需求實現過程，這樣我們才能知道什么樣的呈現形式、技術架構、搭載終端才是最符合用戶場景需求的實現手段。

3. 掌握和理解需求核心組件——數據（Data）

數據在整個需求分析分解過程中占據主要的地位，其不僅作為輸入，也作為輸出參與到整個業務過程的生命周期中，甚至被其他外部對象繼續利用產生外部系統的輸入。但是數據又是最復雜的，可以說整個軟件系統無處不在的就是數據，軟件的成果的核心就在于被準確定義和可使用的數據輸入輸出。

那么產品經理在分析數據需求時，一般會涉及到什么數據的屬性呢？

• 關聯對象的數據；

• 數據的唯一性；

• 數據的可控性；

• 數據的重復性。

1）關聯對象的數據

數據是關聯對象而存在的描述和屬性定義。對象也是我們分析和獲取數據的源頭，對象的數據可以描述其特征和屬性，比如身份證，是一個對象，其包含的數據：18位的數字、姓名、地址、國徽圖案、人物頭像、防偽標志、以及簽發公安局等。

對象的數據可以讓使用者清晰識別和認知對象，相反如果對象的數據定義不足或者不清晰，同樣會對產品的使用者造成困擾和混淆。

只有通過數據，才能進一步地描述對象的存在價值和特點，對象也通過數據形式，表現出它的獨特性和唯一性或者是重要性。當你在發現一個用戶和系統的關聯越緊密時，這個用戶涉及的數據屬性也同樣至關重要。比如這個用戶在系統上的數據：“姓名”、“身份證”、“手機號”、“郵箱”、“地址”等信息，這些數據元素準確的描述了對象（用戶）的重要特征。

當然在產品經理的工作中，有時候用戶并不會清晰地描述自己的數據，在具象化之前，它們通常被描述為：“報告”、“表格”、“表單”等。對于這些不清晰的數據需求，我們一定要詢問和調研，將文檔中的數據元素進行確認，并確保其符合客戶的工作特征及需要，關聯對象的數據獲取不僅可以通過訪談、詢問，也可以結合個人業務的常識進行補充和擴展，但最重要的是不要遺漏重要的數據。

對象的數據最好使用業務術語描述，而不是采用專業的技術術語，更能讓人理解業務需求。我們出一個老師對象的數據模板舉個例子，對不對暫且不說，畢竟對教育行業不熟悉，只做舉例：

這只是簡單舉例，優秀的產品經理和需求分析師能更準確地定義其需要的數據。如果你所需要的數據已經存入系統，那么你此時更應該思考，數據的查詢規則、如何讓用戶快速找到定位自己想要的數據、數據又以何種方式呈現。這也是數據需求，詳細的數據元素和查詢規則記錄，往往能增加對數據需求的思考層次，同時也避免遺漏需求。

2）數據的唯一性

數據的唯一性常常用來作為搜索、查詢特定數據集合的條件。

比如說如果教師工號是唯一性識別的身份標志，那么通過工號定義業務查詢規則就能準確找出對應的教師信息；如果老師的學校不是唯一的，那么通過學校的數據取值，就會出現多個結果。

數據需求很重要的一點在于如何查詢和訪問存儲的數據，如果教師工號是具有唯一性的訪問識別特征，當該教師的賬號被別人登錄進行訪問時，那么就會產生數據真實性問題。所以手機驗證、令牌、其他設備的輔助身份認證這時候就凸顯出數據安全保障的作用。數據需求也可以加深我們對客戶需求的理解和挖掘。

3）數據的可控性

數據的可控性指的是數據是否是強制還是非強制，即必填和選填，除此之外，還有數據權限，即對應的業務場景下，數據的編輯、刪除。

可見權限的定義規則也是屬于數據需求，數據的可控性應結合具體場景進行分析。不同業務領域和流程，在于對數據的可控性上定義是不同的。如我們經常碰到購物軟件，注冊時，我們的收貨地址是選填項，因為這時候，收貨地址數據為空，你也能正常進行其他動作并不對系統造成任何的影響。

但是業務過程到了提交訂單，點擊付款時，這時候系統需要用戶進行地址數據的錄入，并且不允許為空，這是因為系統的流程的下一步必須知道用戶的地址數據，才能進行訂單的發貨。該數據的需要性在業務流程中屬于重要節點，這時候原先的數據的可控性便發生了變化。所以數據的可控性應結合到業務過程進行分析。

4）數據的重復性

數據的重復性，常見的比如我們的用戶的某個數據是否允許多個取值，如多個電話號碼、多個電子郵箱、多個收貨地址。

隨著信息化時代，每個用戶在相同數據定義下都可能具有多個取值需求，產品經理在分析數據的重復性時，切莫去想當然，而是應該站在用戶的實際的場景架構和基礎上進行思考是否有必要保留數據的重復性，這些場景架構包括用戶的畫像、用戶所處的物理環境。

數據的重復性問題，可以用假設的方法來分析。

比如收貨地址，如果用戶地址只有一個，用戶會頻分需要修改嗎？如果用戶收貨地址不是自己的怎么辦？這樣結合具體的假設和場景分析，看下能不能閉環，閉環時有什么痛點，你就知道是否需要多個電話、多個地址、多個郵箱，來驗證自己對數據重復性的思考。

4. 掌握和理解需求核心組件——規則（Rule）

規則，即業務活動能夠完成、業務過程能夠運轉滿足的條件要素。

規則有時候是簡略就能表示，有時候需要涉及復雜算法的計算并最終校驗，才能夠決策活動是否完成或者流程是否流轉。

準確來說，規則是一個需求中的關系組件，它常常會也關聯到其他需求和對象，需求與需求之間也通過規則進行聯結在一起，共同進行協作。

舉個例子：“某某地區凡是有超過15m的水位線的湖泊都記錄到風險點管理”。

我們提煉一下，對象（某地區的湖泊）、數據（水位線）、其他對象（風險點）、規則（水位線超過15m），這樣通過規則的定義，就把一個整個需求和不同對象進行關聯起來。

有些產品經理可能會把規則誤認為是需求，其實這樣不能完全說是錯的，只是大家在結合分析的時候要分清主次關系，重要的是在需求分析中提煉系統需要的規則，使需求和對象進行邏輯性的聯結、溝通、通信。

描述規則時，我們在同一個項目中，相同的規則一定要采用相同的術語，避免測試和研發人員的誤解和概念的混淆。這一點在開發過程中會造成很大的歧義，甚至影響后臺整個的規則架構，引發不必要的開發工程量。所以在定義和描述規則時，動詞的使用和名詞的使用，最好保持一致性的原則。

如何從需求中找出我們的規則呢？

1）通過業務需求的干系人獲取規則和定義規則。

需求討論會中，不同的需求的干系人，也有可能對同一規則的描述產生用詞差異。產品經理一定要詢問并確認其是否指的是同一過程的同一規則、規則使用的場景是什么，這樣才能對規則的把控和后續的功能描述更加到位。

2）通過數據需求的分析來暴露規則。

通常我們需要的規則往往是從對象之間數據需求的分析中暴露出來的，規則還可稱為“數據傳遞相關規則”。

軟件開發中也轉化為表達式和校驗判斷的規則來約束數據在對象之間的傳遞，記錄在數據的模型中，大多數的規則至少依賴于兩個對象之間的數據。當然自己和自己進行內部的處理也是可以的，但我們作為分析，應該以對象之間的數據傳遞為中心去挖掘規則。

3）當業務規則不清晰或者多變時，我們需要一套業務規則的管理系統進行管理規則。這時候，只要根據我們的數據需求進行規則地表達。

現在的軟件系統越做越大，其中的關系也是紛繁復雜。通過業務規則的提煉和相同相似規則的合并，可以組成強有力的規則引擎。在公司對對應領域高度把握，和基于業務需求和規則的理解的基礎上，這樣建立出的規則引擎將具有強大的生命周期和中臺能力，畢竟業務中臺和能復用的底層結構的生命線遠遠比項目的軟件系統本身來得長，所以深度挖掘規則也是對整個業態和系統靈活性和擴展性的深度把握。

四、總結

每個產品經理的層次有高低，但每個產品經理都要掌握自己的分析技術，四大需求組件分析方法，能更好地讓我們掌握結構化分析方法，幫助產品經理從不同的對象、不同視角去剖析業務需求和問題。

需求分析作為產品和需求分析師的核心工作內容，需要以科學的方法、正確的思考方式、完整的邏輯來進行，切勿眉毛胡子一把抓，而應把持著懂分解需求、擅分解需求的意識進行需求分析工作。

本文主要幫助小伙伴們思考結構化自己的需求，并進行分析，希望對大家有所幫助。

總結

以上是生活随笔為你收集整理的需求分析：每个产品经理都应掌握的需求核心组件分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。