大多數學計算機語言的人都會有過這樣的感受，過去一直認為編程和架構是整個軟件生命周期里最了不起的部分，但實際工作后才會發現在商業產品里，需求分析才是一個商業軟件成功與否的關鍵。

　　放眼望去，在當今軟件工程領域出現的許多問題，諸如缺陷及資源運用不當，都源于需求的不清晰，甚至有軟件人戲稱：“需求變更乃萬惡之源”，一時也獲得了頗多響應。時至如今，業務IT間需求分析過程中存在的問題主要有哪些？什么是敏捷需求分析？產品級和項目級需求有何異同？敏捷需求分析方法論中的五大關鍵點是什么？就以上熱點話題，雅各布森中國區總經理吳穹分享了他的看法。

　　三大癥狀

　　在吳穹看來，兩份需求、合同式驗證、產品需求缺失成為了當前需求溝通的三大癥結。

　　兩份需求——用戶（業務）需求和軟件需求。用戶需求由不熟悉IT的業務人員完成，大多歸于天馬行空的意識流，基本上是想起什么寫什么。而軟件需求由IT人員編寫，經過技術思維的過濾、梳理、增刪，包含進了算法、數據庫設計、架構之類的技術專業詞匯，業務人員往往已不知文檔內所云。

　　合同式驗證——業務人員和技術人員企圖在溝通后以合同形式將需求固化并且確定下來，而沒有充分考慮到軟件開發過程中可能出現的需求變更。

　　產品需求缺失——項目是片段，產品是總量，兩者的關系在于項目其實就是一個不斷完善產品的過程。由于國內PMP（ProjectManagement Professional）和項目管理流行，更多IT需求都是以項目形式存在，而往往忽視了產品需求的積累，導致最后的結果多是項目（需求）很多，但產品需求缺失。

　　項目級和產品級需求的具體區別，如果放在幾年或十多年前并不明顯，對于全新產品而言，項目（需求）=產品（需求）。隨著時間推移，兩者的區分逐步明朗，由于全新項目越來越少，更多的需求都是在維護和升級老的產品。以咖啡機為例，從基本型升級到1.1版，或許是加入一個按鈕。此時和客戶溝通的時候就需要引導客戶想清楚，需要的是項目級還是產品級的需求，是做整個咖啡機的需求還是僅僅只是新添按鈕的需求。如果未來再做1.2版，繼續添按鈕，這時候的需求又該如何寫？新按鈕的需求，然后和以前的按鈕有些變化。如果不能明確兩種需求的差異，隨著項目需求的累積，到最后會發現所有的（需求）都是片段的，都是增量而缺乏一個總的全景。

　　事實上，業務IT需求造成如今的混亂狀況，CMMI（Capability Maturity Model Integration，能力成熟度模型集成）和國內企業對CMMI的僵化理解可以說“功不可沒”。在對“兩份需求”的認識上，CMMI里有明確分項，用戶需求和軟件需求。但值得一提的是，其實里面并未明確要求是兩份文檔或由兩部分人來寫，而只是表示需求細化的兩個階段。遺憾的是，很多國內CMMI認證企業也并沒有真正打算去了解它的內涵，只是僵化地表現出自己是否有這樣的能力。

　　最近接觸到一些項目也出現了這樣的情形，大家先做了一份用戶需求，然后花費大量時間寫軟件需求，以滿足認證的需要，但到頭來軟件需求根本沒人看，大家都只是應付，CMMI成為了擺設。

　　需求貫穿于軟件開發測試全過程

　　在吳穹看來，敏捷的最大貢獻在于它是對整個軟件工程的一次再認識。具體到敏捷需求分析領域，其實涉及到一個核心問題：是否承認（軟件）需求可以在一開始就搞清楚并確定下來？敏捷的答案是No！而在傳統瀑布式開發中，更多的是合同式驗證的情形，大多數客戶的思想基礎都是基于需求最初就能確定下來的。但事實上，這在當前階段基本屬于“不可能完成的任務”，不符合軟件開發本質。在敏捷需求分析中，需求應是貫穿于整個軟件生命周期全過程中并在其中不斷變更、迭代和完善。

