chap03a -...

需求

「開發軟體系統最困難的一個部份，就是準確地決定要開發什麼。」1

── Frederick Brooks, 《人月神話》（The Mythical Man-Month）

美國專利商標局

圖 3.1：愛迪生在 1980 年申請了燈泡的專利，但這項發明目前仍然持續在改良。

3商業分析師產品經理使用者經驗

50 | 軟體工程與 Microsoft Visual Studio Team System

上一章討論的是如何選擇軟體開發流程，以及有哪些環境因素會左右你的選

擇。不論你選擇了哪一種開發流程，一開始的工作必然是規劃專案的遠景

（vision）。通常這項工作是由商業分析師或產品經理來主導，如果是 XP（eXtreme

Programming，極致編程），則是由駐點的客戶（onsite customer）來主導。很明

顯的，在專案開始進行之前，你就必須先定義你的產品（它要解決什麼問題）。

因為除非你知道你要做什麼，否則你不可能獲得資金、招募新成員、也不會知道

接下來該做什麼。

遠景聲明、人物代表、情節、與服務品質需求在 VSTS 中，遠景聲明（vision statement）與人物代表（personas）是編寫在文

件裡，你可以利用 Team 總管（Team Explorer）和專案入口網站存取這些文件。

情節（scenarios）和服務品質（quality of services，QoS）則是工作項目，它們

跟其他存在工作項目資料庫中的工作項目一樣可以追蹤跟維護。

在規劃遠景方面，MSF for Agile Software Development 和 MSF for CMMI Process

Improvement 兩者並沒有太大的差異，比較不一樣的地方是它們對於工作項目型

態的定義。

MSF 把需求定義為「情節」和「服務品質」，VSTS 則使用特定的工作項目

類型來捕捉和追蹤這些需求，以便將它們分類成一般的工作項目，並且顯示在專

案工作清單（backlog）裡面。你會從專案開發過程的每一次反覆當中不斷的學習

並修改這些需求，使它們更加精確、詳細。由於這些需求都是工作項目，因此當

你修改它們的時候，所有的修改動作都有完整的記錄與稽核，而且這些變更記錄

會直接流向度量資訊倉儲。

你的遠景是什麼？每個專案都應該有一個讓所有利害關係人都能了解的遠景。通常遠景聲明就

是專案獲得資金挹注的第一步，即使不是，遠景也有助於釐清整個專案的核心

價值。

第 3 章需求 | 51

遠景聲明應該愈短愈好。它可以是一個長句、一個段落、或者更長，只要能

達到目的就行了。遠景是寫給使用者看的，應該以使用者看得懂的文字來撰寫。

成功的遠景聲明有個特徵，就是每個專案團隊的成員都很容易將它記在腦海裡，

並且跟每天的工作內容連結起來。

策略型專案

專案可以分成策略型（strategic）專案和調適型（adaptive）專案。策略型專

案代表的是具有重大改善計畫的大型投資。例如，新公司成立時都有很多新的產

品構想，或者當某個企業要成立一個新的事業單位時，通常都會有一個很清楚的

策略遠景。

有一種方法可以幫助你思考像這樣的一個策略專案有何關鍵價值（即遠景聲

明），這種方法稱為「電梯行銷」（elevator pitch）2。之所以稱為電梯行銷，是

因為它可以讓你在搭電梯的短暫時間內，把你的想法跟你未來的客戶或投資人說

明完畢。它的優點在於能夠準確抓到遠景的重點，內容精簡到足以讓你的客戶或

投資人在短暫的會面當中記住你說了什麼。Geoffrey Moore 為電梯行銷發明了一

張簡單的表格，如表 3.1 所示。

表 3.1：電梯行銷

針對（市場區隔範圍內的目標客戶）

他們所不滿意的是（目前市場上的替代方案）

我們的解決方案是（新的產品型錄）

它提供了（解決問題的關鍵能力）

不同於（產品的替代方案）

我們整合了（關鍵的情節和服務品質）

調適型專案

相對的，大部份的 IT 專案都是屬於調適型專案，它是以漸近的方式來改變既

有的軟體系統。從企業流程變更的角度來描述遠景通常會比較容易，也比較恰當。

在這種情況下，如果已經有企業流程的模型或說明文件，那麼它們也許就是最佳


的起始點。你可以把大家共同提出的遠景當作主要的方案，而把原本的企業流程

模型當作參考的替代方案。

企業流程模型在目前的 MSF 流程範本中，已經有遠景聲明、情節、以及服務品質的工作產品，

可是並沒有定義企業流程塑模（business process modeling）的活動。如果你需

要定義企業流程模型，VSTS 裡面有附一套微軟的 Visio，它有內建的模板可以用來

畫企業流程圖。

何時要撰寫詳細的需求分析癱瘓（analysis paralysis）是專案延誤時最常聽到的責難。這些抱怨所反

映出來的現象，是分析人員因為力求完美或過度仔細，花了太多時間想要把需求

一次寫完整，因而造成了後續工作的延宕。這在確立遠景時會是一個很大的風險。

要解決這個風險，你得將這兩個因素謹記在心：需求的有效期間（shelf life）以

及它們的讀者。

需求是很容易過期的

思維模式認為需求的有效期間是很有限的，此真知灼見乃基於下列四個理由：

商業環境或問題空間（problem space）會改變。你在撰寫需求時所根據

的假設，都可能因為競爭者、管理者、客戶、使用者、科技、和管理的改

變而被否定掉。如果你花太多時間在定義完美的需求，到頭來你會發現，

外在因素的改變將迫使你重新定義需求。

需求背後的知識會過時。分析師或團隊在捕捉需求時，與需求有關的知識

正達到它的顛峰。接著就會進行後續的過程，例如：討論它們的意義、探

索它們隱含的意思、以及了解彼此的差異。這當中所捕捉到的資訊可能會

記錄在文件裡面，以便讓雙方簽字確認。但是最重要的還是最終的實作成

品。你在需求定義的文件裡寫愈多跟實作細節有關的東西，就表示你愈不

允許裡面的知識過時（譯註：若需求裡面寫太多實作細節，到時候若客戶要

求修改不合時宜的地方，開發團隊可能就會以當初雙方都有白紙黑字簽名為

由，拒絕修改需求。換句話說，拒絕需求文件裡的知識過時）。

第 3 章需求 | 53

心理因素會限制團隊一次能考慮到的詳細需求的數量。需求的量愈少，你

就愈能專注在提升設計和實作的品質上面。相反地，在一次反覆

（iteration）當中將需求範圍擴張得愈大，混亂和粗心的狀況也可能更加

