在軟件工程術語中，“原始需求”并不是個常見的說法 。

這個“原始需求”的提法是本博主自己提出來的。它的起源與CMM有關，CMM中，有“客戶需求”的說法。

當時沒有直接采用“客戶需求”而采用“原始需求”的主要原因是當時開發產品不直接面對客戶，直接面對的是工程實施部門，需求來自于工程實施部門和公司相關領導。為了便于溝通采用了“原始需求”的說法。

現在CMM已經升級到了CMMI。我們先來看看CMMI中如何說明“客戶需求”的。

在需求開發過程域中，有“SG1開發客戶需求”的特定目標。

SG1?開發客戶需求

收集相關干系人的需要、期望、限制條件及接口得到收集，并轉換成客戶需求。

關鍵人員(例如：客戶、最終使用者、供貨商、構建人員、測試人員、制造人員，與后勤支持人員)的需要，是決定客戶需求的基礎。進行關鍵人員的需要、期望、限制、接口、操作概念，以及產品觀念的分析、協調、細化及詳細說明，以轉換成客戶需求。

關鍵人員的需要、期望、限制及接口，經常被粗略的識別或相互矛盾。因為必須清楚識別和了解關鍵人員的需要、期望、限制及界限，在整個項目的生命周期里可使用反復的過程，以達到這目標。為協助此必要的循環過程，最終用戶或客戶的代表，通常會加入此過程，以說明其需要并協助解決矛盾。組織的客戶關系或營銷部門，以及來自人際工程或支持部門的開發團隊成員，可視為此類的代表。在收集和解決客戶需求時，也應考量客戶的外在環境、法規及其他限制。

SP 1.1?導出需要

導出相關干系人提出有關產品生命周期各階段的需要、期望、限制條件及接口.?

導出不僅收集需求，且要積極識別尚未經客戶明確提出的補充需求。補充需求應描述各種生命周期的活動，以及它們對產品的影響。

SP 1.2?將干系人提出的需要、期望、限制條件和接口轉換為客戶需求?

把相關干系人的需求、期望、限制條件和接口轉換成客戶需求。

來自相關關鍵人員的各種輸入，須經合并、取得遺漏的信息，以及解決沖突等過程，并記錄為客戶需求。客戶需求可包括與驗證和確認有關的需要、期望及限制。

某些情況來說，客戶提供項目的一套需求，或者之前項目活動的需求產出。以這些情況來說，客戶需求與相關關鍵人員的需要、期望、限制及接口可能有所沖突，所以在沖突適當解決之后，需要轉換成被認可的客戶需求。

代表產品生命周期的所有階段的相關關鍵人員，應包括經營及技術功能。因此，所有與產品生命周期相關的過程概念，都應與產品的概念同步考量。客戶需求來自信息充分的決策，同時考量需求在經營面與技術面的影響。

--------?

雖然歷經CMM到CMMI變化，所提的“原始需求”仍然對應于CMMI中的“客戶需求”。

在實踐中，對于原始需求，也有如下的整理總結。

定義：原始需求是由用戶或者用戶代表提出的功能或性能需求或其他非功能需求，需求可以未經總結或提取。

目的：原始需求調查和管理的主要任務在于收集需求素材，并保證經認可的原始需求獲得了實現。

流程規定：

1.??根據產品規劃，產品經理劃定需求提供者的范圍，這個范圍一般為顧客，最終用戶，開發人員，生產人員，測試人員，供貨商，營銷人員，維護人員，和其它相關人員，要把潛在客戶劃分出來，這類客戶是指當前還沒有采購本部門任何產品的客戶。

2.??通過各種方式，產品經理收集原始需求，錄入，要把需求提供者信息與其提供的原始需求一起記錄。

3.??產品經理或項目組將原始需求錄入，初始狀態是"已建議"，原始需求編號是自動生成的流水號；

4.??要求將所有原始需求錄入。如果原始需求為其他項目組定制，則須注明其他項目組名稱和相關的交付包。

5.??產品經理根據項目組討論和自身判斷，針對錄入的原始需求，處理是否采納此原始需求，如果采納，原始需求的狀態是"活動的"，如果拒絕，狀態是"已關閉"。如果一個原始需求是由潛在客戶提出的，則一般要求是由兩個或兩個以上的潛在客戶提出，或得到其它需求提供者的佐證，才能被采納。如果某原始需求只由一個潛在客戶提出，且得不到佐證，不建議采納。

