需求收集與分析的施行方式與技巧


前言

需求收集與分析的目的，主要是用來辨別客戶需要的是什麼，其目標在於描述客戶對於專案所預期呈現的結果，然後以有系統的方式加以整理列出。在許多書裡，大都只強調需求完整的重要性，或是列出一些很空洞的施行綱要，但對於實作時，需求要怎麼收集、要怎麼分析幾乎都很少提到，使得無經驗的專案經理往往不知如何著手，只能利用嘗試錯誤的方法摸索進行。因此本文特別著重在需求收集與分析的施行方法與技巧上，這些都是作者多年經驗所累積下來的知識，無論對於有經驗或無經驗的專案經理而言，都是一份極有參考價值的資料。

套裝類軟體的需求收集

套裝類的軟體產品所面對的客戶，通常是某個族群，即使有了許多已知的客戶，但潛在的客戶往往還更多，因此它的需求會比較模糊而寬廣，難以收集完整，不過相對的，客戶對於某些不符自己所需的地方也不會太過強求，驗收的標準會比較寬鬆些。而我們所要做的，便是儘量收集到客戶的需求（包括未來可能的需求），再依照目標客戶對各項需求的急迫性加以區分，最後視開發的時程與成本，分階段開發出來。以下便是收集這些需求一些有用的做法：

1.由目標客戶找出需求

a.與既有客戶或未來可能的客戶進行訪談或意見調查，將客戶建議的事項視為需求，逐一列出。

收集需求的最佳方式，永遠都是由客戶端獲得。但由於套裝軟體的客戶群並不固定，因此最好能依照應用領域、運用方式、使用頻率、對電腦系統的熟悉程度、地理位置、職位階層等各種客戶特性，區分出多個目標客戶群，然後針對最重要的幾個目標客戶群進行意見調查或訪談。

b.參考與軟體產品相類似的專案之建議書、功能規格書或需求變更表，將可能成為需求的部份逐一列出。

開發套裝軟體產品最佳的策略，便是以專案養套裝，也就是在開發初期，利用專案收集需求（同時也可獲利），之後再集結這些需求開發出套裝軟體。因此如果公司已有類似的專案，直接拿來參考即可省下不少需求收集的時間。

c.逐一過瀘類似專案或舊版軟體之客戶問題反應單，思考問題的原因，並將可成為需求的部份逐一列出。

客戶反應的問題中，有一小部份是客戶要求的新功能或功能規格變更，這些問題都意味著客戶的隱藏性新需求。然而在收集需求時，不能直接把客戶要求的新功能直接視為需求列出，而要先去了解客戶提出這項功能的動機與目的。因為客戶在有需求時，往往會先自行想出做法，然後才要求軟體開發商新加功能，此時這項功能已和原來的需求有所差異，若是客戶自行想出來的做法很爛，那麼將它視為需求開發出來的結果，往往便會成為一項雞肋功能（食之無味、棄之可惜）。

2.由競爭廠商找出需求

a.向行銷企劃部或業務部拿取競爭廠商相關資料，找出可成為需求的部份逐一列出。

行銷企劃部在進行市場調查與研究，或業務部在推展業務時，往往都會研究競爭廠商的動態，以及相互間產品的特性。直接找他們拿取資料，最是方便省時。

b.由競爭廠商公布的產品規格書、白皮書、廣告稿與網站資料，找出可成為需求的部份逐一列出。

由於行銷企劃部或業務部的競爭廠商資料大都已經過分析，未必適於收集需求，因此還是必須直接閱讀競爭廠商的實際產品資料來加以研究。至於有那些競爭廠商，則可從行銷人員與銷售人員處取得，或是經由入口網站搜尋取得。而且只要是與產品目標市場與功能特性有沾上邊的廠商，都應視為競爭廠商加以研究。

c.由競爭廠商相關的新聞資料，找出可成為需求的部份逐一列出。

競爭廠商所發布的新聞資料，往往隱含著對方未來的產品規劃與方向，因此必須仔細加以研究，及早因應。

3.由現行資料找出需求

a.將「發展計畫書」中的專案目標與範圍部份，視為需求逐一列出。

套裝軟體要開發，一定有其目的及市場需求，通常在專案開始時，都會列在發展計畫書中，而這些內容也都算是需求的一部份。在記錄這些需求時，要特別注意其品質特性的需求。