嚴重。

這次反覆的需求實作會影響下次反覆的需求細部設計。設計是不會憑空

出現的，你從某一次反覆當中學到的經驗可以幫助你完成下一次反覆的

設計。

在接下來關於捕捉需求的討論當中，我冒著可能鼓勵你分析過度的風險，但

請注意，那不是我的本意。我主張的是，一開始先做粗略的思考跟理解，只要足

以訂出需求的優先順序並將它們排入反覆週期的工作計畫當中就夠了，詳細的需

求和設計就能接著繼續進行。

誰在乎需求

對大部份的專案來說，需求最要緊的就是要讓團隊成員和利害關係人都能理

解。在一個成功的專案裡，他們對需求必定都有一致的理解；而在失敗的專案裡，

他們對需求則有不同的解讀和期望（見圖 3.2）。

要把需求描述得既精確又容易理解是很困難的。就像圖 3.2 所描繪的那樣，

最精確的需求不見得是最容易理解的。比如說，一道數學公式或者一個可執行的

單元測試都很精確，但卻可能比不上一張普通的圖片加上一點說明文字來得容易

理解。

你應該以不同層次的精細度（granularity）來思考需求。在某些情況下，例

如進行廣泛議題的討論、排定優先順序、以及粗略估算成本等，你需要的是比較

粗略的、容易理解的需求。相對的，如果要在目前的反覆階段中將需求實作出來，

此時你就需要更詳細的需求規格。如果你有實踐測試驅動開發（ test-driven

development，見第 6 章，「開發」）的話，最詳細的需求定義其實就是可執行的

測試。


Dean Leffingwell and Don Widrig, Managing Software Requirements (Boston, MA:

Addison-Wesley, 2000), 273

圖 3.2：X軸是需求文件的模糊程度（精確的反面）；Y軸則是可理解的程度。

圖 3.2 中的甜蜜點（sweet spot）在不同領域有不同的意思。在高爾夫球的術語裡面，打中桿頭的甜蜜點就會讓球飛得特別遠。而這裡的甜蜜點，則是模糊程度

與可理解程度的平衡點，也是最理想的點。當模糊程度超過了甜蜜點，可理解的

程度就不再往上增加了，而是跟著下降。換句話說，需求文件的精確度太高或太

低都不好，應找出理想的平衡點，讓需求文件剛剛好夠精確，又容易理解。

不妨想一下你的需求文件的讀者。他們對於你在撰寫需求文件時的廣度和精

確度有很大的影響。如果你的開發方法是比較極端的極致編程（ eXtreme

Programming），你可能會有一個小型團隊和一名駐點客戶（onsite customer），

而需求是寫在一章 3x5 的卡片上，也許上面只寫了工作項目的大標題，然後就放

著繼續處理其他工作，直到需要實作時才回來檢視這些卡片。當你需要處理某個

需求時，會在實作之前先跟你的客戶開會討論這個需求，並且在這個會議當中撰

寫測試來驗證這個需求。3

如果是另一種極端（譯註：例如 CMMI），你的需求規格可能會受限於管理、

稽核或招標的相關規定。結果是你會希望所有的細節都說明清楚，好讓後續的需

求變更可以單獨計費並且提出需求異動的申請。4

第 3 章需求 | 55

MSF 在這方面的建議是，每次只為一個反覆週期規劃及撰寫詳細的需求。這

樣的話，實際上每個反覆就是一批逐漸實作完成的需求。對大部分的專案來說，

這種作法比較中庸，它允許充分的溝通、持續更新需求、避免做白工、並且讓你

把心力集中在交付顧客價值上面。

人物代表與情節增值思維模式是以交付給客戶的價值來測量軟體品質。如果你沒有現場駐點

的客戶，或者無法用一個人來代表所有的客戶，這時候人物代表（personas）和

情節就是你用來理解和溝通客戶價值的最佳工具。

從人物代表開始

欲了解專案的目標，你得先知道以後使用這個軟體系統的使用者是誰。從可

識別的、實際的、感興趣的人物代表開始。在目前的易用性工程（ usability

engineering）文獻中，「人物代表」這個術語已經非常普遍了，但是在它普及之

前，市場行銷的相關研究已經把它拿來當作定義產品的方法了。以下是 Moore 對

人物代表的描述：

……市場區隔最容易出問題的時候，就是一開始只把目光放在目標市場或目

標區隔上，而不是真正的客戶……我們需要的是更貼近群眾的東西……然

後，一旦我們的腦袋裡出現他們的影像，就可以讓他們指引我們開發出他們

所需要的產品。5

人物代表是實際執行情節的目標使用者。對那些已經識別出目標使用者的專

案，你可以用「人物代表」來指稱那些真實的使用者。對於具有廣大市場的產品，

你的人物代表可能會是個虛構的角色，所以他永遠不會告訴你他的個人想法，你

得發揮你的想像力才行（注意還有其它的利害關係人，例如使用者的老闆，這個

專案他可能也有出錢，但他並不能算是目標使用者）。Allen Cooper 曾經說明好

的人物代表應該具有什麼特性：

人物代表就是能夠代表特定對象的使用者模型。它們並不是真實的人，只是

把從人身上觀察到的印象加以合成的結果。以人物代表作為使用者模型之所

以這麼成功，其關鍵因素在於它們非常貼近真實的人物（Constantine 與

Lockwood, 2000）。它們代表的是特定的個體。這種方法不僅適當，而且有


效，因為把人物代表當作使用者模型有它獨特的地方：它們讓開發小組設身

處地從目標使用者的角度來設計軟體。同理心對設計師來說是很重要的，因

為這樣他們在決定設計框架以及相關的細節時，才能同時考慮到使用者的認

知和情感兩方面的因素。這就是人物代表所要達成的目標。6

好的人物代表不容易忘記、有真實感、而且描述得很清楚。如果你在拍一部

電影，人物代表就等於是你交給角色經紀人（casting agent）的人物側寫。它們不

只從職稱、功能的角度，同時也從人物的性格、工作或環境、教育、電腦相關的

經驗、以及其他特性來描述使用者，讓憑空想像的人物變成跟真的一樣。為了更

容易記住它們，你可以為每個人物代表指定一個名字和一張圖片。微軟有些開發

小組會把海報掛在牆上，並且大量分送名條磁鐵（fridge magnets）來強化大家對

人物代表的的印象。7

人物代表也可以用來描述系統要應付的敵人。例如，如果考慮到安全性的問

題，你可以能會想要描寫嘗試入侵系統的駭客。隨機尋找被害者並嘗試將其網站