6.??當項目組認為原始需求得到滿足之后，將原始需求狀態置為?"已解決"，此時至少要有一個功能點或者需求用例和這個原始需求對應，否則不允許改變狀態。

7.??原始需求"已解決"之后，產品經理或產品經理的授權代理人參考測試報告，并通過功能展示逐條評審原始需求的完成情況，如果符合，進行"已關閉"操作，原始需求的狀態變為"已關閉"，否則把狀態改回"活動的"，要求項目組重新實現原始需求。

?

原始需求采納標準

必須條件

1，?語法通順，表述清楚，沒有歧義；

2，?需求的范圍已經明確說明或可以推斷是有限的，可控的；

3，?此需求必定存在至少一種用戶場合是適用的；

4，?此需求描述的是產品本身，而不是開發產品的某個過程；

5，?此需求不包含設計實現的內容；

6，?此需求不存在重復的需求，即沒有冗余；

7，?此需求不是發現的缺陷；

8，?推測此需求的技術實現在項目當前限制范圍之內是可行的。

推薦條件

1，?需求來自2個或2個以上來源；

2，?需求是場景化描述的；

3，?需求是付款用戶提出的；

4，?需求是競爭對手產品的賣點；

5，?提出需求的用戶有行業前景，比如海關，公安，稅務等等；

6，?已經有明確的性能需求。

滿足推薦條件越多，優先級越高。

?

示例

不附合標準的原始需求

原始需求表述	不符合的原因
能夠提供各項操作的Web Service?	范圍沒有限制，沒有說明什么操作
XXX地方電子警察攔截	語法不完整，不知其義
設備信息查詢中病毒庫查詢不正確，實際有四種	這是一個缺陷，不是需求
應當請客戶確認原型后，再開發XXX模塊	這是開發過程
客戶登錄時，先調用A模塊，然后調用B模塊，再經C檢驗后確認用戶登錄	包含設計，不是用戶的語言
第3個小版本的原始需求	沒有內容，只為流程

表4-2?附合標準的原始需求

原始需求表述

用戶可以在子網路由器層中刪除路由器（或網關）

在發生報警的時候能夠發出電子郵件

點擊所有顯示計算機的記錄都應能顯示完整的終端信息

若有軟件違規發生，向服務端發送軟件違規信息

?

以上雖然全面的說明了原始需求。但可惜的是反而把原始需求最核心的要求淹沒了。

所以在本文的最后，特別要來說明什么是原始需求最核心的要求。

原始需求最核心的要求不在于已經采納的原始需求，恰恰在于被拒絕的原始需求。只有知道了哪些原始需求被拒絕了或者延遲了，才能相信所采納的原始需求是真正要做的。

只記錄經過選擇采納了的原始需求的做法只能保證這些原始需求得到實現，不能保證恰當的、合適的原始需求得到了采納。

而原始需求最關鍵的地方在于如何尋找最恰當的原始需求，其次才是實現原始需求。

?

因此，原始需求應當全面的記錄來自于各方對產品的要求，無論這個要求是否可行，是否合理，是否要做，是否優先。

在記錄時，為了不影響后續人員的判斷，要盡量傳遞用戶的真實意思，采用用戶的語言，保持“原始”。

以產品經理、項目經理為首的產品開發相關人員應當第1時間記錄原始需求，積累好原始需求，當要選擇做的時候，再來做謹慎的選擇。

只有全面的收集記錄的原始需求，才能有產品全面的判斷和選擇，進而開發出受到客戶歡迎的產品。

?

Scrum中有product backlog，其中的條目一般是用戶故事，由于用戶故事顆粒度受迭代的限制，需要對用戶故事進行分析。

考慮上訴提到的原始需求，存在兩種做法：目前比較常見的是 直接利用 product backlog管理原始需求，將原始需求記錄為用戶故事，碰到過大的原始需求就分解為多個用戶故事。另外一種做法就是前文所述，將原始需求與Product backlog分開管理，適合的場景是存在多處用戶的軟件，有許多客戶和潛在客戶，以及不少干系人。分開管理的好處主要在于能夠更好的跟蹤用戶，更系統的理解用戶的需要，能夠選擇更恰當的需求。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的原始需求的来龙去脉和核心要求的全部內容，希望文章能夠幫你解決所遇到的問題。

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