【IT書摘】從需求到設計──如何設計出客戶想要的產品

從需求到設計── 　如何設計出客戶想要的產品 　（Exploring Requirements: 　Quality Before Design） 　唐納德．高斯（Donald C. Gause）、 　傑拉爾德．溫伯格（Gerald M. Weinberg ）/著 　褚耐安/譯 　經濟新潮社 　售價：550元

CASE、CAD，和蟑螂必殺器
「分析及設計工作站」就類似蟑螂必殺器的A鐵板。「檢索功能」則類似蟑螂必殺器的B鐵板。如果你能想出需求規格，工作站即能「抓取」它們，檢索功能則能「管理」它們。這兩個步驟完成之後，產出功能即能清理雜亂，獲臻成果。

圖表和表示法
任何一種系統設計方法，其中最重要的是表示法（notation），也就是系統概念它自己的符號化方式。用我們的術語來說，就好像是，有許多種繪圖的系統。

確認圖表可以被每個人看懂
圖表所運用的特殊符號，其實沒有想像中重要。每一種表示法各有其優缺點，及一些可用的工具，但運用圖表最重要的工具是人類的頭腦。所以，一張圖最重要的特質，即是讓每個人都可以看得懂。

心得、建議與摘要
你必須隨時做好準備，當進行需求要件作業時，若發現在決策樹的高處有一根錯誤的枝枒，就要立即回頭修正「譯本」或「圖表」。因此，我們必須摒除「只有一條正確道路」或「完美翻譯」的觀念。

相關閱讀：
書評－你真的找對需求了嗎？

CASE、CAD，和蟑螂必殺器
有些讀者同意我們的看法，認為需求陳述曖昧（ambiguity）的問題必須解決，但他們認為問題不在於技術，而是在於人。他們指出，要獲得清楚而明確的需求要件（requirements），必須去除人的因素，而且使用特定的方法（methodology）。事實上，他們指的是完全自動化（automated）的方法—在開發過程中完全不需要人。

我們1958年開始教授軟體開發時，幾乎沒有一家公司發展出特定的開發方法。現在，套裝的開發方法充斥市場。幾乎每一個做軟體設計的人，手上都有幾套開發方法。目前，電腦輔助軟體工程（CASE）和電腦輔助設計（CAD）很熱門，兩者都宣稱在開發時無須使用人力。所以，為什麼我們還需要靠人去弄清楚需求要件呢？為什麼還有人需要看討論「人性化設計」的書？CASE和CAD不是已經保證，任何人都可以正確無誤地獲得正確無誤的需求要件嗎？我們可不這麼認為。而且，蟑螂必殺器（Guaranteed Cockroach Killer）的例子，可以充分說明為什麼。

多年來，有個住在紐約的人，靠著刊登分類廣告販賣蟑螂必殺器。你寄給他一張五元支票，他兌現支票後，就會寄一組如圖1-1所示的工具給你。

他在說明書上寫著：

1.把蟑螂放在A鐵板上。
2.用B鐵板打蟑螂。

如果你按照說明書操作，必能殺死蟑螂。不過，說明書上還應該再加一項：

3.清除屍體。

但是，似乎沒有人用到第三項說明──因為沒有人能把蟑螂抓到A鐵板上。

那麼，蟑螂必殺器和CASE和CAD又有什麼關係？某個CASE的說明書上寫著，CASE工具包括三項基本的應用開發技術：

1.分析以及設計工作站，俾能抓取需求規格。
2.檢索功能，以管理並控制需求規格訊息。
3.產出功能，將需求規格轉化為程式碼和文件。

根據我們的經驗，「分析及設計工作站」就類似蟑螂必殺器的A鐵板。「檢索功能」則類似蟑螂必殺器的B鐵板。如果你能想出需求規格，工作站即能「抓取」它們，檢索功能則能「管理」它們。這兩個步驟完成之後，產出功能即能清理雜亂，獲臻成果。

如果你能完成你那部分的工作，CASE和CAD就保證能發揮它們的功能。本書的內容，即是你應該做的那個部分：把蟑螂抓到A鐵板上，而且讓它在鐵板上靜止不動一段時間，好讓你重重一擊。