掛掉的破壞者，跟暗中竊取帳號密碼的小偷是不一樣的。如果有定義那些討厭的

人物代表，每個人就會了解他們所牽涉的負面情節（anti-scenarios）── 也就知

道應該要盡量避免哪些問題。

情節

MSF 的「情節」（scenarios）是功能需求的基本形式。而 MSF 對「情節」

這兩個字的解釋，就是某個使用者（或一群協同合作的使用者，以人物代表來表

示）為了達到某個目標所執行的單一互動路徑（interaction path）。其中最關鍵的

是目標，你必須以使用者熟悉的語言來陳述目標，例如：下訂單。當你的產品逐

漸成形時，你的情節也將會漸漸發展成具有樣本資料的一些執行步驟，但是情節

的目標應維持不變。

使用情節來定義你的產品有許多好處：

情節是以客戶的語言以及可驗證的形式來表達有形的客戶價值。特別有用

的是類似這種型式的問題：「如果你能達成像〔這個情節〕的目標，對你

會有什麼影響？」你可以在以下場合提出這類問題：焦點團體（ focus

groups）、客戶會議、以及易用性的實驗等。當產品逐漸成形時，情節

自然就會衍生出雛形和可執行的功能。

第 3 章需求 | 57

焦點團體（focus group）這個名詞常用在市場調查，它是被市場調查者挑選出來接受抽樣的最具代表性的一群人，目的在瞭解他們對某一商品或某一特定議題的

意見、看法。這裡指的是針對某個特定的問題或需求，向一群具有代表性的使用者

進行資料蒐集和小團體訪談。稍後會有進一步的說明。

情節能讓團隊規劃和測量客戶的價值流。它可以用來測量專案的進度，並

且提供開發團隊一個用來切割功能範圍的基本單位。

情節能夠結合小型和大型團隊。所有利害關係人對情節都有同樣的理解，

若其中有任何差異，都能很容易將它突顯出來，並且能夠消除偏見，在討

論需求的時候也會比較實際。

重點是要以使用者的語言、背景來陳述目標。目標 ── 例如下訂單或退貨 ─

─ 決定了情節的內容，即使完成該目標的詳細步驟可能會改變，但目標依然不變。

就算你對解決問題的專業領域比對客戶的問題還要熟悉，或者就算你對某些使用

者的瞭解程度不如其他使用者，你還是應該盡量用使用者聽得懂的語言。Alan

Cooper 也曾說過：

目標跟任務（tasks）是不同的。目標描述的是結束的狀態，而任務則是達成目

標的過程中所採取的步驟。目標使人有動機去執行任務……目標是由人類動機

（human motivation）所驅使，它會隨著時間一點一滴，非常緩慢地改變。8

關於人類動機（human motivation），讀者可參考心理學家馬斯洛（A. H. Maslow）提出的人類動機論（A Theory of Human Motivation）。馬斯洛把人的需要依其發生順序或優勢先後，分成五個階層：(1)生理的需要（physiological needs），

(2)安全的需要（safety needs），(3)愛的需要（love needs），(4)敬的需要（esteen needs），(5)自我實現的需要（need for self-actualization）。

有時候，目標主要是用來解決「痛處」（pain points），也就是使用者目前

碰到的問題，以及新的解決方案試圖解決的問題。如果真是這樣，你在設定目標

時就應該以解決痛處為首要考量。至於其它情況，目標應該是要找出能夠振奮人

心的東西 ── 你應該把它們記下來，這樣以後你就可以檢驗情節到底帶給客戶多

少快樂。

研究技術

我們透過觀察目標使用者來找出人物代表，而且盡量在他們自己的環境當中

觀察。有許多技巧可以運用 ── 兩種比較常用的方法是焦點團體（focus groups）


和情境調查（contextual inquiries）。這些技巧都有個共同的重點，就是要選擇具

代表性的使用者。一個基本原則是，不要讓你的想法被新手或老經驗的使用者弄

得搖擺不定，而應該選擇占多數比例的「中間選民」。9

焦點團體基本上就是跟一群仔細挑選出來的訪談對象進行面對面的討論，並

且有一位受過訓練的指導員從旁協助。比較專業的焦點團體訪談法通常是封閉式

的會談，而且會有一些觀察員隱身於單面鏡（one-way mirror）的背後（或者在另

一個房間用監視器觀察）。開放式焦點團體訪談當然也可以，此時觀察員就坐在

會議室的後面，但他並不打岔，只是靜靜的坐在那裡觀看訪談的過程。

焦點團體很管用 ── 這點無庸置疑 ── 尤其是當你正在廣泛地蒐集問題的

時候。此時你必須非常小心分辨使用者所說的跟他所做的是否一致。有些小地方

會讓這兩者的區別顯得非常重要，例如：一廂情願的想法、滿口專業術語、想展

現自己的能力好讓你大感佩服、以及沒有自知之明……，諸如此類的。

人在描述自己（或他的同僚）的行為時，通常跟局外人所觀察到的結果不一

樣。情境調查就是用來解決這個問題的方法。其做法是直接在使用者的工作環境

中觀察他們每天的工作情形。10

情境調查這個技術是從人類學那邊借過來的。觀察員除了觀看，偶爾也會提

出新聞記者常問的開放式問題（誰、做了什麼、什麼時候、為什麼要做、如何做），

他不會以自己的觀點去影響使用者，也不提供解決方案。了解痛處和機會在哪裡

是很重要的 ── 也就是那些讓使用者很懊惱的地方、可以改善的地方、以及對使

用者產生重大影響的東西。如果可能的話，盡量蒐集相關的文件和工作產品，並

且為使用者的環境拍些照片，特別是那些貼在牆上的東西。

我最喜歡用一個小故事來說明自我陳述（self-reporting）的問題，這個故事

發生在 2003 年，當微軟嘗試定義 Visual Studio Team System 的需求時，對某一

家銀行所做的訪談。在某個早晨舉辦的開放式焦點團體會議中，微軟團隊詢問他

們開發軟體的一些實務作法，其中特別問到了有沒有實施單元測試。他們說單元

測試對這家銀行的所有開發人員來說根本就是家常便飯，而且每次簽入（check-in）

程式碼之前，都一定會先進行單元測試。

到了下午，微軟有一位負責軟體易用性的工程師就實地觀察了他們其中一位

開發人員的工作情形（這也是它稱為情境訪談的原因）。這名開發人員寫了一些

程式，這當中也執行了幾次簽入程式碼的動作。幾個小時之後，易用性工程師問

第 3 章需求 | 59

道：「我看你做了好幾次簽入動作，可是你有做單元測試嗎？」「當然有啊！」

