名人推薦：名家書評：

如果你想要開發一樣新產品，你應該讀這本書。──Watts S. Humphrey, 卡內基美隆大學軟體工程學院

高斯和溫伯格……點出了產品開發過程中，最隱微但最重要的環節：對於需求要件必須有適當的了解。本書運用啟發性的實例，提供了一整套的工作方法。──Barry Boehm，加州大學洛杉磯分校，《軟體工程經濟學》作者

對於系統分析師的智識提升很有幫助。──Tom DeMarco，知名軟體顧問，《Peopleware》、《最後期限》作者

看過本書之後，你永遠不會再相信「過時的需求要件」──不論是誰交給你，或給你的時候多麼嚴肅認...

前言

產品開發的工作就是：將某人的想望（desires），轉化為能夠滿足這個想望的產品的過程。本書要討論的是需求要件作業程序（requirements process）──也就是開發過程中，人們試圖發掘什麼是人們想要的（people attempt to discover what is desired）的過程。

為了了解這個程序，讀者們必須注意五個關鍵詞：想望、產品、人、試圖、發掘。

首先，考量「想望」（desire）這個詞。有些讀者比較喜歡說成「試圖發掘什麼是人們需要的（needed）」。但是相對於人們想要的，我們更不知道如何找出人們的需要。此外，人們並非總是購買他們需要的東西，但總是想望他們所購買的東西，雖然想望是會改變的。我們發現，藉由釐清他們的想望，人們可以釐清他們真正需要的，以及不需要的是什麼。

「產品」（product）這個詞，我們指的是，可以滿足一套複雜想望的產品。想望複雜的原因之一是，它們是許多人的想望的集合。當我們製作一項可滿足自己想望的產品──譬如一個花園，或一個書架──通常不需要進行明確的探索需求作業。我們只需動手做出來，檢查一下，然後修改到我們自己滿意就行。

但「人」（people）可能包括許多不同的人。發掘他們究竟是哪些人，是需求要件作業的主要部分。如果參與的人很多──而且產品巨大──逐一發掘每個人的需求，顯然是一項冗長、昂貴、高風險的工作。

「試圖」（attempt）又是什麼呢？如果我們寫一本書，不是應該對其內容相當有把握嗎？不是應該保證它行得通嗎？我們曾經用這本書提到的需求要件作業技巧，協助客戶開發多種產品──電腦軟體、電腦硬體、汽車、家具、大樓、新的消費性產品、書籍、影片、組織架構、訓練課程，以及研究計畫。迄目前為止，還沒有客戶要求退費，但我們無法保證將來會不會有客戶要求退費，因為我們不知道如何使產品的開發程序，成為一門精確的技術。

許多客戶在與我們合作之前，都希望產品開發程序是一門精確的技術。這些客戶大都是電腦軟體業者──他們一直抱有不切實際的幻想，以為產品開發是一門精確的技術。所以我們引用馮紐曼的名言，以提醒業者注意：「如果你不了解自己所說的事物，即便你遣詞用字精確，也毫無意義。」

如果人們不知道自己的想望，沒有一種開發方法──不論這方法如何精確，如何聰明，如何有效率──可以滿足他們。這就是為什麼我們必須進行需求要件作業──這樣，我們才不至於設計出人們不想要的系統。

有效性永遠優先於效率。即便你相當重視效率，希望達成高效率的開發，你也要先剔除那些沒有人想要的產品的開發案。我們也可以換個方式表達：

不值得做的事，就不值得把它做好。

這句話引出「發掘」（discover）這個最重要的詞彙。本書的目的，即是協助讀者發掘真正值得做的事。

艾森豪（Dwight Eisenhower）曾說：「計畫書不重要；訂定計畫的過程才重要。」我們同意他的看法，並延伸這句話的意義至探索需求要件的程序上：

產品不重要，重要的是過程。

或是換一個方式表達：

發現什麼不重要，重要的是發現（探索）的過程。

這句話也適當詮釋了本書的書名Exploring Requirements。

譬如，資料字典（data dictionary）是保存資料定義的方法之一。這部字典是運用本書所提到的一些方法，千辛萬苦編製而成。事實上，幾乎沒有人讀過資料字典，或沒有任何人曾在探索需求的階段運用資料字典。或許有人憂心這個現象，但我們不憂心，因為我們相信：

文件不重要，重要的是建立文件這件事。

如果你觀察工程師們開發新系統的真實狀況，你將發現，探索需求的工作事實上就是建立一個團隊，而且成員們：

