大多數(shù)學(xué)計(jì)算機(jī)語(yǔ)言的人都會(huì)有過(guò)這樣的感受，過(guò)去一直認(rèn)為編程和架構(gòu)是整個(gè)軟件生命周期里最了不起的部分，但實(shí)際工作后才會(huì)發(fā)現(xiàn)在商業(yè)產(chǎn)品里，需求分析才是一個(gè)商業(yè)軟件成功與否的關(guān)鍵。
放眼望去，在當(dāng)今軟件工程領(lǐng)域出現(xiàn)的許多問(wèn)題，諸如缺陷及資源運(yùn)用不當(dāng)，都源于需求的不清晰，甚至有軟件人戲稱：“需求變更乃萬(wàn)惡之源”，一時(shí)也獲得了頗多響應(yīng)。時(shí)至如今，業(yè)務(wù)IT間需求分析過(guò)程中存在的問(wèn)題主要有哪些？什么是敏捷需求分析？產(chǎn)品級(jí)和項(xiàng)目級(jí)需求有何異同？敏捷需求分析方法論中的五大關(guān)鍵點(diǎn)是什么？就以上熱點(diǎn)話題，雅各布森中國(guó)區(qū)總經(jīng)理吳穹分享了他的看法。
三大癥狀
在吳穹看來(lái)，兩份需求、合同式驗(yàn)證、產(chǎn)品需求缺失成為了當(dāng)前需求溝通的三大癥結(jié)。
兩份需求——用戶（業(yè)務(wù)）需求和軟件需求。用戶需求由不熟悉IT的業(yè)務(wù)人員完成，大多歸于天馬行空的意識(shí)流，基本上是想起什么寫(xiě)什么。而軟件需求由IT人員編寫(xiě)，經(jīng)過(guò)技術(shù)思維的過(guò)濾、梳理、增刪，包含進(jìn)了算法、數(shù)據(jù)庫(kù)設(shè)計(jì)、架構(gòu)之類(lèi)的技術(shù)專業(yè)詞匯，業(yè)務(wù)人員往往已不知文檔內(nèi)所云。
合同式驗(yàn)證——業(yè)務(wù)人員和技術(shù)人員企圖在溝通后以合同形式將需求固化并且確定下來(lái)，而沒(méi)有充分考慮到軟件開(kāi)發(fā)過(guò)程中可能出現(xiàn)的需求變更。
產(chǎn)品需求缺失——項(xiàng)目是片段，產(chǎn)品是總量，兩者的關(guān)系在于項(xiàng)目其實(shí)就是一個(gè)不斷完善產(chǎn)品的過(guò)程。由于國(guó)內(nèi)PMP（ProjectManagement Professional）和項(xiàng)目管理流行，更多IT需求都是以項(xiàng)目形式存在，而往往忽視了產(chǎn)品需求的積累，導(dǎo)致最后的結(jié)果多是項(xiàng)目（需求）很多，但產(chǎn)品需求缺失。
項(xiàng)目級(jí)和產(chǎn)品級(jí)需求的具體區(qū)別，如果放在幾年或十多年前并不明顯，對(duì)于全新產(chǎn)品而言，項(xiàng)目（需求）=產(chǎn)品（需求）。隨著時(shí)間推移，兩者的區(qū)分逐步明朗，由于全新項(xiàng)目越來(lái)越少，更多的需求都是在維護(hù)和升級(jí)老的產(chǎn)品。以咖啡機(jī)為例，從基本型升級(jí)到1.1版，或許是加入一個(gè)按鈕。此時(shí)和客戶溝通的時(shí)候就需要引導(dǎo)客戶想清楚，需要的是項(xiàng)目級(jí)還是產(chǎn)品級(jí)的需求，是做整個(gè)咖啡機(jī)的需求還是僅僅只是新添按鈕的需求。如果未來(lái)再做1.2版，繼續(xù)添按鈕，這時(shí)候的需求又該如何寫(xiě)？新按鈕的需求，然后和以前的按鈕有些變化。如果不能明確兩種需求的差異，隨著項(xiàng)目需求的累積，到最后會(huì)發(fā)現(xiàn)所有的（需求）都是片段的，都是增量而缺乏一個(gè)總的全景。
事實(shí)上，業(yè)務(wù)IT需求造成如今的混亂狀況，CMMI（Capability Maturity Model Integration，能力成熟度模型集成）和國(guó)內(nèi)企業(yè)對(duì)CMMI的僵化理解可以說(shuō)“功不可沒(méi)”。在對(duì)“兩份需求”的認(rèn)識(shí)上，CMMI里有明確分項(xiàng)，用戶需求和軟件需求。但值得一提的是，其實(shí)里面并未明確要求是兩份文檔或由兩部分人來(lái)寫(xiě)，而只是表示需求細(xì)化的兩個(gè)階段。遺憾的是，很多國(guó)內(nèi)CMMI認(rèn)證企業(yè)也并沒(méi)有真正打算去了解它的內(nèi)涵，只是僵化地表現(xiàn)出自己是否有這樣的能力。
最近接觸到一些項(xiàng)目也出現(xiàn)了這樣的情形，大家先做了一份用戶需求，然后花費(fèi)大量時(shí)間寫(xiě)軟件需求，以滿足認(rèn)證的需要，但到頭來(lái)軟件需求根本沒(méi)人看，大家都只是應(yīng)付，CMMI成為了擺設(shè)。
需求貫穿于軟件開(kāi)發(fā)測(cè)試全過(guò)程
在吳穹看來(lái)，敏捷的最大貢獻(xiàn)在于它是對(duì)整個(gè)軟件工程的一次再認(rèn)識(shí)。具體到敏捷需求分析領(lǐng)域，其實(shí)涉及到一個(gè)核心問(wèn)題：是否承認(rèn)（軟件）需求可以在一開(kāi)始就搞清楚并確定下來(lái)？敏捷的答案是No！而在傳統(tǒng)瀑布式開(kāi)發(fā)中，更多的是合同式驗(yàn)證的情形，大多數(shù)客戶的思想基礎(chǔ)都是基于需求最初就能確定下來(lái)的。但事實(shí)上，這在當(dāng)前階段基本屬于“不可能完成的任務(wù)”，不符合軟件開(kāi)發(fā)本質(zhì)。在敏捷需求分析中，需求應(yīng)是貫穿于整個(gè)軟件生命周期全