他立刻回答：「我在每次簽入之前都有按 F5 ── 這個動作就是單元測試啦。」（如

果你沒用過 Visual Studio 的話，F5 就是編譯的快速鍵，跟測試一點關係也沒有。）

之前他們自己陳述的單元測試實務根本就從沒發生過。在設計 VSTS 的時候，我

們把這種誤解的現象視為一個機會，我們要把單元測試功能做到像這家銀行的開

發人員所認為的那樣簡單、好用（見第 6 章「開發」）。

一個使用者不足以成為人物代表，你必須重複地觀察，直到你覺得已經有很清

楚的行為模式可以讓你將其中最重要的部份萃取出來，放到人物代表的描述裡面。

儘早明確

當你已經把人物代表都定義好，就可以開始撰寫這些人物代表的情節了。情

節這個名詞最早也是出現在市場研究領域，這裡再引述 Geoffrey Moore 的話：

「描繪情節的特性」並非正式的市場區隔調查 ── 那太花時間了，而且產生

的結果也太枯燥。相反的，它是比較沒那麼正式的故事（anecdotes），但是

卻蘊含了企業知識在其中。情節跟故事很像，多少會有一點虛構、謬誤、以

及成見之類的。不過，它們仍然是目前進行市場區隔時最好用也最精確的

資料。11

先從情節的目標開始，然後把它切成幾個小步驟。至於步驟要切得多細，就

看它是不是夠清楚，只要細分到最清楚、最容易理解的程度就行了。在列出所有步

驟時，應使用動詞來描述，並且以使用者的語言來撰寫情節，不要用你熟悉的實作

語言。換句話說，情節所要描述的應該是問題空間，而非解法空間（solution space）。

不要一開始就想要把情節的替代路徑（alternate path）或例外路徑（exception

path）寫得非常詳盡 ── 那樣通常會讓文件難以閱讀，而且很快就會複雜到難以

掌控的地步 ── 只要先把它們用別的情節名稱來表示就行了，等到以後的反覆階

段再來處理它們。

當你覺得這些步驟已經寫好了，就可以再加上第二個部份了，也就是你的產

品將會如何回應（顯示什麼結果）。現在你已經有一個「人物代表－執行－步驟」

和「產品－顯示－結果」這種型式的清單了。接著請把那些會讓使用者驚喜到喊

出「哇！」一聲的步驟明白標示出來（這些就是所謂的「興奮因子」（exciters），

稍後會再提到它）。


圖 3.3的情節描述當中提到了「組建驗證測試」（Build Verification Tests，簡稱

BVTs），這個術語在第 6章會有進一步的說明。順便一提，微軟的官方文件在翻譯“build”時是「建置」和「組建」兩種混著用。因此，筆者在翻譯“build”時也會交替使用者兩個詞彙，原則上，名詞的場合多數譯為「組建」，動詞的場合

則一律譯為「建置」。

故事板

雖然情節是以目標做為起點，然後逐漸形成一些步驟的清單，但不是這樣就

結束了。當你覺得這些步驟和他們的順序已經能夠充分展現你所要傳達的經驗或

想法，接著就是要詳細描述它們的頁面框架（wireframes）、故事板（storyboard）、

雛型、以及開發的反覆週期。雖然每個情節的目標應維持不變，但細節和步驟可

能會在每次的反覆週期中不斷演進和修改。

Wireframe 或譯為「線框」，原本是圖形處理的術語，它是一些由頂點和線段所構成的立體模型。這裡則是有圖式結構（ schematics）、頁面架構（ page architecture）、和使用者介面藍圖（blueprint）的意思。講白一點，其實它就像我們平常開發專案時，在初期用 Visio、Word、或其他工具畫出來的概略使用者操作畫面，其用途在於讓設計人員和使用者都能透過這些圖形預想未來使用軟體

的實際情形。

圖 3.3：當我們在開發 VSTS時，我們使用較高層次的情節

來展現產品的範疇，而這張圖

就是初期階段的範例。之後，

這張圖中的每一行敘述都會

成為工作項目，並且記錄於工

作項目資料庫中，我們就利用

這些項目清單當做執行和測

試的依據。

第 3 章需求 | 61

頁面框架和故事板經常用來展示和說明系統與使用者互動的情形，尤其是當

你的設計有很多資料和狀態要展現時，它們會是很有用的溝通工具。微軟的 Visio

就有提供一個用來畫使用者介面的頁面框架模板。你可以為每項工作畫一個頁面

框架圖，並且賦予一個標題，而標題就是用前面提過的「人物代表－執行－步驟」

的型式來命名。把這些頁面框架圖串起來，並注意它們之間的順序和資料的流動

情形，這樣你就得到一個故事板了。然後你可以用複製－貼上的方式把 Visio 中

的圖形貼到 PowerPoint 文件裡，以便向使用者展示說明。如果你想要把故事板散

佈給其他人，你可以利用 Producer for PowerPoint 或 LiveMeeting 錄製的方式將

故事板製作成電影檔。

圖 3.4：這是 VSTS 初期情節中的一個非常早期的 Visio 頁面框架。並非所有畫出來的視窗都會實作，而有實作出來的視窗也未必會先畫在頁面框架裡。在達到使用者希

望的目標之前，至少必須經過三次易用性測試和後續改版動作的循環。

情節的廣度

有一種很好用的技巧，就是以起點到終點（end-to-end）的方式來思考你的軟

體系統所要描述的故事，然後將這些故事的情節按順序排列。故事應該要從你部


署軟體的那名使用者開始，然後經過所有實現軟體價值的使用者。不管是開發內

部的系統、客製化的專案、還是套裝軟體，這個技巧都同樣管用。

如果你採用這個方法，那麼你會碰到兩個問題：可發現性（discoverability）

── 第一次使用這個軟體的人是否能夠很快找到他需要的功能 ── 和縱深的

（longitudinal）問題──進階的使用者如何能利用這套軟體提高生產力。

此外，要寫多少情節才算足夠？通常你至少要有足夠的情節可以描述系統的

主要流程，但是又不能多到記不住。

你的情節應該要足以涵蓋產品的所有起點到終點的流程，這當中不能有任何

遺漏或重覆的地方。這表示你的情節可能需要先拆解成一些中等規模的活動

（activities），然後在各個活動裡面撰寫詳細的步驟。

如果你正在撰寫多人互動的情節，那麼你可以為它畫一張流程圖，裡面有泳

道（swimlane）可以顯示某某人在誰之前做了什麼動作。