不論是蟑螂或需求，最困難的部分是抓到它們，而且讓他們靜止不動。產出程式碼和清除蟑螂屍體一樣，是一件瑣碎工作，與前兩個步驟迥然不同。因此我們認為，除了運用保證有效的CASE和CAD這兩種工具之外，你還需要本書所提供的工具。而且，你使用的CASE和CAD功能愈佳，你愈需要我們的工具。讓我們來看看為什麼。

方法改變了問題
毫無疑問地，正規方法──尤其是自動化的正規方法──已改變系統設計工作的本質。1958年必須耗費數星期才能完成的系統設計工作，現在只花幾個鐘頭就可以大功告成。運用現有的超級工具和方法，現在系統設計師能做1958年無法想像的事。但是，即便有些系統只需一點點時間即完成設計，仍有許多系統設計案須耗費多年才能完成。

不僅如此，在一個系統內，正規方法最容易處理的問題，可以迅速被解決，但剩下來的瑣碎（messy）問題，則無法運用正規方法來解決。基於上述兩種效應，問題的本質已然有所改變，如圖1-2所示。

從事產品設計和系統設計多年的人，在他們的日常工作中，已發現到這個問題。他們覺得，用於處理技術性工作的時間愈來愈少，用於處理人與人之間關係的時間愈來愈多；用於細微末節工作的時間愈來愈少，大問題則似乎永遠處理不完。本書的主旨，即是處理正規方法未碰觸到的「瑣碎」問題，以及對於正規方法期望過高所導致的企圖心太大的問題。

圖表和表示法
我們的方法，曾經與多種CASE和CAD，以及其他多種設計方式聯合運用。我們曾經與多種資訊系統方法如Warnier-Orr、Jackson、Ross的SADT、Yourdon-Constantine，以及Gane-Sarson等配合。我們也曾運用我們這項工具於傳統工程領域，如電子工程、機械工程、建築和城市規畫。

任何一種系統設計方法，其中最重要的是表示法（notation），也就是系統概念它自己的符號化方式。用我們的術語來說，就好像是，有許多種繪圖的系統。做城市規畫的時候，有許多傳統地圖很容易判讀。在建築工程方面，平面圖和外觀圖也很容易看得懂，但管線圖和材料表則比較抽象。描繪機械和零件的固然是圖，表示材料強度的表格也是圖。

圖1-3和圖1-4是同一個程序（寫信）的兩種表示法。圖1-3運用圖示，很容易一目了然。圖1-4雖然不能被多數人快速判讀，但不容易產生誤解，程序變化時容易修改。

譬如，圖1-3的打字機是人工打字機，圖1-4卻沒有明確指出打字機是哪一種。如果這個程序使用電動打字機非常重要，圖1-4應該指明是電動打字機，圖1-3則應該畫一臺電動打字機。哪一種表示法比較好？雖然CASE的支持者可以為這個問題爭論不休，但它並沒有正確答案，因為兩張圖各以不同的方式呈現程序。因此，兩張圖各有功能，甚至都必要。

一個好的表示法的重要特質是容易修改，而且不影響需求要件作業的順暢度。我們不希望圖表的應用過於僵硬，以至於更改圖表變得非常麻煩。這也是CASE和CAD的最大優點：我們隨時能看到呈現目前狀況的圖表。

確認圖表可以被每個人看懂

圖表所運用的特殊符號，其實沒有想像中重要。每一種表示法各有其優缺點，及一些可用的工具，但運用圖表最重要的工具是人類的頭腦。所以，一張圖最重要的特質，即是讓每個人都可以看得懂。

每一種表示法的支持者都認為，他們繪製的圖表是「直覺式的」，而且「容易看懂」，就好比說中國文字是直覺式的──對於住在北京的中國人而言。事實上，如果某人花了許多時間製作圖表，這張圖對他而言就是直覺式的。但是在需求要件作業階段，由於參與工作的人大部分都不是專業的需求文件製作者，或許也是第一次使用這種圖表，因此很難依直覺了解這類圖表的內容。

由於多數參與設計工作的人都是「專業人士」，至少有些圖表無須專業訓練就能看懂。運用某些特殊圖表時，必須預留一段使工作人員熟悉圖表的時間。為了讓工作人員熟悉圖表，必須做以下各項動作：

1. 每一張圖，由不熟悉這張圖的人負責解說。這種方式不但能彰顯圖表本身的語意曖昧之處，也能彰顯圖表功能的曖昧之處。

