緣起

筆者在這幾年工作中，接觸了各類需求，不同人員在不同的時間點按照不同表述方式來提供。在溝通交流中，有些時候會因為說法的不同和不同的說法，浪費不少時間，往往會有這樣的感覺：唉，原來你說的是這個啊？ 或者是這樣：哦，我大概明白你的意思了，你的這個結構邏輯是這樣的啊。

所以在4月10日在微博上發起了如下的調查

@張克強-敏捷307 調查-你如何稱呼最初步的軟件需求？?業務需求？客戶需求？用戶需求？原始需求？?@徐鋒-需求@PMO之道---蔡德輝?@haitao深圳?各位朋友隨便說說 再補充了條 張克強-敏捷307：有沒有使用 概要需求 說法的情況？
澄清調查問題 朋友們首先要澄清問題，對于說法的問題，由于剛開始沒有共識，啟動討論第一步是要定位問題 PMO之道---蔡德輝：初步到什么程度？//@張克強-敏捷307:有沒有使用 概要需求 說法的情況？ |?轉發(11)4月10日 09:06? lvxinke：如何定義初步？
我的回答： 張克強-敏捷307：程序員還不能拿來開發 lvxinke：這是結果，還是不夠清晰，初步需求的價值或者目的是什么？ 張克強-敏捷307：初步而言，最緊要的是收集。//@lvxinke: 這是結果，還是不夠清晰，初步需求的價值或者目的是什么？ 來自@鄭仁華_PZ簡明扼要的補充 鄭仁華_PZ：用戶或者客戶意見，提煉后才說需求。//@張克強-敏捷307:程序員還不能拿來開發/

朋友們的精彩點評

PMO之道---蔡德輝：從設想、業務規劃、系統需求、軟件需求看看是哪個

? ? ? ? ? ?lvxinke：前兩者？@王海鵬Seal(《掌握需求過程》的譯者)

? ? ? ? ? ?王海鵬Seal：最初的時候，有人有一個vision//@lvxinke: 前兩者？@王海鵬Seal(《掌握需求過程》的譯者

? ? ? ? ? ?張克強-敏捷307：設想和業務規劃更像些，系統需求也許是，有些軟硬件一體化開發是先出系統需求，然后分解到軟件需求。 軟件需求肯定不是初步的了。

agile123：RUP中好像叫Stakeholder Requests（含Customer Needs），代表一開始收集來的各種原始、粗略、未經整理、分析和細化的初始“需求”，因不是正式、經確認的需求，所以不叫Requirements。另：CMMI、UP、SWEBOK...對幾十年來常用的軟件工程術語作了一些統一和規范，大家平時可以多參考，以免重新發明輪子。

? ? ? ? ? ? ?張克強-敏捷307：回復@agile123:贊，謝。其實這不是重新發明輪子的問題，估計是沒有統一說法的，只是列舉下，看看哪個占比多些

pinxue：是說 initial idea 吧，所謂初心是也。然后 brain storm 建立 vision，不知不覺 feature spreading，然后搞出個不知啥玩意

? ? ? ? ? ? ?王海鵬Seal：意識到也許可以搞出更好的東西，解決人們還沒意識到的痛苦。比如全球還有2/3的人不能上網，但他們不知道自己的痛苦。//@pinxue: 是說 initial idea 吧

? ? ? ? ? ? ?張克強-敏捷307：初心貌似是哲學詞匯，讓我想起了王陽明，軟件領域的話，初步需求應當比初心再多走些，感覺是根據初心做了些延伸思考，然后可得到收集

haitao深圳：系統或項目的需求。。。。叫什么不重要，怎么做需求調研、分析，才是一個項目成敗的關鍵

haitao深圳：先是吐槽現有系統、模式的痛點，吐槽的人、內容多了，就是新系統的必要性

徐鋒-需求：我從不糾結這些勞什子名詞！對于小型需求、變更需求而言；用戶提出的通常是以解決方案形式陳述的Want；需要分析其真正的Need，甚至是內心的win；從而結合開發成本，在解決方案上達成共識。而對于整個系統需求而言，用戶會有不同角度的需求片段，需要匯總成體系化的、指導開發的SRS。

? ? ? ? ? ?張克強-敏捷307：回復@徐鋒-需求: 但是為了便于收集最初的素材，總是要有個說法的，當然也許“需求素材”也是個不錯的說法。

黃勇TonyWong：業務需求層面我喜歡用“需求愿景”，提醒領導與決策層不要過多或者過早侵入用戶需求：用戶需求層面的我喜歡用“需求素材”，這樣會讓提供者明白他們不是在做設計，也會增加需求分析人員的責任感和使命感。

火星人陳勇：贊成業務需求，道出了本質。如果客戶懂業務直接提出技術需求，其他幾個名稱就崩潰了。

小結

調查進行時間不長，短短的4天就收集到了以上精彩觀點。但也確實可以看到這軟件需求前期階段存在不同說法。