泳道（swimlane）是流程圖或 UML 活動圖中的一塊長條區域，每一條泳道代表某個角色的責任範圍（例如圖 3.5中的 architect和 developer）。也就是說，所有落在某個泳道的活動，就是由該泳道所屬的角色來負責執行。

圖 3.5：這份 PowerPoint簡報描述的是起點到終點的故事情節，而這張投影片則是 VSTS的某個情節的定義。

第 3 章需求 | 63

客戶驗證

情節和反覆式開發的主要優點，就是你給了客戶很多機會檢視你的產品，他

們可以在設計的過程中及早發現問題並修正你的方向，讓你少做一點虛工。審核

過程依各企業環境而有所不同，你可能只想要三種審核角色。首先，使用者（或

他們的代表）必須確認你提供的產品能讓他們有效率的達成目標。其次是掌握資

金者（economic buyers），有時候就是使用者的老闆，或稱為企業決策制定者，

他們希望看到的是你的產品能為他們的公司增加利潤。最後是技術評估者

（technical evaluators），他們會檢查你的產品是否有依照規定的架構來實作，並

符合原先要求的條件和規範。這些角色有時候是重疊的，但通常不是。情節可以

讓這三種角色方便討論專案的進度。

在專案初期，驗證的動作可以採用焦點團體的方式，或者把情節列成一張清

單跟客戶確認，然後再確認頁面框架。當故事板和系統功能完成時，也可以經由

易用性的實驗來加以驗證。

圖 3.6：這張圖擷取自某個易用性實驗的視訊檔。圖中的畫面就是當使用者正在操作軟體時所看到的畫面，而右下角重疊的部份，則是使用者正在操

作的情形。這樣觀察者可以從這個畫面同時看到使用者的操作畫面以及他

使用軟體的情況，並且聽到使用者反映的意見。


易用性實驗的設定要儘可能符合真實的環境，並且提供一組要達成的目標，

而使用者必須在沒有他人協助的情況下完成這些目標。在微軟，我們有一些房間

會固定裝設單面鏡和錄影設備，這樣觀眾就可以在鏡子背後或者透過串流影音觀

看實驗的過程。這樣的環境的確很方便，但不是必要的，你只要有一台攝影機架

在三角架上，或者用微軟的 LiveMeeting 之類的軟體再搭配一個網路攝影機，就

可以達到相同的效果。

有三個關鍵因素會影響易用性實驗的成效：

營造信任的氣氛，讓使用者知道受測的是軟體，不是他。

讓使用者放聲思考（think out loud），這樣你就可以聽到他發自內心的

聲音。

不要「誘導證人」── 也就是說，不要在測試的時候干擾使用者，讓他自

己去探索和發現這個軟體系統。

請記住，需求是會變來變去的，你必須在開發軟體的過程中不斷重新檢討並

了解使用者的期望和滿意度。

發展情節

你怎麼知道你的情節已經寫得夠好了？當團隊成員對於下一次反覆週期要設

計的功能和測試都有共同的認知時，這樣就表示足夠了。你也可以用以下三種方

式來檢驗情節是否足夠：

客戶看完這些情節之後，能夠提供一些回饋意見，例如：是否符合原訂的

目標、是否遺漏了什麼步驟、以及資料之間的關聯性等。

測試人員從這些情節就知道如何定義好的和不好的測試。他們會知道如何

測試執行的順序、哪些資料是必要的、以及應該找出哪些差異。

程式開發人員或架構小組能夠從中找出必要的互動、介面、和依存關係，

俾以設計要交付的服務、元件、或功能。

另一方面，如果你發現情節沒有完全達到利害關係人期望的功能，你可以加

入更多細節或者進一步擴充情節。

第 3 章需求 | 65

在一個反覆週期的中間或結束時展示剛完成的功能有很大的激勵作用，這樣

不但能鼓舞團隊士氣、促進同儕之間的互動，而且如果客戶有參與的話，也能產

生良性互動並提高客戶的熱誠。

你應該在反覆週期進行的過程中逐步加入一些情節。早期的反覆週期要注意

的通常是滿意因子（satisfiers）和興奮因子（exciters），而比較後面的反覆週期，

則應致力於排除不滿因子（dissatisfiers）。這種方法會很自然的帶領你找出情節

的替代路徑。下一章會示範如何把完成的情節轉成計分卡，以追蹤專案的開發速

度和進度。

人物代表、情節、和它們的替代品雖然 MSF 使用人物代表和情節來捕捉使用者的遠景和需求，不過，其它開發

流程還有使用其他的技術或術語，因此我也在這個小節中略提一二。

參與者和使用案例

如果你熟悉 Rational 統一流程（Rational Unified Process，簡稱 RUP），那

你應該聽過「參與者」（actor）和「使用案例」（use case）這兩個術語 12，而且

可能會想知道它們跟人物代表和情節是不是相同的東西。MSF 之所以用不同的術

語來區分情節和使用案例，是因為 MSF 主張要捕捉到某種層級的明確性，而使用

案例卻通常不會這麼明確。情節和使用案例的出發點很類似，但是後續的發展卻

大不相同。

MSF 有一個理念是：儘早將人物具體化。例如，與其給一個棒狀小人圖，旁

邊加註沒有具名的角色名稱（譯註：這裡指的就是使用案例圖），還不如給他一張圖、

一個名稱、以及一份描述。你可能會根據使用者族群定義多種人物代表，而使用

案例分析裡面則可能只有一個參與者。人物代表是以電影人物性格的方式描述，

不僅好記，而且方便溝通，這對於規劃系統的遠景很有幫助。

與人物代表一樣，情節也應該儘早明確。你會在其中加入操作畫面的簡圖，

並顯示從一個畫面切到下一個畫面時的資料流。如果是以使用案例來分析，這些

明確的資訊通常會拖到細部設計的步驟時才會出現。不要拖 ── 你應該立刻針對

這些明確的需求進行初步的測試。


同樣的，不要像在撰寫使用案例時那樣，那麼快就陷入替代路徑的泥淖，應

該等到你真正需要的時候才去寫替代路徑。你的目標是盡快交付可執行的軟體並

從中學習。在交付可執行的軟體之後，你會更清楚應該要有哪些替代路徑；如果

你在一開始什麼都還不明確的情況下就要找出所有的替代路徑，你肯定會碰到很

多麻煩。單一路徑的情節不管是在排時程、監控、還是改版方面都更為容易。

使用者故事

如果你熟悉極致編程（XP），那麼你一定知道使用者故事（user stories）13。

XP 的使用者故事等同於前面提過的情節的目標 ── 寫在 3x5 吋的卡片上的簡短陳

述。XP 並未要求你詳細描述情節，而是要求一位駐點的客戶隨時在旁邊提供實作