2. 由於每一種圖表各有優缺點，最好每一個工作人員都有繪製數種圖表的能力。為了達成這個目的，可以要求工作人員將某圖表轉繪為另一種圖表。圖1-3轉繪為圖1-4之時，轉繪者可能認為，打信件和打信封使用同一部打字機。這個假設值得討論，並引發如何準備信紙和信封的假設的討論。

3.更好的方式為，運用具有數種繪圖功能的CASE或CAD，而且具備即時轉繪圖表為另一種圖表的功能。這套系統，能將一張圖以不同的方式呈現，使各個工作人員都能看到自己熟悉的圖表。但是，這種全自動化的方法，無法取代方法1和方法2。因為這兩種方法能使工作人員更深入了解圖表，因而學得更多。

4. 為了使每個工作人員都熟悉圖表，最常使用的方法為，先讓成員上一堂讀圖課，然後再進行需求要件作業。重視讀圖問題固然值得嘉許，但發現問題再補習卻不足採。如果已安排好每個成員的工作進度表，為了讀圖的問題，必須重新訂定進度表，將降低成員的工作士氣。因此，讀圖課程應列為討論需求要件會議的一部分，並以擬設計之系統的相關圖表為實例，進行教學。

需求要件圖表並非需求要件本身
探索需求要件時，設計者根據的是需求要件圖表（maps of require-ments），而非需求要件本身。有一次，我們和一位瑞典客戶合作，他告訴我們，瑞典軍人有一項非常重要的原則：

地圖和實況不符合時，以實況為準。

工作人員常囿於正規設計系統（尤其是使用自動繪圖工具時），因此常以為地圖就是實況，而忘了另有實況存在。譬如判讀圖1-3，你可能不自覺地認為執行程序的是個女人，因為人形符號畫的似乎是女性。你也可能認為，整個程序都由同一個女人操作，因為圖中的人形符號都相同。

或者，解讀圖1-4時，你可能認為複印檔案和裝入信封是同時進行。這個認定必須假設，有一種機器可以複印文件──譬如碳粉影印機或雷射印表機。圖1-5的繪圖方式與圖1-4相同，但內容不同。在圖1-5中，影印和寫信同時進行。

圖1-6是圖1-5的另一版本，用另一種也很常用的表示法。有些人認為，圖1-6比圖1-5容易判讀；有些人則認為，圖1-5比圖1-6容易判讀。我們認為這是個人偏好的問題，而且與個人習慣哪一種表示法有關。最重要的是使用圖表的目的──使用哪一種圖表，必須根據我們手頭上的工作屬於哪一類型，以及我們希望避免哪一類錯誤。

心得與建議
● 開發專案複雜度高的另一個原因，是因為希望非專業人士也參與產品的設計工作。多數使用者希望，於產品設計階段能盡量不參與，但也希望釐清需求要件階段的成果，能符合他們的期望。由於使用者希望盡量不參與產品設計，工作人員繪製的圖表就變得非常重要。而且，使用者讀圖表的時候有許多問題，必須釐清。解決這個問題有一個方法，即是派專人指導使用者，使他由專業白痴變成這方面的專家──但如果使用者不肯努力學習，仍將徒勞無功。

● 客戶不願意參與設計程序的原因之一，是因為專業設計者自視甚高。務必記住，客戶只是不懂設計程序，他們在自己的領域裡可是專家（而專業設計者通常不是）。因此，客戶的參與是必要的。如果我們能營造出分享專業知識的氛圍，客戶將樂於參與設計工作。

● 設計專家常低估解讀圖表的困難度，他們認為圖表應該是「直覺式的」。為了讓專家們了解什麼叫做「直覺式」圖表，可以考慮讓他們設計全世界通用的路標看看。

● 當兩組專家共同參與一個需求要件作業，對於哪一種圖表是直覺式的，常發生爭論。在巴黎長大的小孩，認為法文是直覺式的；在蒙特婁長大的小孩，認為法文和英文都是直覺式的。同樣的道理，專家對於圖表都有著「初戀症候群」。

這種偏執是可以避免的。譬如我們對兒童施予雙語教育，即能避免他們偏執於某一語言。教導他人繪圖或製圖，必須同時教導兩種方式。每一張圖都以兩種方式繪製，然後比較哪一種方式表達得較清楚。

