需求工程系列（一）- 軟體需求的困境 – 分析代替了需求

十年來國內軟體工程方面的進展有目共睹，在軟體需求方面，我們看到在大多數組織中已經建立起了一級或兩級需求體系（業務需求和軟體需求）；在某些組織中，需求分析員已經成為一種專門的職位；甚至在某個大型國有商業銀行已經成立一個專門的部門來負責需求分析工作。應該來說，這是一些非常可喜的進步。 然而，目前大多數的項目參與者都對需求工程的現狀不滿，這又是為什麼呢？首先，我們必須承認市場快速變化而帶來的需求變化的確對項目帶來了很大的挑戰，為此許多項目應用了迭代化開發來應對這樣的變化。但根據我們對客戶的訪談，更多的需求變化是由於需求溝通不力造成的，也就是說，參與需求溝通的各方並沒有達成真正的共識，這又是什麼原因呢？根據我們的分析，這主要是由於缺少一個可以被各方真正理解和溝通、並可以被逐步精化的需求體系。 目前，大多數使用者採用的需求體系基本上是沿襲了結構化分析的文檔體系（包括資料流圖，資料字典等）。這種文檔體系起源於70年代，當時，軟體的主要應用還是科學計算或資訊處理，理解需求的人往往也受過結構化分析的相關教育，然而這些內容對今天的大多說業務人員或終端使用者而言就是很難理解的了。這裡的主要問題是 分析代替了需求。為瞭解決這個問題，有的組織引入了非形式化、非結構化的業務需求，然而卻很難在兩種需求之間建立明確的對應關係，從而出現了業務人員/終端使用者認可業務需求，但開發人員覺得不夠詳細；開發人員認可軟體需求，但業務人員/終端使用者無法給與確認。 那麼，我們如何解決這一軟體需求的困境呢？ （待續）