的流程說明。如果你的客戶願意到你那裡駐點，你也不需要尋找替代的設計方案，

而且設計的結果不需要有人簽核的話，那麼 XP 的開發流程就可以運作得很好。

但是很不幸，很多團隊需要更明確的溝通與簽核流程，而無法單靠一個駐點

客戶。對於這種情況，把使用者故事詳細描述成情節會很有幫助。情節通常都比

使用者故事更長，尤其是那些描述使用者之間如何互動的情節。

興奮因子、滿意因子、不滿因子情節所關注的，是如何讓使用者喜歡這個產品，並且達成其目標的功能需求，

你可以把這些需求想成所謂的滿意因子（satisfiers）。有些目標和情節對使用者

特別重要或設計得很棒，棒到讓使用者喊出「哇！」的一聲，我們把這種情節稱

為興奮因子（exciters）。

另外還有一些潛在的因素會讓使用者覺得懊惱或擾亂他們的工作習慣，這些

就是不滿因子（dissatifiers）14。在蒐集需求時我們必須考慮這些情況。由於服務

品質常常被忽略，因此不滿因子經常會出現。例如使用者可能會抱怨：「程式的

速度很慢」、「間諜軟體偷了我的帳號」、「我最常用的功能不能執行了」、以

及「系統的延展性很差」等，這些都是由於沒有考慮到對應的服務品質所產生的

不滿因子。

客戶和使用者很少會提出這些不滿因子 ── 他們通常假設不會發生這些狀

況。這令人想到了 Monty Python 的一齣搞笑劇：「寵物店（The Pet Shoppe）」，

這齣戲的劇情是，有一個人到寵物店退還他剛剛買的鸚鵡，由於他在買鸚鵡時並

第 3 章需求 | 67

沒有指定要活的，所以店員就賣給他一隻死的鸚鵡。這齣戲之所以好笑，在於它

揭露了我們平日經常會發生的誤會。一些像是「你當初又沒有告訴我 X」、「客

戶並沒有指明要 X」、和「我們的研究結果並沒有顯示 X」之類的話，都是因為

沒有考慮到要避免不滿因子而產生的後果。

圖 3.7：寵物店（The Pet Shoppe）顧客：「我要申訴，我半小時以前在你的店裡面買了這隻鸚鵡。」店家：「喔好的，這個，啊……有……有什麼問題嗎？」顧客：「我告訴你怎麼了，小老弟。牠是死的，這就是問題！」15

Monty Python's Flying Circus，簡稱 Monty Python（蒙蒂蟒蛇），是英國著名的喜劇表演團體，於 1970年代起與英國 BBC電視台合作一連串短篇喜劇劇集，風格辛辣、葷腥不忌，與美國的 Saturday Night Live 互相輝映。（資料來自

http://www.kr.com.tw/form/phpBB2/viewtopic.php?p=2756）

服務品質情節的確非常有用，但它們並不是唯一的需求。情節也必須考慮到服務品質

（Quality of Service，簡稱 QoS）。（服務品質一度被稱為「非功能需求」，但

我不用這個術語，因為它不大貼切。也有人叫它們是「’ilities」，這倒是既貼切

又簡潔）


「 ‘ilities」之所以成為服務品質的代名詞，是因為許多服務品質的單字都是以「ilitiy」結尾，例如：usability（易用性）、compatibility（相容性）、maintainability（可維護性）……等等。

其實只要定義適當的服務品質項目，就能避免大部分的不滿因子。服務品質

可能代表了系統整體的特性，也可能是針對特定情節的特殊限制。例如，「未授

權的使用者不能存取系統或任何資料」就是系統整體安全的服務品質。「當有 1000

名使用者同時執行下訂單的功能時，95% 的訂單必須在三秒內傳回結果」則是跟

下訂單情節有關的效能服務品質。

並不是所有的服務品質都適用於所有系統，你應該知道你的系統需要哪些服

務品質。服務品質通常意味著比較大的架構需求或風險，因此你應該儘早和利害

關係人討論它們。

目前並沒有一份絕對完整的服務品質項目清單，之前曾經有人嘗試撰寫一些

標準文件 16，但是因為科技進步得太快了，這些標準很快就會過時。例如，那些

主要的標準並沒有考慮到安全性和隱私權的問題，可是它們卻是現代的軟體系統

不可或缺的品質因素。

以下四個小節分別列出一些開發專案時最常見的服務品質項目。

安全與隱私

網際網路的盛行同時也讓安全性和隱私權成為每個使用者的隱憂。這兩項服

務品質對於應用程式的開發和操作都很重要，而且現在的客戶水平也都很高，會

要求知道你是採用什麼方法來解決這個問題。漸漸地，它們就成為企業治理的重

大議題了。

安全性（Security）：軟體能夠避免未授權的使用者、病毒、蠕蟲、間諜

軟體、或其它方式入侵和破壞的能力。

隱私權（Privacy）：軟體能夠避免未授權的存取或檢視個人身分資訊的

能力。

第 3 章需求 | 69

效能

效能通常要等到已經很差的時候才會有人注意到它。其實在設計、開發、和

測試的時候，你都應該要考慮這些會影響整體效能的服務品質因素。

回應性（Responsiveness）：系統對於使用者執行的動作、函式呼叫、

或者事件的回應速度。

並行性（Concurrency）：當系統跟其他軟體同時執行時，依然能維持正

常運作的能力。

效率（Efficiency）：在限定資源的條件下，軟體效能依然能夠維持一定

水平的能力。17

容錯能力（Fault Tolerance）：軟體在發生錯誤或違反其特定介面時仍

然可以維持正常運作的能力。18

延展性（Scalability）：當有多個使用者同時進行多項作業時，軟體仍然

能夠維持一定效能的能力。

使用者經驗

雖然「容易使用」是一般常見的說法，但其實還有許多用來描述使用者經驗

的術語，包括：

可及性（Accessibility）：身心障礙者可以跟一般人一樣存取及使用軟體

資訊的程度。19

吸引力（Attractiveness）：用來表示軟體對使用者的吸引力有多大。20

相容性（Compatibility）：表示軟體符合一般慣例和期望的程度。

容易使用（Ease of Use）：使用者能否很有效率地使用軟體執行他的

工作。

本地化程度（Localizability）：軟體能夠符合特定使用者族群的語言、

文化、和使用習慣的程度。


可管理性

現代的軟體大部分是多層式、分散式、服務導向或主從式架構的應用程式。

這些應用程式的作業成本往往比開發成本還要高，然而，知道如何改善的開發團

隊卻少之又少。應該要考慮的服務品質有以下幾項：