試圖小結下，首先羅列下形容最初步需求的所有說法

1，業務需求

2，客戶需求

3，用戶需求

4，原始需求

5，用戶意見

6，客戶意見

7，設想

8，業務規劃

9，系統需求

10，Stakeholder Requests 干系人要求

11，Customer Needs 客戶需要

12，?initial idea ?初心

13，需求素材

14，需求愿景

（朋友們，如果你還有有不同的說法，請告訴我，或者你已經說了，但是我漏了）

這些不同的說法其實說明了如下的一點：在正式需求表述之前，是值得處理正式需求表述前的信息。

所謂的正式需求表述是指可供各方作為下一步工作開展的基礎，常見的有SRS-軟件需求規格說明，Use Case Analysis-用例分析

在敏捷開發中，常見是User Story-用戶故事。

這部分的說法 我建議 沿用軟件需求規格說明作為統稱，傳統SRS當然是SRS，采用Use Case或者User Stroy也同樣是軟件規格說明。

在最新的SWEBOK V3.0中就是采用了SRS這個說法。

更關鍵的問題

? ? ? ? ? 在SRS之前如何做？要不要分幾個階段做？出什么樣的產物，叫什么名稱？

在最新的SWEBOK V3.0中，用的是 Requirements Elicitation 作為標題，強調了從Requirements?Sources收集

Requirements elicitation is concerned with the

origins of software requirements and how the

software engineer can collect them. It is the first

stage in building an understanding of the problem

the software is required to solve. ?

It is variously termed “requirements capture,”

“requirements discovery,” and “requirements

acquisition.”?

Requirements have many sources in typical software, and it is essential that all potential sources

be identified and evaluated.?

而在CMMI for DEV V1.3中，對應是如下結構

SG 1 Develop Customer Requirements

SP 1.1 Elicit Needs

SP 1.2 Transform Stakeholder Needs into Customer Requirements

SG 2 Develop Product Requirements

SP 2.1 Establish Product and Product Component Requirements

SP 2.2 Allocate Product Component Requirements

SP 2.3 Identify Interface Requirements

傳統的SRS是面向軟件業界人員的，不便于讓客戶理解，所以CMMI區分了客戶需求和產品需求、產品組件需求，而Use Case和User Story的可讀性都很好，是直接可以給客戶看的。所以采用Use Case或者User Story的一份需求規格說明是可以同時滿足CMMI 上述兩個目標。

推薦的實踐

? ? ? ? ??SRS前在需求方面最緊要的事務是收集，而不是分析，所以我推薦采用“原始需求”（英文：Original Requirements, 或者origins of requirements)的說法，這個說法最有利于收集。無論宏觀展望，還是微觀雞毛蒜皮，無論總經理董事長，還是一些操作員，無論業務規劃、初心，還是要個醒目提示符，這些在原始需求下統統可以處理。

? ? ? ? ? SRS前如果再劃分階段的話，就顯得稍顯沉重了，一般的，SRS前沒有必要再分階段了。但是如果企業出于產品整體考慮，在集成產品開發下，為把握市場機會，投資回報，需要整理產品級需求文檔，常見的文檔名稱有市場機會分析、產品需求說明

結語

最后我想說的是在Scrum中只用單列表的Backlog是不夠用的。從backlog的字面意思上，直接的意思貌似是待辦項的單個列表，按照Scrum要求帶有優先級。

進入Sprint之后的 spring backlog中條目的顆粒度要能夠在sprint中實現。而Sprint之前的backlog中條目是難以限制顆粒度的，要緊的是采集，珍視市場機會，珍視客戶訴求。多列表+關聯或者樹形分解結構的backlog才能應對SRS前后不同顆粒度不同形態的需求。

另外需求的生命不是在上線后就結束了，后期還有更長時間的維護修改升級等等。?如果只是一個提供定制化交鑰匙工程的乙方，不負責后續運維升級，那么確實完成的user story可以不管了，但對于甲方或者是業主方，Backlog上做完的條目不是可以扔掉的。那么對照Backlog的字面意思，做完的需求繼續維護在Backlog中，是不是有點尷尬？ 如果說后續的修改按新的用戶故事來處理，那么隨著時間推移，老用戶故事、新用戶故事、新新用戶故事，新新新.......用戶故事都在，那是個什么景象？

真正實用的Backlog不是看上去那么簡單，也不只是待辦！

Backlog的字面意思與其實際使用存在差異，也許這就是PMO之道---蔡德輝?所說的敏捷帶來的“軟件工程的亂像”?之一。

BTW： 本調查和本報告是受PMO之道---蔡德輝?微博影響所發。

感謝參與討論的所有朋友。

總結

以上是生活随笔為你收集整理的最初步软件需求说法的简单调查报告的全部內容，希望文章能夠幫你解決所遇到的問題。

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