系統設計前的需求探索(1)

引言

需求分析階段需要經歷兩個步驟：首先，提出問題的人說一些話，以告訴幫助他解決問題的人他要干什么，這就是“問題陳述”，即通過語言或者文字對某個關注點的細節進行表述。然后，解決問題的人和提出問題的人進行溝通，以確證這個問題的細節，這就是“探索需求”，這是一個反復溝通的過程。

需求分析在現代軟件開發中的地位日趨重要，這也意味著我們認為現今的需求過程尚不完善。這種不完善很大程度上體現在“問題陳述”和“人們真正想要的東西”之間的差距上，或者說，“問題陳述”沒有能夠陳述清楚“人們真正想要的東西”。

在過去幾年，軟件過程和軟件工程流行的時代，很多人已經被時尚所左右，言必稱自動化，開口即軟件工程，仿佛所有的開發問題都已經解決。更有甚者，有人還認為需求分析中的歧義的根源是因為“人”的參與。有人認為“人”的不確定性導致了“陳述”的不確定性，由此導致了“人”提出的“問題陳述”的歧義。并且，他們認為只要排除掉需求分析過程中的人的因素，然后用一種嚴格論證、高度自動化的、規范的方法論來進行分析，就能夠消除這種歧義了。

但是，我們無法“剔除”具有嚴重不確定性的“顧客”；同樣，我們實在不能不把顧客當人看待的。

自動化方法干的是“大事情”。40年前需要很多個星期才能完成的工作量，今天只需要一個小時就能夠搞定。而且，由于自動化工具的發展，我們還開始挑戰那些在以前想都不敢想的系統。然而，隨著工具的進步，軟件產品在可用性方面的口碑卻并沒有多少提高。

對于那些需求明確、陳述無歧義、一定程度上模式化了的內容，自動化方法非常擅長；但是也還有一些涉及到人性心理方面的棘手問題卻無法用這些方法來解決。換句話說，只要是有規律的、統一的開發過程，自動化方法非常擅長；而在不同項目或產品之間的差異和個性化，則需要更細致的分析。

我們不妨做一個簡單的計算。

規模為S的項目中有P%的問題為公共問題，有Q%（Q＋P＝100）的問題為個性問題。

在時間T1時，我們每解決一個公共問題需要投入T，每解決一個個性問題需要投入M。解決個性問題在整個項目中所占的投入為：R1＝M×Q／（T×P＋M×Q）。

在時間T2時，我們每解決一個公共問題需要投入t，每解決一個個性問題需要投入m。解決個性問題在整個項目中所占的投入為：R2＝m×Q／（t×P＋m×Q）。

從T1到T2，自動化水平提高了，于是有T>>t，公共問題和個性問題的比例變化很小，而且對于每個個性問題的投入也變化很小，即有M≈m。從而可以得到R1<
這表明，隨著自動化水平的急劇提高，我們在個性問題方面的投入比例也急劇提高。

個性問題，亦即是人性方面的因素反而隨著自動化程度提高而愈顯得重要了。這一特征在那些具有多年開發經驗的人們當中早已成為了共識。也就是說，經驗豐富的專家們在技術任務上的投入少了，而在人性因素方面的投入更多了。

語言和符號系統

語言是我們表達思想的工具，也是某種文化的載體。在開發系統方法中，我們也有語言，那就是符號系統。相信所有人都遇到過因為語言不通而產生的交流障礙；同樣，在符號系統上，我們也遇到了交流障礙。

語言文字所傳遞的信息包括“內涵”和“外延”兩部分。人們在說話傳遞信息時，往往會附加上各種語態、表情、動作作為對其所說語音的外延；甚至我們可以認為，因為我們來自各個不同的省份縣市，各種不同的方言鄉音也傳遞了豐富的外延。

于是，對于同樣的事件或需求，我相信沒有任何兩個人的描述是完全一致的。承認這一點對于我們直面需求分析的困難會有很大的幫助。

我們這里給出優秀符號系統的兩個重要要求（當然這僅僅是眾多要求中的兩個），以幫助我們將來使用這些符號。例如說，首先符號系統要能夠比較全面地表述我們所遇到的絕大部分問題；其次為了適合產品開發的過程化，符號系統的表述結果要比較容易保存和修訂。這也是對一個優秀的CASE和CAD工具的基本要求：在任何時候都可以保留并修改我們當前的結果。實際上，幾乎所有的符號系統本身是不可能完全“直觀”和“易讀”的。

如果，要讓所有相關人員都能夠理解某種符號系統，那么，最直接的辦法就是培訓這些相關人員。下面的步驟可以測試一下當前的映射圖到底有多直觀：

1、把每一幅映射圖展示給那些不知道這種符號系統的人來看。這種方法能夠揭示出符號系統中不直觀的地方。當然，也有可能揭示的是這個映射圖中需要表達的那部分信息本身的不直觀。

2、讓每個人用自己熟悉的符號系統重新描述一遍對映射圖的理解，然后再讓一個理解這兩種符號系統的人來核對。這樣可以揭示映射圖中的一些人為的假設。

3、使用某種能夠把別的符號系統自動轉換成某種“標準”的符號系統的自動化工具。

上面講到了因為不同的符號系統導致的對映射圖的理解的分歧，這就相當于由于語言不通而導致了交流障礙。最直接最常見的辦法就是推遲需求工作的進度，先讓大家都來學習這種語言（或符號系統）。但是，這也是不切合實際的，因為這樣有可能還會讓大家失去對需求過程的興趣和沖動。經驗表明，把這些學習時間安排為需求階段的一部分會好一些，因為這時候我們可以一邊學習語言，一邊解決問題。

特別地，我們需要指出，任何一種符號系統都不可能百分之百地反映需求。下面提出了一些關于如何讓開發者較好地表述需求的語言的建議。

1、在生活（或開發項目）當中，我們往往會遇到一些不明是由的旁人（非專業人員）橫加職責，他們往往不愿意或者不屑于花時間來了解設計過程的時候，這時候，建議雇用一個明白事理而又口齒伶俐的調解人會比較有效。

2、人們不愿意參與設計過程的一個重要原因是現在的所謂“專業設計人員”的高高在上的姿態。千萬要注意顧客和旁人（實際上是決定事態結果的裁決者）僅僅是對開發過程不了解，他們在別的方面（比如說法律、業務等）卻是專家，這也是需要他們參與的原因。

3、一部分自動化過程的固執而忠實的擁躉認為他們的“直觀”的符號系統很容易被別人看懂。這時候，不妨讓他給小組里外的成員培訓一下他的符號系統。

4、對于同一個需求過程中的兩批不同背景的專家，常常會傾向于說兩種不同的符號系統。那么最好的辦法就是用兩種不同的符號系統都表述一遍。

5、用一種大家都能聽懂的語言來作為正式文檔的語言會比較有效，那么在需求過程中也最好事先指定一種“大家都能理解的”符號系統作為正式文檔。如果誰不懂的話，就讓他去學好了。

6、不同母語之間的翻譯會有優劣之分，同樣不同符號系統之間的翻譯也有優劣。優劣的背后就是分歧，也就是歧義。需求過程經歷了從真正最終用戶——用戶代表——需求分析員——需求規格說明書這么一長串的步驟，每一步都是一種翻譯，因此保證每一個步驟都是最優的就顯得格外重要了。

7、需要注意的是，需求過程并不完全是瀑布式的。隨著過程的深入，我們極有可能會像老牛一樣進行反芻。