可用性（Availability）：每當使用者需要使用某個系統或元件時，它們

都能夠隨時提供服務的能力。也有人稱它為可能性（probability）21，而

且常常會以「一些九」（nines）或「三個九」（three nines）來表示 99.9%

的可用性。

可靠性（Reliability）：在特定的情況下使用軟體時，軟體的效能可以維

持在一定程度的能力 22。也就是我們經常講的「平均故障時間」（Mean

Time Between Failures，MTBF）。

可安裝性與可移除性（Installability and Uninstallability）：>>軟體可在

特定環境下安裝和移除的能力 23，而且移除之後要能將系統還原到安裝前

的狀態。

可維護性（Maintainability）：軟體系統或元件能夠很容易修改、修復錯

誤、改善效能或其它屬性、或很容易隨環境調整的能力。24

可監視性（Monitorability）：軟體系統能夠自動蒐集執行過程當中的作

業資料或健康資訊的能力。

操作性（Operability）：軟體能夠讓使用者自動控制的能力。

可攜性（Portability）：軟體從一個環境移轉到另一個環境的能力。25

可復原性（Recoverability）：當軟體發生錯誤時，能夠從失效的狀態恢

復成原本可執行的狀態並且將資料復原的能力。26

可測試性（Testability）：是否容易為軟體系統或元件訂出測試條件，並

且對它進行測試以得知它是否符合那些條件的能力。27

支援性（Supportability）：對於後續作業方面的問題，能夠持續予以修

正的能力。

符合標準（Conformance to Standards）：軟體符合標準規範的程度。

互動性（Interoperability）：軟體跟其他系統互動的能力。28

第 3 章需求 | 71

怎樣才能訂出好的服務品質需求清單？就像撰寫情節一樣，服務品質需求應

該要讓利害關係人很容易了解、及早定義，而且如果你是在規劃某一次的反覆週

期的品質需求，那麼它們都必須是可測試的。你可以先從一般的效能問題開始著

手，例如，在某個反覆當中，特定負載的情況下，系統必須在多少時間內完成多

少筆交易。如果你無法說明你是如何進行測試以得知系統是否滿足品質的要求，

那你也一定無法測量軟體的完成率究竟是多少。

卡諾分析有一種很有用的分析技術，叫做「卡諾分析」（Kano Analysis），它是以原

創者的姓氏來命名。卡諾分析是把興奮因子、滿意因子、和不滿因子都放在相同

的軸線上 29。X 軸代表某個情節或服務品質已經完成了多少，Y 軸則是客戶的滿

意度。

以前面提到的 Monty Python 的鸚鵡為例，「活著」就是它的滿意因子，或者

說，必要的服務品質（就像其他的服務品質一樣，客戶通常會認為這是天經地義

的事，因此沒事先檢查就把牠買回家。而店員卻也像個心術不正的專案經理一樣，

充分利用了需求不明確、又不主動告知的手段來佔客戶的便宜）。

當然啦，排除掉不滿因子也只能讓你的客戶得到一個不好也不壞的印象。一

隻活的鸚鵡只是讓你的客戶願意進一步觀察牠。相對的，要達到讓客戶滿意的程

度，你的產品必須有令客戶想要購買或使用的附加價值。就鸚鵡來說，可能就是

當客戶跟牠說話時，牠會以美妙的歌聲回應。

鸚鵡的身體健康是必要的需求 ── 少了它，客戶會不高興；有了它，客戶覺

得理所當然。唱歌的情節則是一項滿意因子或「效能需求」── 客戶會希望有這

項功能，而且他的滿意度會隨著這項功能的品質而提升。

滿意因子能夠讓客戶滿意的程度，並不一定跟它們的表現成正比。有時候我

們不會特別去描述或考慮到它們，因為有些滿意因子需要大幅度的創新才有可能

產生。不過相對的，它們也可能非常簡單，卻足以發揮極大的效益。比如說，有

一陣子，小型箱型車是以後座的置杯架為賣點，後來變成了滑動門的數量，然後

又變成了後座的影音設備。這些都只是小地方的改進，但是卻造成了產品之間的


差異，而且它們剛開始在市場上只是興奮因子，經過一段時間之後就變成基本配

備（must-haves）了。

圖 3.8：X軸顯示產品的需求已經完成了多少；Y軸顯示客戶對產品的反應。

回到鸚鵡的例子，想像一下，如果鸚鵡會清理自己的籠子會是什麼景象。

根據客戶對某種功能的存在與否感到滿意或不滿，你可以歸納出三種需求：

必備因子（must-haves）、滿意因子、和興奮因子。必備因子是產品的基本要件，

興奮因子則讓產品更加完美，而滿意因子則是符合使用者原本的期待，但是不會

讓他們覺得跟其它產品有何不同。為了完整起見，我們再加上第四項 ── 無關緊

要的（indifferent）功能 ── 即有沒有都沒關係（例如鳥籠的顏色）。

第 3 章需求 | 73

圖 3.9：卡諾分析模型展現了產品功能的重要性，共分成四種：必備因子、滿意因子、興奮因子、和無關緊要的功能。

技術採用生命週期

這裡再介紹一個很有用的方法，它也可以用來將需求分類以及了解不同客戶

族群之間的差異性。這個方法就是「技術採用生命週期」（technology adoption

lifecycle），如圖 3.10 所示。這個模型經常用於描繪產品在市場上的滲透力或科

技的普及性。30

不滿因子和興奮因子的重要性主要是看你的使用者是屬於技術採用生命週期

中的哪一個類型。如果是屬於早期採用者（early adopters），他們通常對新技術

有著高度的狂熱，因此對不滿因子的容忍度比較高，而且為了實現興奮因子的優

點，他們也比較願意接受廠商提供的暫時解決方法（或快速修補）。相對的，在

技術採用生命週期中屬於比較晚期的使用者，他們對不滿因子的容忍度就比較

低，而且通常認為興奮因子是理所當然的事。使用者會逐漸對整個產品更加熟悉

也更加敏感和挑剔，這是產品在市場上演進的必然現象。


圖 3.10：技術採用生命週期的標準模型，圖中的 S形曲線分成了四個區域：早期採用者（early adopters）、早期大眾（early majority）、晚期大眾（late majority）、和落後者（laggards）。

蒐集資料

雖然 Monty Python 的鸚鵡有點搞笑，不過，卡諾分析的確是用來思考和分析

需求的好用工具。有一個很簡單的方法可以讓你很容易就蒐集到卡諾分析所需的

資料，那就是向客戶提出兩個問題，一個問題是關於某項功能的適用性，另一個

