需求收集與分析
前言
需求收集與分析的目的，主要是用來辨別客戶需要的是什麼，其目標在於描述客戶對於專案所預期呈現的結果，然後以有系統的方式加以整理列出。在許多書裡，大都只強調需求完整的重要性，或是列出一些很空洞的施行綱要，但對於實作時，需求要怎麼收集、要怎麼分析幾乎都很少提到，使得無經驗的專案經理往往不知如何著手，只能利用嘗試錯誤的方法摸索進行。因此本文特別著重在需求收集與分析的施行方法與技巧上，這些都是作者多年經驗所累積下來的知識，無論對於有經驗或無經驗的專案經理而言，都是一份極有參考價值的資料。
邱奕南，2009/9/3
套裝類軟體的需求收集
套裝類的軟體產品所面對的客戶，通常是某個族群，即使有了許多已知的客戶，但潛在的客戶往往還更多，因此它的需求會比較模糊而寬廣，難以收集完整，不過相對的，客戶對於某些不符自己所需的地方也不會太過強求，驗收的標準會比較寬鬆些。而我們所要做的，便是儘量收集到客戶的需求（包括未來可能的需求），再依照目標客戶對各項需求的急迫性加以區分，最後視開發的時程與成本，分階段開發出來。以下便是收集這些需求一些有用的做法：
- 由目標客戶找出需求
- 與既有客戶或未來可能的客戶進行訪談或問卷調查，將客戶建議的事項視為需求，逐一列出。
收集需求的最佳方式，永遠都是由客戶端獲得。但由於套裝軟體的客戶群並不固定，因此最好能依照應用領域、運用方式、使用頻率、對電腦系統的熟悉程度、地理位置、職位階層等各種客戶特性，區分出多個目標客戶群，然後針對最重要的幾個目標客戶群進行問卷調查或訪談。
- 參考與軟體產品相類似的專案之建議書、功能規格書或需求變更表，將可能成為需求的部份逐一列出。
開發套裝軟體產品最佳的策略，便是以專案養套裝，也就是在開發初期，利用專案收集需求（同時也可獲利），之後再集結這些需求開發出套裝軟體。因此如果公司已有類似的專案，直接拿來參考即可省下不少需求收集的時間。
- 逐一過瀘類似專案或舊版軟體之客戶問題反應單，思考問題的原因，並將可成為需求的部份逐一列出。
客戶反應的問題中，有一小部份是客戶要求的新功能或功能規格變更，這些問題都意味著客戶的隱藏性新需求。然而在收集需求時，不能直接把客戶要求的新功能直接視為需求列出，而要先去了解客戶提出這項功能的動機與目的。因為客戶在有需求時，往往會先自行想出做法，然後才要求軟體開發商新加功能，此時這項功能已和原來的需求有所差異，若是客戶自行想出來的做法很爛，那麼將它視為需求開發出來的結果，往往便會成為一項雞肋功能（食之無味、棄之可惜）。
- 由競爭廠商找出需求
- 向行銷企劃部或業務部拿取競爭廠商相關資料，找出可成為需求的部份逐一列出。
行銷企劃部在進行市場調查與研究，或業務部在推展業務時，往往都會研究競爭廠商的動態，以及相互間產品的特性。直接找他們拿取資料，最是方便省時。
- 由競爭廠商公布的產品規格書、白皮書、廣告稿與網站資料，找出可成為需求的部份逐一列出。
由於行銷企劃部或業務部的競爭廠商資料大都已經過分析，未必適於收集需求，因此還是必須直接閱讀競爭廠商的實際產品資料來加以研究。至於有那些競爭廠商，則可從行銷人員與銷售人員處取得，或是經由入口網站搜尋取得。而且只要是與產品目標市場與功能特性有沾上邊的廠商，都應視為競爭廠商加以研究。
- 由競爭廠商相關的新聞資料，找出可成為需求的部份逐一列出。
競爭廠商所發布的新聞資料，往往隱含著對方未來的產品規劃與方向，因此必須仔細加以研究，及早因應。
- 由現行資料找出需求
- 將「發展計畫書」中的專案目標與範圍部份，視為需求逐一列出。
套裝軟體要開發，一定有其目的及市場需求，通常在專案開始時，都會列在發展計畫書中，而這些內容也都算是需求的一部份。在記錄這些需求時，要特別注意其品質特性的需求。
- 找出與專案軟體相關的流行技術、界面標準或法令規章，將可成為需求的部份逐一列出。
藉由這方面的需求收集，可確保專案軟體能符合相關的介面標準與法令規章，同時也能符合技術潮流的走向。
- 參考舊版軟體各版本之軟體規格書與技術文件、使用手冊，將其中所列之需求逐一列出。
如果不是全新開發的套裝軟體，那麼舊版軟體的各項文件，便是個極佳的需求資料來源。
- 試用舊版軟體，將其中之各項功能與應改進缺點視為需求，逐一列出。
如果舊版軟體缺乏文件可供參考，試用便是取得舊版需求的唯一方法。不過即使有完整的文件，也可經由試用過程找出缺點，做為新版改進的需求。
- 由未來產品找出需求
- 與核心技術人員、產品經理、行銷人員、銷售人員討論未來套裝軟體可能衍生的產品、相關的產品、以及可能的合作廠商整合方式，在討論內容中找出可能的需求，逐一列出。
藉由這種方式，可以找出未來功能擴增的可能需求，以及應提供出來的界面需求，強化軟體的擴充性與公用性。
- 列出現行所有的核心技術，並參考其相關文件，找出加入時可成為需求的部份逐一列出。
套裝軟體現行規劃的目標，不一定全用到所有核心技術，因此必須將所有將來可能加入的核心技術都列出，並思考加入時可能會造成的需求。
- 自己思考或詢問同事對該產品的新點子。
如果自己創意夠的話，花些時間好好想想，有時能提出一些不錯的功能，或是被忽略掉的需求。
- 由模擬方式找出需求
- 找出一個或多個專案軟體運用的例子，模擬其運用過程，由過程中找出遺漏的需求。
由於套裝軟體沒有很明顯的客戶群界限，要鑑訂是否有遺漏的需求，最好的方式便是仿造幾個客戶使用的可能例子，在其作業的過程中來驗證是否有遺漏的需求。
- 利用系統分析技術，如結構化分析中的資料流程圖（Data Flow Diagram，簡稱DFD）和物件導向分析中的使用案例（Use Case）等，定出容納所有需求的系統模型，並檢查各需求相互間的關係，以試圖找出未明白列出的隱藏性需求。
這是需求收集的最後一道防線，主要目的便是運用需求的交互關係，來找出隱藏性未列出的需求，使得各項需求緊密連繫在一起。同時藉由建構此一系統模型，也容易檢查出相衝突的需求。這個方法可以延到需求分析的篩選過程中進行。
客戶訂製類軟體的需求收集
客戶訂製類的軟體產品，它的需求通常都有一個相當明確的範圍，因為客戶是已知且有限的。不過這類軟體的需求反而不易收集，主要是因為客戶對於軟體的要求會比較高，而且客戶也往往存在有許多易變的或隱藏的需求，特別是連客戶自己也搞不清楚自己要的是什麼的情況下。這時，我們必須斟酌情形給予客戶適當的建議，儘量讓客戶充份了解到自己實際的需要，否則再怎麼收集需求，最後還是會一變再變，徒勞虛功。以下便是一些運用在這類軟體的需求收集步驟與方法：
- 閱讀並分析客戶交予的需求文件：當客戶訂製類軟體專案一開始，一定都有客戶提供的需求文件或規格書，閱讀這些文件並將各需求逐一條列出來，這是收集需求的第一步。接著，找出各需求的相關性，將語意不清、相互衝突、不知目的、缺少關連的需求表列出來，做為下階段客戶訪談時所要了解的內容。其中在閱讀分析時，要特別注意非功能性的品質需求，因為這部份無論在客戶訪談或原型中，都是很容易被忽略的。
- 安排初次客戶訪談以收集專案相關資訊與需求：在訪談前應先告知客戶訪談的計畫與內容，以節省訪談所需的時間。而初次客戶訪談的目的，除了讓雙方在面晤交談的過程中，增加彼此間的信任與了解外，還包括下列的目的：
- 了解並認識與專案相關的人員，包括使用人員、使用單位主管、承辦人員、承辦單位主管、上級主管等。
- 討論並協調當各使用單位或主管在需求上有衝突時，應由誰進行決策，以避免多頭馬車、懸而不決的情況。以下是一些建議的決策人員，可依實際情況加以調整：
- 開發人員與客戶之間：由客戶決定，不過要提供一些建言，因為客戶不一定是對的。
- 承包商與客戶之間（即我們是別人的外包商）：由客戶決定，承包商與客戶間再行協調。
- 承辦人員與承辦單位主管之間：由承辦單位主管決定。
- 承辦單位與使用單位之間：由使用單位決定。
- 不同單位的使用人員之間：由上級主管協調決定，或由使用頻率最高的使用單位決定。
- 使用人員與使用單位主管之間：由使用人員決定。
- 同單位多個作業不同的使用人員之間：由單位主管協調決定，或由使用頻率最高的作業人員決定。
- 同單位多個相同作業的使用人員之間：由資深人員決定。
- 了解專案的背景，詢問並澄清客戶需求文件中有疑問的內容。
- 了解客戶現行作業的流程與處理方式，以及專案軟體在這過程中扮演的角色。如果客戶無暇提供現行作業的資料，最好的方法便是另行安排時間，觀察客戶一日的作業情況並加以記錄分析，最後再與客戶討論確認。
- 建立客戶作業模型找出需求：了解客戶的領域知識，並建立客戶現行與未來作業的模型（可利用DFD或Use Case），從中找出客戶未提及的需求，或是該領域中常識性的需求。模型建立後，應再與客戶確認作業模型的正確性，但記得要將模型改用最常見的步驟化方式來描述，並忌用技術性字眼（最好使用客戶領域的專業術語，可建立一個專案詞彙表做為參考）。如果未來作業的模型有多種可能，都應該全部告訴客戶，由客戶來自行決定（我們可從旁分析與建議）。
- 利用原型收集及確認需求：原型是提供客戶確認需求的最好方式，主要是因為它看得到，特別容易挖掘到客戶一些細微的隱藏性需求。不過利用原型模式會多費一些人力時程，在時程與成本的控制上要特別小心。
- 最終需求確認：不要枉想一定能和客戶簽下需求確認合約，因為絕大部份的承辦人員或使用單位都不願意配合（當然可能的話是最好，不過即使簽立確認合約，也不可能避免需求變更）。適當地採用原型來進行需求確認，比較能減少將來需求變更的機會，不過同樣要注意原型展示時的客戶參與對象。但是無論客戶是否願意簽下需求確認合約，都要讓客戶了解到（最好寫在文件中），將來需求的變更都會導致成本與時程的改變，甚至必須重新協調專案的價格與時間表。加強對客戶觀念的灌輸與溝通，有時比單純簽約保證，更有利於專案的順利進行。
在實務上，確立專案真正的決策單位與人員相當重要，否則常會發生專案進行至一半，卻被更高階層全面否決原先已談好的需求，或是不同使用單位各自堅持相衝突需求的情況。在進行需求訪談時，必須特別注意這點，以免徒勞無功。
需求分析的步驟
一份好的需求規格書，必須要能達到下列的品質要求：
- 完整性：列出的需求必須涵蓋使用者的所有需求。
- 必要性：不可有贅餘無用的需求。
- 正確性：不可有錯誤的需求。
- 一致性：不可有相衝突的需求。
- 清晰性：需求描述的方式必須一看就懂，且不會有不同的解釋。
- 可行性：所有需求皆必須能夠實現。
- 可測試性：所有需求皆必須可加以驗證測試。
這些品質要求，有些需要藉助需求規格正式審核會議來檢驗，但在需求分析過程中，應時時自我檢驗是否達到這些要求。以下便是需求分析時，應執行的步驟與內涵：
- 記錄：在需求收集階段裡，任何收集到的需求，一定都要馬上建檔集中記錄下來，避免遺忘或漏失。記錄的同時，應該同時標示需求獲得的來源，以供將來審核需求必要性時的參考。
- 推究：針對前述記錄下來的需求，判別是否屬不是需求的需求，然後進行因果關係分析，找出實際隱含的需求。不是需求的需求，包括帶有技術解決方法的需求、舊系統的局部改良建議、對軟體工程相關的要求等。進行因果關係分析時，應思考該需求是否為了解決其他需求而設，以找出更深一層的實際需求，然後對所得的需求再進行相同的因果關係分析，直到找出所有隱含的需求為止。
- 分類：對推究後所得的實際需求，進行分類的動作。一般先依子系統或系統作業項目分類，然後再依作業流程、企業規則（即作業流程運作規則）、功能需求、外部界面需求、限制、非軟體性品質需求等類別進行分類。如果某個類別（特別是功能需求部份）有太多的需求時，應再依需求的性質進一步分類。分類完畢後，應檢查各預定的類別中是否都已有相關的需求列出，如果有缺少的部份，多半表示完整性不足，應再進行需求收集的動作。如果難以找出適當的分類類別，可直接從資料處理面（含資料流向）、操作面（如人機界面、作業流程）、管理面（如管理設定、安全控管、報表、備份）等三個層面來思考找出。
- 歸納：將同一類別中，相同或類似的需求加以合併，避免有重複的需求。
- 分解：將範圍太大的需求再進一步加以了解並細分，以利後續需求的精鍊定義。每個需求描述儘可能只有一項單純的要求，避免使用及、或等連接詞一次表達多個要求，或是使用所有、各種、完整、詳細、進階、其他等不明確範圍的形容詞。細分出來的需求必須重新以先前的分類、歸納步驟處理。
- 精鍊：將模糊不清的需求定義清楚，該標示品質特性的地方要予以標示，而能量化的地方則儘量以數據量化。要確認各項需求是否定義清楚，只需將該項需求交給數人觀看，如果對方看不太懂，或出現了兩種以上的解釋，便表示該需求還是模糊不清的。若實在難以用文字描述清楚，也可採用舉例、圖示、公式等方式來表達。
- 預審：預審的目的，便是確認各需求是否皆已定義清楚，亦即容易明瞭且僅有唯一解釋。預審時，每次找一個人，最好是與該專案無關的人，然後請他逐條解釋該需求的內容（自己不可解釋），若對方無法解釋，或解釋結果與實際所要表達的不同，表示該需求還是模糊不清，必須重新撰寫改良。在這個步驟裡，可進行多次預審來確保需求的清晰性，一般要求至少三次以上。
- 篩選：討論、評估需求的必要性（需要客戶參與），並檢查需求的一致性，淘汱掉不需要的需求、或相互衝突的需求（也可加以折衷）。最好能事先用系統分析方法建構出系統的初步模型，來加以檢驗需求是否有所衝突。
- 評估：對各項需求，進行成本效益、可行性等風險評估，確認各需求皆為可行。視情況必須依照專案的各種限制條件，去除掉一些不可行的需求（仍需與客戶討論確認）。
- 撰寫：將最終的需求寫成需求規格書。撰寫時應對每項需求給予一個固定編號，以利將來的分析設計與需求變更時的追蹤。撰寫後，應再進行數次非正式預審，以減少正式審核時的爭議。
- 審核：對需求規格書中的需求進行正式審核，確認各項需求清楚、完整，以及它的適用性（審核前數日應先行將文件送交審核人員處）。如果審核人員對最終需求有所疑慮或意見，應再依前述步驟重新修正過。審核人員通常由專案經理、系統分析師、系統設計師、資深程式設計師、測試人員各派一名代表（可兼任），再加上數位客戶代表共同擔任，但人數最好不要超過7人（不含需求分析人員），超過時可改成分組討論的方式進行審核。但無論如何，一定要儘量讓客戶代表參與，因為只有客戶代表才有權決定需求的適用與否。如果是套裝類軟體，客戶代表則可由產品經理、行銷人員、業務人員、或現行客戶擔任。審核時，應對需求逐條檢閱，並賦予各審核人員主要的審核角度，同時審核過程也應以正式文件加以記錄。
- 排序：討論並決定各需求實作時的優先次序（仍由參與審核的人員擔任）。這是因為在開發過程中，可能會因為時程或成本的關係，捨棄掉一些不重要的需求。其訂定的方式，一般可先將需求大致區分為必做的核心需求，與可有可無的一般需求。先將核心需求列為第一順位，接著再採用成本效益評價法，排序剩下的一般需求。成本效益評價法可採用下列公式計算，其中各值可以1～9的分數加以評量，開發風險也可設成0：
(加入產生的利益+捨棄導致的損失) / (開發成本+開發風險)
- 定案：將審核過的需求規格書視為需求基準，納入組態管制，做為系統分析時的依據。
參考文獻
- 軟體工程實務專家作法，第四版，Roger S. Pressman原著，金子葳等人譯，儒林，1998
- 軟體發展指引（SDG 2.0），資策會，1988
- 微軟如何滿足客戶的需求，Karl E. Wiegers原著，許惠丹編譯，華彩，2000
- 微軟開發快速秘笈，Steve McConnell原著，鄒正平譯，華彩，1999
- 系統開發－分析、設計與製作，林淑芬譯，碁峰，1991
- WebGenie 2.0版再造工程專案需求收集計畫，邱奕南，2001