1. 了解需求要件

2. （大多數都）貫徹始終參與專案

3. 知道如何使團隊有效運作

我們相信，如果其中一個條件不符合，專案就很可能失敗。當然，導致專案失敗的原因還有很多，坊間也有許多書討論如何避開地雷。本書的重點在於，進行探索需求要件的程序時，下列三項很重要但被忽略的關於人的因素：

1. 使所有團隊成員對於需求要件的了解一致

2. 使成員希望以團隊的方式進行專案

3. 使成員具備必要的技巧和工具，以團隊作業方式，有效地界定出需求要件

許多討論系統開發的書籍和文章，大都忽略這些主題，因此這本書可以用來補強你目前使用的探索需求要件程序，不論是正式或非正式的。本書大多數篇章都是獨立的，每章討論一項或數項工具或方法，可以強化你的需求要件作業。你可以從頭到尾讀一遍，也可以只讀你最需要加強的篇章。不論你用哪一種方式，本書都可以讓你更了解自己所說的事物。



第二部 起步的方式

BLT設計公司的芭芭拉、賴利和泰德，從來沒有見過長成這個樣子的會議室。它不像是間會議室，比較像一個洞穴；牆上浮雕著從蘇格拉底（Socrates）到沙根（Carl Sagan）等知名教育家的雕像。四邊牆上各掛著一張大黑板──說得更恰當一點，是四個方向各掛著一張黑板，因為圓形洞窟並沒有邊。主人之一的拜倫請他們坐下，以便開始進行會議，另外兩位主人薇瑪和約翰也坐定。

拜倫：我們聚在一起的目的，是要開發一項新產品，我稱之為「超級粉筆」。約翰將以使用者的觀點協助我們，他在綜合中學教幾何學和籃球。薇瑪擔負了雙重角色──她是州立大學的材料學教授，所以她是粉筆材料專家，也是粉筆使用者。有沒有問題？

芭芭拉：約翰，我們應該在一個粉筆盒裡，放各種顏色的超級粉筆嗎？

約翰：這個，我不知道。但我認為這樣做對幾何學的教學有點幫助。

賴利：籃球課與幾何課的需求要件不同嗎？

約翰：我不曾真正思考過這個問題。現階段我不認為有什麼不同，但讓我仔細想想。

芭芭拉：這樣很好，我們不希望草率做假設。

泰德：薇瑪，到底是大學生還是高中生比較會偷粉筆？

薇瑪：（驕傲地）我的學生不偷粉筆！

泰德：我曾經讀過資料，指粉筆含有迷幻藥成分，還有，最近大學生似乎很流行用粉筆在皮膚上彩繪。

約翰：事實上，據我了解，用粉筆彩繪的情形，比拿它當迷幻藥吸食的情形還多。我們的學生似乎很喜歡模仿澳洲土著。

泰德：我們的超級粉筆，是不是應該設計成無法用於身體彩繪？譬如，我們在粉筆裡添加一種物質，畫在皮膚上就會刺痛。

芭芭拉：會引起刺痛的東西應該上色。你認為這樣有用嗎，約翰？

約翰：我不清楚。但是，我上課的時候會刺痛我的手嗎？

拜倫：女士先生們，這是很有趣的粉筆閒聊。但我們能不能開始討論我們公司的問題？

芭芭拉、賴利、泰德齊聲說：哦，我們不是已經開始了嗎？



第5章 開始

如果你即將進行一項偉大的開發案──譬如設計一種超級粉筆──起步可能是最困難的。所有的需求要件作業(requirements work)進行之前，都會先有某種萌發程序（initiation process）：某人興起一個概念（idea），想要設計或建造某個東西。不論這個概念由何而來，這個概念即是需求要件作業程序的起點。

不幸地，由於每個人的思維方式不同，對於概念的形式與內容解讀也不同，以致可能衍生不同的起點。對於需求要件作業而言，這種現象確實麻煩。

如果我們不小心，萌發概念的形式將無效率地啟動整個需求要件作業程序，並繼續進行下去，而且無法挽救。如果參與者在開始思考時無法協調一致，那麼在你還沒有獲得他們真正參與之前，你就會失去他們。如同宣道人所說的，你必須「因材宣教」。你將他們召入帳棚，才有可能施以教化。

我們將在本章討論最通用的概念形式（idea form），以及它們引發的不同起點；並討論如何從一開始，就讓通用起點的需要以及全部參與者的需要取得平衡。

