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