● 在探索需求要件的程序中，嫻熟圖表的人將取得主導地位，並排擠不熟悉圖表的人。如果你不希望工作團隊形成派系，就必須致力於泯除語言隔閡。試著採用瑞士模式：每一個工作成員的「初戀」圖表，都是釐清需求要件階段的「官方」語言。在這個階段完成之前，每一份正式文件，都必須用每一種官方語言表述。

瑞士模式的多種語言方式，看起來很繁複，但只要執行時基本精神正確，運作成效相當良好。事實上，在瑞士開會的時候，如果某種語言為大多數人使用（即「主流」語言），則表述意見時通常會使用「第二」語言，以表示對少數參與族群的尊重，並明白表示重視少數族群的價值。根據我們自己的經驗，運用多種語言的方式，總是能夠更精確界定出需求要件，並使所有的參與者更積極參與。

● 我們的同事艾立克‧明屈（Erick Minch）建議一個理論模式，即對於設計內容的所有描述──包括各個需求要件及滿足需求要件的方法、限制和決策、最後的實作說明──都可以視為是不同「語言」的表述。換句話說，我們不認為這些內容是運用單一語言做不同表述，而是以多種語言表述同一內容。因此，整個設計工作就包括找出一個語言轉換方式，而最後的產出即是這個轉換方式。

這個構想讓我們注意到，「翻譯」並不是我們通常認為的一字對應一字模式。有些翻譯工作本身即是一種藝術。下列愛德華‧費茲傑羅（Edward FitzGerald）英譯的奧瑪‧卡嚴（Omar Khayy）四行詩，即是一個很好的說明範例：

大樹下，一本書，
一壺酒，一塊麵包──還有你
野地裡，你在我身邊歌唱──
喔，野外成為真正的天堂。

奧瑪是十一世紀波斯的帳棚製造匠，也是天文學家和數學家。費茲傑羅是十九世紀英國索沃克郡（Suffolk）的紳士。上述詩句，有多少是奧瑪的原意，有多少是費茲傑羅添加（或刪減）的？你我朗誦時，又添加或刪減了多少？

使用最終產品的時候，我們不在乎它是否被正確轉化，只在乎我們是不是喜歡這項產品。也就是說，在開發產品的過程中，任何一個階段都可能增益其價值，需求要件只是指示方向罷了。需求要件應該被逐句遵守，但也不要矯枉過正。條條大路通天堂。

● 我們在IBM的同事肯恩‧拉溫尼（Ken de Lavigne）曾說過一段話，與上述觀點直接相關：「你對於圖表的討論，引導出『逐步修正法』（stepwise refinement）最大的問題──雖然使用逐步修正法的人宣稱，他們延遲決策至必須做決定的時候，事實上，卻是最遠端的決定最先做成，而且是在相關資訊最少的時候。」

你必須隨時做好準備，當進行需求要件作業時，若發現在決策樹的高處有一根錯誤的枝枒，就要立即回頭修正「譯本」或「圖表」。因此，我們必須摒除「只有一條正確道路」或「完美翻譯」的觀念。

摘要
為什麼？
「探索」（exploring）是根據需求要件圖表，而不是根據需求要件本身。我們進行探索，以繪製地圖，並終於繪製出以「實用」為目的，並接近實況的地圖。

何時？
作業的時候，務必根據圖表，而不是根據實際狀況。因此，務必致力於讓眾人了解所使用的圖表。如果問他人：「你能說明你的圖表嗎？」這是在釐清需求要件階段必然會問的問題。問這個問題的時候，無須覺得自己太蠢，或是在向他人挑釁。

如何？
製圖固然是一項重要程序，但更重要的是，製圖代表了解並確信清楚溝通的重要性，以及願意致力於清晰溝通。為了避免溝通發生問題，請參考下列各項：

1. 不可將困難的部分留給他人處理，如蟑螂必殺器的例子。

2. 隨時準備好，運用新方法可能導致的變動。有些人很難適應新方法和新圖表，不可低估這方面的效應。

3. 了解每一個人都不同，因此，各個人對各種圖表的解讀不同。務必接受不同的解讀而不要求齊一意見，或嘲笑他人「愚蠢」。

4. 確認每一個人在每一個階段都能判讀圖表，因而不排擠任何人。

5. 如果你發現圖表與實際狀況有差異，務必記住，圖表並非就是實際狀況，而且世界上沒有十全十美的翻譯。（本文摘錄自第一章）