5.1 一個共通的起點

我們如何將眾多可能的起點，減約至一個穩固的平台，以釐清需求要件？可能的解決方式之一，就是將設計案視為要解決某個問題，然後將眾多起點減約至一個陳述問題的共通形式。

我們將「問題」定義為：

你的期望和你的感受之間的落差。

這個定義可以做為評估各個概念的樣板。如果某個概念不符合這個定義，我們可以和這個概念的萌發人一起努力，將概念共通化，直到符合樣板為止。

5.2 將眾多起點共通化

我們將詳細說明，共通化程序如何將以下六種不同的起點，簡約至一個陳述問題的共通形式。

5.2.1 解決方案概念

我們最常見到的起點或許是：還沒有陳述該解決的問題（也就是某人所感受到的和所期望的），就開始思考解決方案。請參考下列實例。

某業務經理告訴某系統分析師：「我們的銷售力報告，需要更鮮明的碳粉影本。」系統分析師並沒有立即去找使碳粉更鮮明的方法，而問說：「鮮明碳粉能幫你解決什麼問題？」經理解釋：目前的碳粉無法印出優質影本，業務員看報告很吃力。「所以，」分析師說：「你希望每一個業務員都有一份清晰的報告。而且，你目前將我們給你的報告，影印許多份？」經過這番問與答，問題被重新界定：業務經理的需求是，他的四百個業務員，每人都能準時獲得一份清晰的報告──這是一件非常簡單的事，只需將現有的內部網路查詢系統略做修改。這個問題的最後解決方案與鮮明碳粉無關，甚至與紙張無關。

另一個例子是，某大學校長說：「我們必須研究出一個吸引更多學生的方法。」但校長先生並沒有說為什麼需要更多學生，於是教職員們各自發揮想像力。有些人認為，「更多學生」是指更多傑出的學生。有些人認為，「更多學生」的目的是為了增加某些系所的助教職位。另有一些人認為，「更多學生」的目的是讓宿舍能住滿學生。

經過數個月討論，教職員終於明白校長真正的意圖：藉由增加申請入學人數，以降低錄取比率，使州議會對本大學嚴謹辦學印象深刻，以增加對本大學的經費補助。了解真正目的之後，教職員們提出數個辦法，但沒有一個與增加入學人數有關。

5.2.2 科技概念

有時候，我們腦袋裡並沒有任何問題，卻有一個解決方案在手──也就是說，已經存在解決方案，現在要找這個解決方案可解決的問題。你在撕去電腦報表紙兩側的洞洞條時，有沒有想過這些洞洞紙條應該有用途？洞洞紙條就是解決方案，問題則是：「我們應該如何利用它？」經過三十年研究，有一天，傑瑞（本書作者之一）買了一隻小德國牧羊犬蜜糖，突然發現這個解決方案可以解決的問題。電腦報表紙兩邊的洞洞條，最適合舖在狗窩，給狗狗當床舖。

新科技的發明，常常就是先有解決方案，再找問題。3M公司發明的便利貼，就是最顯著的例子。這個只能部分黏著的紙片，原本是開發貼紙過程中的一個失敗品。3M公司的員工並沒有將這個失敗品丟棄，而認為這個部分黏著的東東是一個解決方案，並積極尋找這個解決方案可解決的問題。於是，他們發明了便利貼──但解決方案尋找問題的程序尚未結束。每當辦公室裡出現便利貼的時候，人們就知道他們有問題得去處理了。

與我們合作的若干高科技公司，即是以先有解決方案再找問題的方式，做為開發案的起點。實際運作時，他們的問題分為兩種形式：

˙ 感受：我們擁有一種獨門科技，但他人不願意投資。譬如，拜倫的粉筆公司已發明出一種具有超級純度和強度的粉筆。但是對多數人而言，粉筆只是粉筆而已。

˙ 期望：他人願意支付我們大筆金錢，以使用這項獨門科技。譬如，拜倫可以在眾人心目中創造超級粉筆的概念，於是新粉筆的純度和強度成為一種有價值的資產。

上述兩種陳述問題的方式，使新科技成為一顆種子，得以萌發多種新產品。如果沒有陳述問題這個程序，科技公司將誤以為「新科技可以自我行銷」。雖然這個觀念有時候未必錯誤，但通常是事後諸葛型的聰明。一般而言，解決方案找到它能解決的問題，必須經過許多釐清需求要件的程序和設計工作──譬如，讓教師們相信，使用超級粉筆能使教學更有效率。