b.找出與專案軟體相關的流行技術、界面標準或法令規章，將可成為需求的部份逐一列出。

藉由這方面的需求收集，可確保專案軟體能符合相關的介面標準與法令規章，同時也能符合技術潮流的走向。

c.參考舊版軟體各版本之軟體規格書與技術文件、使用手冊，將其中所列之需求逐一列出。

如果不是全新開發的套裝軟體，那麼舊版軟體的各項文件，便是個極佳的需求資料來源。

d.試用舊版軟體，將其中之各項功能與應改進缺點視為需求，逐一列出。

如果舊版軟體缺乏文件可供參考，試用便是取得舊版需求的唯一方法。不過即使有完整的文件，也可經由試用過程找出缺點，做為新版改進的需求。

4.由未來產品找出需求

a.與核心技術人員、產品經理、行銷人員、銷售人員討論未來套裝軟體可能衍生的產品、相關的產品、以及可能的合作廠商整合方式，在討論內容中找出可能的需求，逐一列出。

藉由這種方式，可以找出未來功能擴增的可能需求，以及應提供出來的界面需求，強化軟體的擴充性與公用性。

b.列出現行所有的核心技術，並參考其相關文件，找出加入時可成為需求的部份逐一列出。

套裝軟體現行規劃的目標，不一定全用到所有核心技術，因此必須將所有將來可能加入的核心技術都列出，並思考加入時可能會造成的需求。

c.自己思考或詢問同事對該產品的新點子。

如果自己創意夠的話，花些時間好好想想，有時能提出一些不錯的功能，或是被忽略掉的需求。

5.由模擬方式找出需求

a.找出一個或多個專案軟體運用的例子，模擬其運用過程，由過程中找出遺漏的需求。

由於套裝軟體沒有很明顯的客戶群界限，要鑑訂是否有遺漏的需求，最好的方式便是仿造幾個客戶使用的可能例子，在其作業的過程中來驗證是否有遺漏的需求。

b.利用系統分析技術，如結構化分析中的資料流程圖（Data Flow Diagram，簡稱DFD）和物件導向分析中的使用案例（Use Case）等，定出容納所有需求的系統模型，並檢查各需求相互間的關係，以試圖找出未明白列出的隱藏性需求。

這是需求收集的最後一道防線，主要目的便是運用需求的交互關係，來找出隱藏性未列出的需求，使得各項需求緊密連繫在一起。同時藉由建構此一系統模型，也容易檢查出相衝突的需求。這個方法可以延到需求分析的篩選過程中進行。

客戶訂製類軟體的需求收集

客戶訂製類的軟體產品，它的需求通常都有一個相當明確的範圍，因為客戶是已知且有限的。不過這類軟體的需求反而不易收集，主要是因為客戶對於軟體的要求會比較高，而且客戶也往往存在有許多易變的或隱藏的需求，特別是連客戶自己也搞不清楚自己要的是什麼的情況下。這時，我們必須斟酌情形給予客戶適當的建議，儘量讓客戶充份了解到自己實際的需要，否則再怎麼收集需求，最後還是會一變再變，徒勞虛功。以下便是一些運用在這類軟體的需求收集步驟與方法：

1.閱讀並分析客戶交予的需求文件

當客戶訂製類軟體專案一開始，一定都有客戶提供的需求文件或規格書，閱讀這些文件並將各需求逐一條列出來，這是收集需求的第一步。接著，找出各需求的相關性，將語意不清、相互衝突、不知目的、缺少關連的需求表列出來，做為下階段客戶訪談時所要了解的內容。其中在閱讀分析時，要特別注意非功能性的品質需求，因為這部份無論在客戶訪談或原型中，都是很容易被忽略的。

2.安排初次客戶訪談以收集專案相關資訊與需求

在訪談前應先告知客戶訪談的計畫與內容，以節省訪談所需的時間。而初次客戶訪談的目的，除了讓雙方在面晤交談的過程中，增加彼此間的信任與了解外，還包括下列的目的：

a.了解並認識與專案相關的人員，包括使用人員、使用單位主管、承辦人員、承辦單位主管、上級主管等。
b.討論並協調當各使用單位或主管在需求上有衝突時，應由誰進行決策，以避免多頭馬車、懸而不決的情況。以下是一些建議的決策人員，可依實際情況加以調整：