　　敏捷需求分析認為，需求應建立在以用例為中心的需求文檔體系，采取協作式而非合同式的溝通方式之上。具體可分為五個關鍵點：

　　用例；
　　協作；
　　迭代，即需求不是一次最終確定，而是先完成主要框架，再通過迭代逐步精化；
　　整個過程中以分析為支撐，做需求同時也在做分析，分析模型的輸出結果應跟需求分開；
　　把用例分解到用戶故事，在整個軟件生命周期過程中來驅動開發和測試。

　　業務/技術溝通頻現“兩份需求”

　　同時還要考慮到的是，將兩份需求改為一份文檔，而不必死摳CMMI概念區分出用戶和軟件需求。首份需求稿將由SA（系統分析師）來牽頭完成，負責各方協調和溝通的工作。理想的情況下，整個團隊在項目開始前就應搭建完畢，包括客戶、開發測試人員都參與的寫作和迭代，而不是以往的由技術人員對用戶進行里程碑式的教輔。通常來說，一個項目里一名SA同時對應5~9名開發人員是比較合適的。

　　需求文檔化與敏捷的平衡點

　　至于用例和用戶故事。按照敏捷大師Martin博客中的說法，兩者都是組織需求的方式，只是目的不同而已，用例的目的是為了把需求描述清楚，而用戶故事的目的是把需求分解成可用于迭代計劃的單元。對應到產品級和項目級文檔，用例是產品級，例如做咖啡機，不管有多少不同版本，有些核心功能是不改變的，這些都是產品級需求。而用戶故事則是項目級，屬于做完就扔的“拋棄型”。

　　進一步理解的話，用戶故事其實是一個或多個完整的業務場景，而用例是場景的抽象，一個用例里可以包含成百上千個場景。用戶故事是基于開發思想的，不光要考慮業務，還要考慮如何實現包括工作量大小、任務分配、項目風險以及架構風險等多重因素。有人認為寫用戶故事是極簡單的事，但在吳穹看來，現在有很多人都還在用功能點套用用戶故事，顯得不倫不類，而沒有理解到用戶故事的精髓。

　　以ATM取款為例，正常流程是插卡、取錢、把錢拿走。這個看似簡單的場景其實工作量很大，可以在整個流程中做一些必要的簡化。有人認為既然用戶故事是一個場景，那就把它變成一個場景步驟吧，于是就成了功能點。其實他們忽略了一點，用戶故事還是一個簡化了但還保證完整業務價值的場景。ATM取款建立用戶故事會涉及哪些因素呢？取款是否需要輸入密碼？小額取款時能否取消密碼輸入的步驟？取錢后打印賬單，查詢余額等，在這里面哪些功能是風險級別高的，哪些需要與銀行核心數據通信？這不僅涉及（功能）優先級的問題，還可以根據原則簡化用戶故事。例如可以考慮做一個用戶故事，儲戶用不需驗密的卡，限額是一千塊，取幾百塊錢的時候，把去銀行驗證的過程取消掉。這種情形下很多時候都要考慮到賬戶的風險情況，這些都需要多方溝通。類似的用戶故事簡化的情形有很多，但這時一定基于黑盒方式來做簡化。而在簡化的過程中，考慮如何實現如何合理調整工作量提高效率，這些都是找（用戶）故事的過程，也是一個白盒的過程。

　　在實現上，除了強調快速交付或生命周期很短、業務模式高度可變的互聯網、網游等項目，可以采用純用例的模式，現階段讓（大型）企業IT項目全面接納需求完全無文檔化還是不現實的，更實際的解決辦法是在文檔化和敏捷需求分析之間找到一個平衡，一份需求用例加上用戶故事，然后驅動開發這種方式，目前看來，這是現階段更適合大型企業的敏捷需求實踐模式。