5.2.3 比喻法

許多產品的開發程序起始於各種比喻式思維方式──明喻或比較。譬如，某人說：「製造一個類似這個的東西。」雖然客戶強調「這個」，但釐清需求要件的程序則是界定「類似」的意義。

譬如，軟體設計主管莫琳告訴她的團隊，她希望設計出一個「類似小狗」的使用者介面。「首先，」她進一步說明：「人們看見小狗，立刻被它吸引，想拍拍它，和它玩。小狗可能會抓人，也可能會咬人，但是人們不怕小狗，因為小狗不會咬傷人，也不曾抓死任何人。而且，和小狗玩也不太會弄傷小狗。」

這番說明雖然不足以使她的團隊，設計出符合需求要件的介面，但引發團隊成員進一步詢問。

「是不是應該訓練小狗不隨地大小便，以及服從命令？」某團隊成員問。

莫琳想了一下，說：「這個介面應該可以被訓練，以服從你的命令。它就是你養的小狗。」

「好，」另一個成員問：「它會不會長大，還是永遠是一隻小狗？」

「這個問題容易，」莫琳說：「如果你希望它不長大，它就永遠是一隻小狗。但是，如果你喜歡，它也可以長大成一隻會做事的狗，你說什麼，它就做什麼。」

「做哪一類事情？」

「譬如警戒，有危機產生時，它會對你發出警訊。」

另一個成員也參加討論：「可不可以變成一隻牧羊犬，幫你趕羊進柵欄，而且擔任守衛，防止任何人來偷羊。」

討論熱烈進行，團隊成員個個像敏捷的獵犬，進行釐清需求要件程序，雖然追逐的路線不必然是直線。某人問：「它的皮毛是什麼樣子？長毛還是短毛？」沒有人理解這個問題的真正意義，但他們仍然據此討論觸控式螢幕，以及之前未使用過的各種硬體介面。最後，毛皮問題被暫時擱置，因為某人說：「我們的狗尾巴已經開始搖來搖去了。」

比喻法是很好的激發概念工具，但團隊成員最後必須將眾多概念進行篩選，也就是說，我們需要可以刪減概念的工具。比喻法有時就像狗耳朵一樣靈敏，能激發眾多概念。但我們寧可讓比喻法的運作略微超過合理界限，以確保能萌發足夠的概念。

5.2.4 基準法

許多人認為自己不是很擅長運用比喻法，而是以較具體的方式進行思考。在釐清需求要件的程序中，他們會說：「這是一張椅子。請設計一張更好的椅子。」或「這是普通粉筆，請設計超級粉筆。」事實上，基準（norm）也是一種比喻，而且所期望的產品實質上「接近」基準品。運用基準法的最大危險是：一旦我們確認顧客期望的是何種產品，設計者的思維就會受限制。

另一個危險是，思維邏輯一下子就跳到最後結論。為了避免這種危險，我們應該由基準起步，一點一滴前進，以免犯重大錯誤。譬如，萊特（Wright）兄弟原本的專業是製造腳踏車，他們運用製造腳踏車的諸多基準，終於成功製造出貓鷹飛機（kitty Hawk）。

第三個危險為根據錯誤的基準開始作業，以致我們無法跨出最關鍵的一步。萊特兄弟曾經利用軌道來推進他們的飛機，但他們不曾在火車頭裝翅膀，想讓它飛起來（參考圖5-2）。

5.2.5 模型法

如果我們決定以一張椅子做為基準，但是，你腦海中呈現的椅子，與我腦海中呈現的椅子，極可能迥然不同。模型法（mockup），即製造實體模型，可以避免這種語意曖昧。而且，模型可以在產品實際產製之前，用來進行說明、研究以及測試。

不論我們已經有基準或沒有基準，模型都可以當成基準。因此，模型法具有基準法的各項優點和缺點。模型也具有幻想式產品的各項優點和缺點。製作模型並不受既有實物的限制，因此我們製作的模型可能無法產製為實品。

模型可用圖形方式，在紙張上或電腦螢幕上顯示。客戶和使用者可以指著模型圖說：「對，這就是我要的東西。」或「不對，這是什麼東東？」事實上，模型是用來測試客戶的反應──即偵知客戶的期望。模型彷彿代設計者發言：「我們認為產品應該長成這個樣子，讓我們看看你作何反應。」

5.2.6 名稱法