*開發人員與客戶之間：由客戶決定，不過要提供一些建言，因為客戶不一定是對的。
*承包商與客戶之間（即我們是別人的外包商）：由客戶決定，承包商與客戶間再行協調。
*承辦人員與承辦單位主管之間：由承辦單位主管決定。
*承辦單位與使用單位之間：由使用單位決定。
*不同單位的使用人員之間：由上級主管協調決定，或由使用頻率最高的使用單位決定。
*使用人員與使用單位主管之間：由使用人員決定。
*同單位多個作業不同的使用人員之間：由單位主管協調決定，或由使用頻率最高的作業人員決定。
*同單位多個相同作業的使用人員之間：由資深人員決定。

c.了解專案的背景，詢問並澄清客戶需求文件中有疑問的內容。

d.了解客戶現行作業的流程與處理方式，以及專案軟體在這過程中扮演的角色。如果客戶無暇提供現行作業的資料，最好的方法便是另行安排時間，觀察客戶一日的作業情況並加以記錄分析，最後再與客戶討論確認。

3.建立客戶作業模型找出需求

了解客戶的領域知識，並建立客戶現行與未來作業的模型（可利用DFD或Use Case），從中找出客戶未提及的需求，或是該領域中常識性的需求。模型建立後，應再與客戶確認作業模型的正確性，但記得要將模型改用最常見的步驟化方式來描述，並忌用技術性字眼（最好使用客戶領域的專業術語，可建立一個專案詞彙表做為參考）。如果未來作業的模型有多種可能，都應該全部告訴客戶，由客戶來自行決定（我們可從旁分析與建議）。

4.利用原型收集及確認需求

原型是提供客戶確認需求的最好方式，主要是因為它看得到，特別容易挖掘到客戶一些細微的隱藏性需求。不過利用原型模式會多費一些人力時程，在時程與成本的控制上要特別小心。

5.最終需求確認

不要枉想一定能和客戶簽下需求確認合約，因為絕大部份的承辦人員或使用單位都不願意配合（當然可能的話是最好，不過即使簽立確認合約，也不可能避免需求變更）。適當地採用原型來進行需求確認，比較能減少將來需求變更的機會，不過同樣要注意原型展示時的客戶參與對象。但是無論客戶是否願意簽下需求確認合約，都要讓客戶了解到（最好寫在文件中），將來需求的變更都會導致成本與時程的改變，甚至必須重新協調專案的價格與時間表。加強對客戶觀念的灌輸與溝通，有時比單純簽約保證，更有利於專案的順利進行。

需求分析的步驟

1.記錄：任何收集到的需求，一定都要馬上建檔集中記錄下來，避免遺忘或漏失。記錄的同時，應該同時標示需求獲得的來源。

2.分類：將所有記錄下來的需求，進行分類的動作，一般先依子系統或系統作業項目分類，然後再依作業流程、企業規則（即作業流程運作規則）、功能需求、外部界面需求、限制、非軟體性品質需求等類別進行分類。如果某個類別（特別是功能需求部份）有太多的需求時，應再依需求的性質進一步分類。分類完畢後，應檢查各預定的類別中是否都已有相關的需求列出，如果有缺少的部份應再進行需求收集的動作。

3.歸納：將同一類別中，相同或類似的需求加以合併。

4.分解：將範圍太大的需求再進一步加以了解並細分。細分出來的需求必須重新以先前的分類機制分類。

5.精鍊：將模糊不清的需求定義清楚，該標示品質特性的地方要予以標示，而能量化的地方則儘量以數據量化。要確認各項需求是否定義清楚，只需將該項需求交給數人觀看，如果會出現兩種以上的解釋，便表示該需求還是模糊不清的。

6.篩選：討論、評估需求的必要性（需要客戶參與），並檢查需求的一致性，淘汱掉不需要的需求，或相互衝突的需求（也可加以折衷）。最好能事先用系統分析方法建構出系統模型來加以檢驗。

7.評估：對各項需求，進行成本效益、可行性等風險評估。視情況必須依照專案的各種限制條件，去除掉一些不可行的需求（仍需與客戶討論確認）。

8.撰寫：將最終的需求寫成需求規格書。撰寫時應對每項需求給予一個固定編號，以利將來需求變更時的追蹤。

