語言和符號系統
語言是我們表達思想的工具，也是某種文化的載體。在開發系統方法中，我們也有語言，那就是符號系統。相信所有人都遇到過因為語言不通而產生的交流障礙；同樣，在符號系統上，我們也遇到了交流障礙。
語言文字所傳遞的信息包括“內涵”和“外延”兩部分。人們在說話傳遞信息時，往往會附加上各種語態、表情、動作作為對其所說語音的外延；甚至我們可以認為，因為我們來自各個不同的省份縣市，各種不同的方言鄉音也傳遞了豐富的外延。
于是，對于同樣的事件或需求，我相信沒有任何兩個人的描述是完全一致的。承認這一點對于我們直面需求分析的困難會有很大的幫助。
我們這里給出優秀符號系統的兩個重要要求（當然這僅僅是眾多要求中的兩個），以幫助我們將來使用這些符號。例如說，首先符號系統要能夠比較全面地表述我們所遇到的絕大部分問題；其次為了適合產品開發的過程化，符號系統的表述結果要比較容易保存和修訂。這也是對一個優秀的CASE和CAD工具的基本要求：在任何時候都可以保留并修改我們當前的結果。
實際上，幾乎所有的符號系統本身是不可能完全“直觀”和“易讀”的。
如果，要讓所有相關人員都能夠理解某種符號系統，那么，最直接的辦法就是培訓這些相關人員。下面的步驟可以測試一下當前的映射圖到底有多直觀：
把每一幅映射圖展示給那些不知道這種符號系統的人來看。這種方法能夠揭示出符號系統中不直觀的地方。當然，也有可能揭示的是這個映射圖中需要表達的那部分信息本身的不直觀。
讓每個人用自己熟悉的符號系統重新描述一遍對映射圖的理解，然后再讓一個理解這兩種符號系統的人來核對。這樣可以揭示映射圖中的一些人為的假設。
使用某種能夠把別的符號系統自動轉換成某種“標準”的符號系統的自動化工具。
上面講到了因為不同的符號系統導致的對映射圖的理解的分歧，這就相當于由于語言不通而導致了交流障礙。最直接最常見的辦法就是推遲需求工作的進度，先讓大家都來學習這種語言（或符號系統）。但是，這也是不切合實際的，因為這樣有可能還會讓大家失去對需求過程的興趣和沖動。經驗表明，把這些學習時間安排為需求階段的一部分會好一些，因為這時候我們可以一邊學習語言，一邊解決問題。
特別地，我們需要指出，任何一種符號系統都不可能百分之百地反映需求。下面提出了一些關于如何讓開發者較好地表述需求的語言的建議。
在生活（或開發項目）當中，我們往往會遇到一些不明是由的旁人（非專業人員）橫加職責，他們往往不愿意或者不屑于花時間來了解設計過程的時候，這時候，建議雇用一個明白事理而又口齒伶俐的調解人會比較有效。
人們不愿意參與設計過程的一個重要原因是現在的所謂“專業設計人員”的高高在上的姿態。千萬要注意顧客和旁人（實際上是決定事態結果的裁決者）僅僅是對開發過程不了解，他們在別的方面（比如說法律、業務等）卻是專家，這也是需要他們參與的原因。
一部分自動化過程的固執而忠實的擁躉認為他們的“直觀”的符號系統很容易被別人看懂。這時候，不妨讓他給小組里外的成員培訓一下他的符號系統。
對于同一個需求過程中的兩批不同背景的專家，常常會傾向于說兩種不同的符號系統。那么最好的辦法就是用兩種不同的符號系統都表述一遍。
用一種大家都能聽懂的語言來作為正式文檔的語言會比較有效，那么在需求過程中也最好事先指定一種“大家都能理解的”符號系統作為正式文檔。如果誰不懂的話，就讓他去學好了。
不同母語之間的翻譯會有優劣之分，同樣不同符號系統之間的翻譯也有優劣。優劣的背后就是分歧，也就是歧義。需求過程經歷了從真正最終用戶——用戶代表——需求分析員——需求規格說明書這么一長串的步驟，每一步都是一種翻譯，因此保證每一個步驟都是最優的就顯得格外重要了。
需要注意的是，需求過程并不完全是瀑布式的。隨著過程的深入，我們極有可能會像老牛一樣進行反芻。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