許多設計案的概念起始於一個名稱：製造超級粉筆、一張桌子、一張椅子、一枝鉛筆、一個時鐘、一部電梯、一個駕駛方向盤、一個計速表，或一輛腳踏車。給予名稱固然可以使設計者迅速掌握重點，卻也有引發不相干聯想的風險。如我們先前所說明，一個詞彙能引發千種圖像，一個名稱的各種聯想也可能引發各種內在假設。

譬如，傑瑞花了三十年研究電腦報表紙側條的用途，即是受限於它的名稱。我們的同事吉姆‧衛瑟發現，他的四歲女兒絲毫不受名稱的限制。她將電腦報表紙側邊的洞洞條減成小片，稱它們為「車票」。我們應該向這個四歲小女孩學習，能夠不受既有名稱的限制，為新產品命名。

5.3 存在之假設

我們討論設計案的共通起點，迄今為止有什麼收穫？我們已探討解決方案概念、科技概念、比喻法、基準法、模型法以及名稱法，似乎離主題愈來愈遠。但回頭檢視這些不同的起點，我們發現它們都有一個共同點──假設解決方案存在。

進行一項開發案，最基本的假設為，我們設計的產品目前雖然不存在，但必然將存在。所以，這些相異的起點有何共同之處？它們都是某項成功商品將會成真的各種方式。任何一個設計者，必先假設至少有一個解決方案存在，才可能動手進行設計。

再重複一次。我們定義共通的起點為（圖5-3）：

所有的開發案皆起始於，假設對某問題的解決方案存在。

其他的需求要件作業，則可以視為釐清這項假設的工作。我們將在後續章節，介紹一系列以「可能成真」──即假設存在──為起點的工具和技巧，然後一次釐清一個假設，終於達臻「成真」──即真正存在。

前言

產品開發的工作就是：將某人的想望（desires），轉化為能夠滿足這個想望的產品的過程。本書要討論的是需求要件作業程序（requirements process）──也就是開發過程中，人們試圖發掘什麼是人們想要的（people attempt to discover what is desired）的過程。

為了了解這個程序，讀者們必須注意五個關鍵詞：想望、產品、人、試圖、發掘。

首先，考量「想望」（desire）這個詞。有些讀者比較喜歡說成「試圖發掘什麼是人們需要的（needed）」。但是相對於人們想要的，我們更不知道如何找出人們的需要。此外，人們並非總是購買他們需要...

致台灣讀者 傑拉爾德‧溫伯格

最近，我很榮幸地得知，台灣的經濟新潮社要引進出版拙著的一系列中譯本。身為作者，知道自己的作品將要結識成千上萬的軟體工程師、經理人、測試人員、諮詢顧問，以及其他相信技術能為我們帶來更美好的新世界的人們，我感到非常驚喜。我特別高興我的書能在台灣出版，因為我有個外甥是一位中文學者，他曾旅居台灣，並告訴過我他的許多台灣經驗。

在我早期的職業生涯中，我寫過許多電腦和軟體方面的技術性書籍；但是，隨著經驗的增長，我發現，如果我們在技術應用和建構之時對於其人文面向沒有給予足夠的重視，技術就會變得毫無價值－－甚至是危險的。於是，我決定在我的作品中加入人文領域的內容，並希望讀者能注意到這個領域。

在這之後，我出版的第一本書是《程式設計的心理學》（The Psychology of Computer Programming）。這是一本研究軟體開發、測試和維護當中關於人的過程。該書現在已經是25週年紀念版了，這充分說明人們對於理解其工作中人文部分的渴求。

各國引進翻譯我的一系列作品，讓我有機會將這些選集當作是一個整體來思考，並發現其中一些共通的主題。自我有記憶開始，我就對於「人們如何思考」產生了濃厚的興趣；當我還很年輕時，全世界僅有的幾台電腦常常被人稱為「巨型大腦」（giant brains）。我當時就想，如果我搞清楚這些巨型大腦的「思考方式」，我或許就可以更深入地瞭解人們是如何思考的。這就是我為什麼一開始先成為一個電腦程式設計師，而後又與電腦共處了50年；我學到了許多關於人們如何思考的知識，但是目前所知的還遠遠不夠。