9.審核：對需求規格書中的需求進行審核，確認各項需求清楚、完整，以及它的適用性（審核前數日應先行將文件送交審核人員處）。如果審核人員對最終需求有所疑慮或意見，應再依前述步驟重新修正過。審核人員通常由專案經理、系統分析師、系統設計師、資深程式設計師、測試人員各派一名代表，再加上數位客戶代表共同擔任，但人數最好不要超過7人（不含需求分析人員），超過時可改成分組討論的方式進行審核。但無論如何，一定要儘量讓客戶代表參與，因為只有客戶代表才有權決定需求的適用與否。如果是套裝類軟體，客戶代表則可由產品經理、行銷人員、業務人員、或現行客戶擔任。審核時，應對需求逐條檢閱，並賦予各審核人員主要的審核角度，同時審核過程也應以正式文件加以記錄。

10.排序：討論並決定各需求實作時的優先次序（仍由參與審核的人員擔任）。這是因為在開發過程中，可能會因為時程或成本的關係，捨棄掉一些不重要的需求。其訂定的方式，一般可先將需求大致區分為必做的核心需求，與可有可無的一般需求。先將核心需求列為第一順位，接著再採用成本效益評價法，排序剩下的一般需求。成本效益評價法可採用下列公式計算，其中各值可以1∼9的分數加以評量，開發風險也可設成0：

(加入產生的利益+捨棄導致的損失) / (開發成本+開發風險)

11.定案：將審核過的需求規格書視為需求基準，納入形態管制，做為系統分析時的依據。



參考文獻

1.軟體工程實務專家作法，第四版，Roger S. Pressman原著，金子葳等人譯，儒林，1998
2.軟體發展指引（SDG 2.0），資策會，1988
3.微軟如何滿足客戶的需求，Karl E. Wiegers原著，許惠丹編譯，華彩，2000
4.微軟開發快速秘笈，Steve McConnell原著，鄒正平譯，華彩，1999

需求規格書格式

1. 簡介
簡單說明專案成立的原因與背景。

1.1 專案目標
明確標示出專案所欲呈現的結果與達成的目標，必須包括品質目標。此處列出的品質目標為總體性目標，以定性方式描述，定量的品質要求則列於系統需求之中。品質特性可分成可追蹤性、完整性、一致性、安全性、健壯性、正確性、精確性、培訓性、可作業性、自描述性、模組性、簡單性、清晰性、結構性、產品檔案完備性、可見性、設備有效性、處理有效性、通訊有效性、軟體系統無關性、硬體系統無關性、可擴充性、公用性、相容性等24個特性。

1.2 專案範圍
說明專案所涵蓋的內容範圍，如作業範圍、用戶範圍、功能範圍、限制範圍等，屬於總體性的需求範圍概觀說明。不必太詳細，但必須與系統需求的內容一致。

2. 系統需求

2.1 環境需求
說明系統在自然環境（如溫度、濕度、風速、地理位置等）、後勤支援（如維修、運送設備與工具）、人員訓練（如使用人員與維護人員所需的知識、技術與訓練）等需求。

2.2 系統架構
以架構圖來表示，一般分成２∼３層，以說明系統由那些子系統所組成，各子系統又需要那些軟硬體建構項目。也可增列資料流程圖（DFD）或使用案例（Use Case）做為輔助說明。

2.3 系統界面

2.3.1 外部界面
說明系統與外部相關軟硬體之間的界面。

2.3.2 內部界面
說明系統內，子系統與子系統之間，或建構項目與建構項目之間的界面。

2.4 子系統需求
針對每個子系統，說明下列的需求。如果沒有子系統，則針對整個系統進行說明。

2.4.a <子系統名稱>需求

2.4.a.1 軟體建構項目需求
針對每個軟硬體建構項目，說明下列的需求。如果沒有軟硬體建構項目，則針對整個子系統進行說明。

2.4.a.1.b <軟體建構項目名稱>需求

2.4.a.1.b.1 功能需求
列出所有的功能需求，並各賦予一固定編號。功能需求中應包含它的輸出入資料之說明。

2.4.a.1.b.2 界面需求
列出與其他建構項目、子系統或外界的界面。

2.4.a.1.b.3 作業程序需求
列出原來的作業程序以及系統導入後的作業程序，必須包括電腦作業程序與人工作業程序。

2.4.a.1.b.4 品質需求
列出非功能性的品質需求，儘量以定量方式加以描述。

