緣起

筆者在這幾年工作中，接觸了各類需求，不同人員在不同的時(shí)間點(diǎn)按照不同表述方式來提供。在溝通交流中，有些時(shí)候會(huì)因?yàn)檎f法的不同和不同的說法，浪費(fèi)不少時(shí)間，往往會(huì)有這樣的感覺：唉，原來你說的是這個(gè)啊？ 或者是這樣：哦，我大概明白你的意思了，你的這個(gè)結(jié)構(gòu)邏輯是這樣的啊。

所以在4月10日在微博上發(fā)起了如下的調(diào)查

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

朋友們的精彩點(diǎn)評(píng)

PMO之道---蔡德輝：從設(shè)想、業(yè)務(wù)規(guī)劃、系統(tǒng)需求、軟件需求看看是哪個(gè)

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

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

? ? ? ? ? ?張克強(qiáng)-敏捷307：設(shè)想和業(yè)務(wù)規(guī)劃更像些，系統(tǒng)需求也許是，有些軟硬件一體化開發(fā)是先出系統(tǒng)需求，然后分解到軟件需求。 軟件需求肯定不是初步的了。

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

? ? ? ? ? ? ?張克強(qiáng)-敏捷307：回復(fù)@agile123:贊，謝。其實(shí)這不是重新發(fā)明輪子的問題，估計(jì)是沒有統(tǒng)一說法的，只是列舉下，看看哪個(gè)占比多些

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

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

? ? ? ? ? ? ?張克強(qiáng)-敏捷307：初心貌似是哲學(xué)詞匯，讓我想起了王陽明，軟件領(lǐng)域的話，初步需求應(yīng)當(dāng)比初心再多走些，感覺是根據(jù)初心做了些延伸思考，然后可得到收集

haitao深圳：系統(tǒng)或項(xiàng)目的需求。。。。叫什么不重要，怎么做需求調(diào)研、分析，才是一個(gè)項(xiàng)目成敗的關(guān)鍵

haitao深圳：先是吐槽現(xiàn)有系統(tǒng)、模式的痛點(diǎn)，吐槽的人、內(nèi)容多了，就是新系統(tǒng)的必要性

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

? ? ? ? ? ?張克強(qiáng)-敏捷307：回復(fù)@徐鋒-需求: 但是為了便于收集最初的素材，總是要有個(gè)說法的，當(dāng)然也許“需求素材”也是個(gè)不錯(cuò)的說法。

黃勇TonyWong：業(yè)務(wù)需求層面我喜歡用“需求愿景”，提醒領(lǐng)導(dǎo)與決策層不要過多或者過早侵入用戶需求：用戶需求層面的我喜歡用“需求素材”，這樣會(huì)讓提供者明白他們不是在做設(shè)計(jì)，也會(huì)增加需求分析人員的責(zé)任感和使命感。

火星人陳勇：贊成業(yè)務(wù)需求，道出了本質(zhì)。如果客戶懂業(yè)務(wù)直接提出技術(shù)需求，其他幾個(gè)名稱就崩潰了。

小結(jié)

調(diào)查進(jìn)行時(shí)間不長(zhǎng)，短短的4天就收集到了以上精彩觀點(diǎn)。但也確實(shí)可以看到這軟件需求前期階段存在不同說法。

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

1，業(yè)務(wù)需求

2，客戶需求

3，用戶需求

4，原始需求

5，用戶意見

6，客戶意見

7，設(shè)想

8，業(yè)務(wù)規(guī)劃

9，系統(tǒng)需求

10，Stakeholder Requests 干系人要求

11，Customer Needs 客戶需要

12，?initial idea ?初心

13，需求素材

14，需求愿景

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

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

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

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

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

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

更關(guān)鍵的問題

? ? ? ? ? 在SRS之前如何做？要不要分幾個(gè)階段做？出什么樣的產(chǎn)物，叫什么名稱？

在最新的SWEBOK V3.0中，用的是 Requirements Elicitation 作為標(biāo)題，強(qiáng)調(diào)了從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中，對(duì)應(yīng)是如下結(jié)構(gòu)

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

傳統(tǒng)的SRS是面向軟件業(yè)界人員的，不便于讓客戶理解，所以CMMI區(qū)分了客戶需求和產(chǎn)品需求、產(chǎn)品組件需求，而Use Case和User Story的可讀性都很好，是直接可以給客戶看的。所以采用Use Case或者User Story的一份需求規(guī)格說明是可以同時(shí)滿足CMMI 上述兩個(gè)目標(biāo)。

推薦的實(shí)踐

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

? ? ? ? ? SRS前如果再劃分階段的話，就顯得稍顯沉重了，一般的，SRS前沒有必要再分階段了。但是如果企業(yè)出于產(chǎn)品整體考慮，在集成產(chǎn)品開發(fā)下，為把握市場(chǎng)機(jī)會(huì)，投資回報(bào)，需要整理產(chǎn)品級(jí)需求文檔，常見的文檔名稱有市場(chǎng)機(jī)會(huì)分析、產(chǎn)品需求說明

結(jié)語

最后我想說的是在Scrum中只用單列表的Backlog是不夠用的。從backlog的字面意思上，直接的意思貌似是待辦項(xiàng)的單個(gè)列表，按照Scrum要求帶有優(yōu)先級(jí)。

進(jìn)入Sprint之后的 spring backlog中條目的顆粒度要能夠在sprint中實(shí)現(xiàn)。而Sprint之前的backlog中條目是難以限制顆粒度的，要緊的是采集，珍視市場(chǎng)機(jī)會(huì)，珍視客戶訴求。多列表+關(guān)聯(lián)或者樹形分解結(jié)構(gòu)的backlog才能應(yīng)對(duì)SRS前后不同顆粒度不同形態(tài)的需求。

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

真正實(shí)用的Backlog不是看上去那么簡(jiǎn)單，也不只是待辦！

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

BTW： 本調(diào)查和本報(bào)告是受PMO之道---蔡德輝?微博影響所發(fā)。

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。