我對於思考的興趣都呈現在我的書裡，而在以下三本特別明顯：《系統化思考入門》（An Introduction to General Systems Thinking，這本書已是25週年紀念版了）；它的姊妹作《系統設計的一般原理》（General Principles of Systems Design，這本書是與我太太Dani合著的，她是一位人類學家）；還有一本就是《你想通了嗎？》（Are Your Lights On?: How to Figure Out What the Problem Really Is，這本書是與Donald Gause合著的）；一本《從需求到設計》（Exploring Requirements: Quality Before Design，也是和Donald Gause合著，談的是人們如何去思考他們在系統中的價值）。

我對於思考的興趣，很自然地延伸到如何去幫助別人清晰思考的方法上，於是我又寫了其他三本書：《顧問成功的祕密》（The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully）；《More Secrets of Consulting: The Consultant’s Tool Kit》；《The Handbook of Walkthroughs, Inspections, and Technical Reviews: Evaluating Programs, Projects, and Products》（這本書已是第三版了）。就在不久前，我寫了《溫伯格談寫作》（Weinberg on Writing: The Fieldstone Method）一書，幫助人們如何更清楚地傳達想法給別人。

隨著年齡的增長，我逐漸意識到清晰的思考並不是獲得技術成功的唯一要件。就算是思維最清楚的人，也還是需要一些道德和情感方面的領導能力，因此我寫了《領導者，該想什麼？》（Becoming a Technical Leader: An Organic Problem-Solving Approach）；隨後我又出版了四卷《溫伯格的軟體管理學》（Quality Software Management），其內容涵蓋了系統化思考（Systems Thinking）、第一級評量（First-Order Measurement）、全面關照的管理作為（Congruent Action）和擁抱變革（Anticipating Change），所有這些都是技術性專案獲得成功的關鍵。還有，我開始寫作一系列小說（第一本是《The Aremac Project》）是關於專案及其成員如何處理他們碰到的問題──根據我半個世紀的專案實務經驗所衍生出來的虛構故事。

在與各譯者的合作過程中，透過他們不同的文化視野來審視我的作品，我的思考和寫作功力都提升不少。我最希望的就是這些譯作同樣也能幫助你們──我的讀者朋友──讓你的專案、甚至你的整個人生更成功。最後，感謝你們的閱讀。

致台灣讀者 傑拉爾德‧溫伯格

最近，我很榮幸地得知，台灣的經濟新潮社要引進出版拙著的一系列中譯本。身為作者，知道自己的作品將要結識成千上萬的軟體工程師、經理人、測試人員、諮詢顧問，以及其他相信技術能為我們帶來更美好的新世界的人們，我感到非常驚喜。我特別高興我的書能在台灣出版，因為我有個外甥是一位中文學者，他曾旅居台灣，並告訴過我他的許多台灣經驗。

在我早期的職業生涯中，我寫過許多電腦和軟體方面的技術性書籍；但是，隨著經驗的增長，我發現，如果我們在技術應用和建構之時對於其人文面向沒有給予足夠的重視，...

致台灣讀者／溫伯格
推薦序 從需求到設計，解析消費者的需求／陳禧冠
前言

第一部　先有一點共識

第一章　光有方法，還不夠
第二章　需求要件語意曖昧
第三章　語意曖昧的原因
第四章　直接詢問法的侷限

第二部　起步的方式

第五章　開始
第六章 開放式問題
第七章 找到對的人參與
第八章　有效率的會議
第九章 努力減少語意曖昧

第三部 探索各種可能性

第十章　激發概念的會議
第十一章 運用右腦
第十二章　專案的名稱
第十三章　調和衝突

第四部　釐清客戶的期望

第十四章　功能
第十五章 特性
第十六章　限制
第十七章　偏好
第十八章　期望

第五部　大幅提升成功機率

第十九章　判斷語意曖昧的基準
第二十章　技術審查
第二十一章 測試滿意度
第二十二章　測試案例
第二十三章 研究現有產品
第二十四章　意見合致
第二十五章　結束

參考書目
致謝

致台灣讀者／溫伯格
推薦序 從需求到設計，解析消費者的需求／陳禧冠
前言

第一部　先有一點共識

第一章　光有方法，還不夠
第二章　需求要件語意曖昧
第三章　語意曖昧的原因
第四章　直接詢問法的侷限

第二部　起步的方式

第五章　開始
第六章 開放式問題
第七章 找到對的人參與
第八章　有效率的會議
第九章 努力減少語意曖昧

第三部 探索各種可能性

第十章　激發概念的會議
第十一章 運用右腦
第十二章　專案的名稱
第十三章　調和衝突

第四部　釐清客戶的期望

第十四章　功能
第十五章 特性...