2.4.a.1.b.5 限制條件
說明其實體限制（空間、重量、運輸、儲存、環境、耐久等）、硬體限制（記憶體容量、CPU速度、電腦機種等）、軟體限制（支援的軟體工具、套裝軟體）、人體工程因素（即描述人員與系統間操作的一些限制與考量）。

2.4.a.2 硬體建構項目需求
針對每個軟硬體建構項目，說明下列的需求。如果沒有軟硬體建構項目，則針對整個子系統進行說明。

2.4.a.2.c <硬體建構項目名稱>需求

2.4.a.2.c.1 架構
說明硬體的結構與連接方式。

2.4.a.2.c.2 配置
說明硬體的分佈位置。

2.4.a.2.c.3 特性
說明硬體建構項目所必須具備的功能及特性。

2.4.a.3 支援軟體需求
說明子系統運作時必須具備的支援軟體，包括系統軟體（如操作系統、資料庫系統、編譯器）、軟體元件、套裝軟體等。

2.4.a.4 通訊網路需求

2.4.a.4.1 通訊網路架構
說明各項設備在網路中互相連結的方式（如星狀、網狀），以及各設備之間賴以連繫的傳輸媒介（如同軸電纜、電話線）與方式（如專線、數據機）。

2.4.a.4.2 資料傳輸處理
說明通訊協定與傳輸能力。

2.4.a.4.3 通訊網路配備
說明通訊網路的硬體設備、傳輸媒界規格、與使用的軟體。

2.4.a.4.4 網路限制
說明通訊規範限制（即通訊協定、傳輸媒介、資訊傳輸業者提的服務所造成的限制）與軟硬體限制（如傳輸距離、速率等）。

3. 軟體發展管理

3.1 組織
明確標示出參與專案的人員，以及其負責的任務，並描述採用的組織形態。如果人員不足，必須明列出該任務所需人數及資料。如果有其他機構參與本專案，如上屬機構、使用機構、承包機構等，都應描述出來，最好用組織圖描述。

3.2 預估時程與成本
說明預估的時程、查核點、與交付項目。並列出預估的成本。

4. 需求重要性一覽表

4.1 必要需求
列出所有必要的需求。

4.2 非必要需求
依重要次序列出各非必要需求，以及其評價分數。

5. 審核人員
列出所有參與需求規格審核的人員及其職責。

6. 參考文件

需求規格正式審核會議

前言

一個好的需求規格，必須是完整、正確、清楚、可行、必要、且可加以驗證測試的，而要確保此一品質要求最重要的步驟，便是需求規格的正式審核會議。通常在此過程中多花一分力氣找出潛在的需求錯誤，往往便可省下後面開發階段裡近百倍的成本。因此本文的目的，便是說明如何成功地召開並完成需求規格的正式審核會議。

邱奕南，2000/5/9


一、決定與會人員及角色

1.客戶代表：只有客戶才有權決定需求規格的必要性，因此審核人員中，最重要的便是客戶代表。如果客戶族群有多種，應從最具代表性的幾個客戶族群中，各挑一個客戶代表參與會議。如果是套裝類軟體，客戶代表則可由產品經理、行銷人員、業務人員、或現行客戶擔任。客戶代表的主要工作，便是審核需求是否完整、正確且必要。

2.專案經理或產品經理：以整體規劃的角度來審核需求是否完整、正確、清楚。

3.系統分析師：審核需求是否清楚，並由理論與邏輯的角度來審核需求是否可行。

4.系統設計師：審核需求是否清楚，並由理論與應用技術的角度來審核需求是否可行。

5.資深程式設計師：審核需求是否清楚，並由應用技術與程式撰寫的角度來審核需求是否可行。

6.測試人員：審核需求是否清楚、並可加以驗證測試。

7.品質保證人員：監督正式審核會議是否合乎既定流程，並審核需求規格中是否有可能違反品保規章、或影響其他相關品質的部份。

8.需求分析人員：不參與審核，主要聆聽審核人員的討論，思考並回答審核人員的疑問。

上述各類人員至少均應派一位代表參與審核（可兼任），但審核人員（不含需求分析人員）最多不要超過7人，如果超過時可改成分組討論的方式來進行審核，避免人多口雜，延緩了會議的效率。而在與會人員中，還必須指派會議中的三個角色（需求分析人員均不可擔任）：