則是它的重要性。例如以下兩個問題：31

我們剛才給您示範（為您解說）的功能（情節），離您想要的還有多遠？

我們剛才示範（或解說）的功能對您來說有多重要？

不論你是在做廣泛的統計研究還是非正式的焦點群組訪談，把情節和服務品

質分開，或者把要實作的功能分成四組（譯註：即滿意因子、不滿因子、興奮因子、

和無關緊要的功能）對於了解產品的真正需求都有很大的幫助。

由於思考需求的過程或方法過於草率，大部分的專案最後都會列出過多的需

求項目（而且有的根本不需要）。卡諾分析能夠讓你很容易看到整體的需求，並

第 3 章需求 | 75

且將那些不同的觀點和一些關於興奮因子、滿意因子、和不滿因子的相對重要性

等隱晦不明的資訊突顯出來。

卡諾分析也能協助你決定情節和服務品質的優先順序。當你在規劃一個反覆

週期時，你可以把一組需求畫在圖上，並且預估可能的客戶滿意度，以決定各項

需求在圖中的 Y 軸位置。當專案持續發展了幾次反覆週期，你會想要把代表客戶

滿意度的 Y 軸調高。這種方法可以展現各項需求在價值上的差異，當你需要抉擇

哪些需求要先實作或哪些要捨棄時，這會是一個相當好用的工具。

總結本章介紹了與專案遠景和需求有關的議題。如上一章所說的，MSF 提倡反覆

式軟體開發流程，以及在第 1 章裡面討論的增值思維模式。這也意味著需求是在

每一次反覆週期當中逐漸改進並描述得更加詳細，因為需求本身是很容易改變的。

在 MSF 中，需求的主要型式就是情節和服務品質。情節就是功能需求，它的

內容必須考慮到是否符合某個或一群人物代表的目標，並且以使用者熟悉的語言

來描述人物代表為了達成其目標所必須執行的步驟和互動情形。情節可以在頁面

框架和故事板當中詳細的加以描述。

服務品質描述了軟體應該要具備的品質屬性，例如安全性、效能、使用者經

驗、以及管理方面的屬性。品質屬性有的是全域性的，亦即跟軟體的所有功能需

求都有關係的；有的則是限定在某些情節。服務品質經常被視為是架構面的需求，

不僅僅因為它們對於架構的設計決策有重大的影響，同時也因為通常要具備專業

的架構知識才有辦法列舉這些服務品質項目。

並非所有需求都同等重要。你必須了解哪些需求對客戶而言是滿意因子、興奮

因子、和必備因子（可消除不滿因子的項目）。單單只有情節的話，通常很難消

除所有的不滿因子，因為那些不滿因子通常隱藏在設計不良的服務品質計畫中。

此外，情節本身也不會包含架構設計、實作細節、或者全部的替代路徑。

討論完需求的相關議題之後，下一章我們再來看專案管理的流程。


注釋 1. Frederick P. Brooks, Jr., The Mythical Man-Month: Essays on Software

Engineering, 二十週年紀念版（Reading, MA: Addison-Wesley, 1995），第 199頁。中文版《人月神話》，錢一一譯，經濟新潮社出版，第 257 頁。

2. 取自 Geoffrey A. Moore, Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers (New York: HarperCollins, 2002), 第 154 頁。

中文版《跨越鴻溝》，陳正平譯，臉譜出版，第 242 頁。

3. Beck 2000，之前已經引用過，第 60–61 頁。

4. IEEE STD 830 就是這類規格書的範例指南。

5. Moore, Crossing the Chasm，第 93–4 頁。

6. Alan Cooper and Robert Reimann, About Face 2.0: The Essentials of Interaction Design (Indianapolis: Wiley, 2003), 第 59 頁.

7. 欲進一步了解微軟如何使用人物代表，請參考 John Pruitt, Persona Lifecycle:

Keeping People in Mind Throughout Product Design (Elsevier, 2005).

8. Cooper 2003，之前已經引用過，第 12 頁。

9. 同上，第 35 頁。

10. Hugh Beyer and Karen Holzblatt, Contextual Design: Designing Customer- Centered Systems (San Francisco: Morgan Kaufmann, 1998) and Cooper op cit., 44 ff.

11. Moore，之前已經引用過，第 98 頁。

12. 源自 Ivar Jacobson 等人所著的 Object-Oriented Software Engineering: A Use Case Driven Approach (Reading: Addison-Wesley/ACM Press, 1992), 159 ff., 而且在許多書籍中都有詳細說明，包括 Alistair Cockburn 的 Writing Effective Use Cases (Pearson Education, 2000). 這些作者對使用案例的用法有了實質上的轉

變，而 MSF 則透過「情節」這個字眼與傳統上獨立的使用者經驗（User Experience）社群連結起來。

13. 例如 Mike Cohn, User Stories Applied: For Agile Software Development (Boston:

Addison-Wesley, 2004).

14. J.M. Juran, Juran on Planning for Quality (Simon & Schuster, 1988).

15. Monty Python’s Flying Circus, "The Dead Parrot Sketch," available on The 16-Ton Monty Python DVD Megaset, Disc 3 (A&E Home Video, 2005).

第 3 章需求 | 77

16. 例如 ISO/IEC 9126 and IEEE Std 610.12-1990.

17. [ISO/IEC 9126-1/2001]

18. [ISO/IEC 9126-1/2001]

19. Section 504 of the Rehabilitation Act, 29 U.S.C. § 794d, 可在此取得：

http://www.usdoj.gov/crt/508/508law.html.

20. [ISO/IEC 9126-1/2001]

21. [IEEE STD 610.12-1990], 11

22. [ISO/IEC 9126-1/2001]

23. [ISO/IEC 9126-1/2001]

24. [IEEE STD 610.12-1990], 46

25. [ISO/IEC 9126-1/2001]

26. [ISO/IEC 9126-1/2001]

27. [IEEE STD 610.12-1990], 76

28. [ISO/IEC 9126-1/2001]

29. Kano, N., Seraku, N., Takahashi, F. and Tsuji, S. (1996), "Attractive quality and must-be quality," 原發表於 Hinshitsu (Quality), The Journal of the Japanese Society for Quality Control, XIV:2, 39–48, April 1984, 英文版發表於 The Best On

Quality, edited by John D. Hromi. Volume 7 of the Book Series of the International Academy for Quality (Milwaukee: ASQC Quality Press, 1996).

30. 例如 Moore，之前已經引用過。

31. 關於蒐集資料的詳細問卷，請參考：Center for Quality Management Journal, II:4,

Fall 1993.

chap03a -...

Documents