1.主持人：通常由專案經理或產品經理擔任，負責與需求分析人員共同規劃、決定與會人員，同時協調並控制整個會議的議程順利進行。

2.解釋員：負責逐一解釋各個需求規格中的語意。

3.記錄員：負責記錄會議中所發現的需求問題與錯誤。


二、會前準備

1.決定與會人員並發出審核會議通知書，明訂出各與會人員的職責，以及會議的議程。整個會議的時間以不超過兩小時為宜，若有需要可分成多次會議進行。

2.將需求分析結果寫成正式的需求規格文件。

3.先進行數次非正式的複審，以降低需求規格可能出錯的機率。其過程和正式審核會議有些類似，但比較不嚴謹，通常每次找一到兩位同事（最好是非參與正式審核會議的人員），針對需求規格書中每個需求，逐條說出他們所了解的程度，以及他們的看法。非正式複審往往可事先找出絕大多數描述不清楚的需求。

4.對即將交付審核的需求規格書，進行校閱的工作，避免有任何的錯漏字。

5.會議幾天前（至少要三天以上）即將需求規格書送交審核人員進行預審。審核人員可先行反應需求規格書中明顯的問題與錯誤，需求分析人員在修正需求規格書後，應將新的需求規格書重新送交審核人員，並將修正之處附於文件之後供做參考。需求分析人員應持續追蹤所有審核人員是否均已進行過預審。

審核人員預審時，可依下列問題進行思考（但非絕對）：

1.所有需求彼此之間的牽動關係是否正確？
2.所有需求描述的詳細程度是否適當？
3.是否已納入了所有客戶曾告知的需求？
4.需求中是否漏了任何必要的資訊或重要限制？
5.是否有重複或相互衝突的需求？
6.所有需求是否都描述得清楚明確？
7.所有需求是否都在專案範圍以內？
8.需求描述內容是否有拼字或文法錯誤？
9.所有需求是否能透過某種方式來加以驗證？
10.所有需求是否都能指出它的來源？
11.品質需求是否都採用適當的數據加以表達？
12.是否有安全性的考量？
13.需求是否真的是需求，而非實作的解決方案，或是問題的描述？

三、會議過程

1.由解釋員逐一唸出並解釋各個需求規格條文中的語意。
2.審核人員比對自己的理解方向是否和解釋員有所出入。
3.審核人員討論並提出對於該需求規格的疑惑之處。
4.需求分析人員回答審核人員提出的疑問。
5.審核人員討論需求分析人員的回答，並加以決議。
6.主持人裁示該需求規格是否通過審核。
7.記錄員記錄各未通過之需求規格的問題與錯誤。
8.記錄員將記錄的內容一一唸出，供審核人員確認。
9.審核人員最後討論決議需求規格書的審核結果：通過、些微修正後直接通過、退回修正重審。

在會議過程中，主持人必須特別注意控制下列事項：

1.對事不對人。審核的是需求規格書，而不是需求分析人員。
2.討論的內容必須符合議程與主題，避免愈扯愈遠。
3.限制爭論與辯駁，將有爭議的問題記錄下來，會後另行討論。
4.提出的問題不必討論出解決方案，可留到會議之後再進一步討論。


四、會議之後

如果需求規格通過審核，且有必要定出各需求實作時的優先次序時，可再加開需求評價會議，訂出各需求的優先次序。其步驟為：

1.將需求分成一定要做的核心需求，和可有可無的一般需求。將核心需求都列為第一優先順位。
2.針對一般需求，利用成本效益評價法，定出其價值，然後依價值高低依次排序需求。

成本效益評價法，是由審核人員對各需求的下列四項因素進行評價（各項分數０∼９）：

1.加入該需求所會產生的利益。
2.捨棄該需求所會導致的損失。
3.完成該需求所需的成本。
4.無法完成該需求可能的風險。

各項因素取平均值後，再依照下列公式計算出該需求的評價值：

(利益 + 損失) / (成本 + 風險)

會議全部結束後，記錄員應整理出會議報告，提供給各審核人員觀閱確認，然後再交由需求分析人員修正需求規格。



參考文獻

1.微軟如何滿足客戶的需求，Karl E. Wiegers原著，許惠丹編譯，華彩，2000
2.軟體工程實務專家作法，第四版，Roger S. Pressman原著，金子葳等人譯，儒林，1998