需求分析 (Requirement Analysis)

2020/05/30 (增加內容)
2021/03/19 (微調內容)
2022/05/09 (增加連結)
2022/06/13 (增加連結)
2024/02/14 (重整內容)
2025/02/25 (新增投影片)
2025/04/20 (新增連結)

簡介

需求分析是相當重要的一件事，過去，我曾經犯過一個錯誤，我花了很多時間設計了一個系統，使用者原本是希望能輸入產品編號，我覺得這樣的需求很糟，應該提供一個下拉式選單，讓使用者可以點選產品，我覺得這才不會讓使用者選錯產品，結果，這個公司的產品編號是物品編號，是每個客戶儲存在該公司的物品編號，而每個客戶儲存上千上萬個物品，這樣的設計要讓使用者拉很久才能找到編號，當時，我認為好的改變卻是完全不符合需求的設計。

再以最近參與過的專案為例，一開始，開發者假設輔導室的老師會上傳學生的姓名、身分證號碼及班級資料，後來，才發現對於輔導室的老師而言，是需要透過教務處取得這些資料，而且，輔導室老師工作相當繁重，把學生資料的管理工作交給他們是不可行的，如果，這樣的問題一直到系統上線才發現，輕者可能會導致延後上線時間，重者可能會因此喪失先機，被競爭者搶走先機，導致系統失敗。

• The Most Important Lesson about Software Development from the Past 50 Years 

  • A usage-centric approach to requirements and design will meet customer needs better than a feature-centric approach.

  • I recommend that BAs shift requirements conversations away from the product itself and toward what users need to do with the product. We change the emphasis from functionality to usage, from the solution to the need. 

需求引出/獲取 (Requirement Elicitation)

現在我們都會使用需求引出而非需求收集，來強調獲得使用者的需求不只是靠收集需求，而且是要有技巧性的找到需求。所以，一般在使用者訪談之前是需要做一些功課，比如說先藉由公司相關文件(如：網頁)，先了解公司的營運狀況，並且收集系統相關的文件(如：表單、報表)，對需求先做初步的了解，再進一步透過訪談，釐清一些細節。

取得需求的方式很多，有些是靠閱讀使用者所提出的需求建議(或問題)，有些是透過訪問使用者。當使用者很多的時候，會先經由使用者代表了解需求，再透過座談會或甚至問卷調查來確認。

訪談

當我們進行訪談的時候，Satzinger, et al.(2013)建議需求收集通常要問三種問題:什麼是企業的流程? 企業流程的效率如何? 什麼資訊是需要的? 問的題目可以是開放式的題目或非開放式的題目，開放式題目通常會需要很多的討論與解釋，如:「你們怎麼做這件事?」，非開放式題目通常是期待得到具體的事實，如:「你一天處理幾份表單?」一開始通常是由開放式的題目開始，後來就會有很多的非開放式題目。另外，還要注意使用者談的是現有的系統或做法，還是對新系統的期待，如果只注意現有的做法，可能只是把現在的做法電子化罷了，無法真正的解決問題，如果只注意對新系統的期待，也可能會忽略現有系統或做法的問題，所以，必須要了解現有的系統或做法以及對新系統的期待。

一般而言，如果使用者很清楚，如:部門主管，通常會透過使用者的需求訪談確認系統的範圍及主要的功能。當使用者的數量比較多，往往使用者的看法會是不一致的，所以，必須進行多次的訪談，並分析出需求的差異，並請主要的使用者，如:部門主管，做最後的協調或確認。

通常要進行訪談前，會先整理一些問題，讓受訪者能事先準備，在訪談後，會對訪談內容進行整理，會對受訪者進行確認，也會順便澄清一些訪談內容的疑義。

從過去的經驗來看，使用者並不一定可以很清楚的講出需求，往往是想像自己的需求，等看到系統之後，才會發現雖然系統是依照需求開發，但並不是自己真正要的。所以，一個有經驗的系統分析師，最好是有相關系統的開發經驗，或者對使用者的環境有足夠的了解，以避免開發出使用者不需要的系統。 

焦點群體法、工作坊、問卷調查或觀察

大部分的系統使用者相當的多，如選課系統的使用者是全校的同學，不可能利用訪談去訪問所有的同學，所以，往往會訪問具代表性的使用者，如選課系統通常會先訪問課務組的同仁，從課務組同仁的建議中先有個初步的概念，再利用焦點群體法訪問一些系所秘書、學生代表，如有必要，會透過問卷調查來抽樣確認同學們的想法。

現在也有一些系統並沒有特定的使用者，(如：線上遊戲)，使用者的需求往往是比較不明確的，雖然如此，最好還是要選定一些目標使用者，才有辦法去找出初期的系統需求，比如說：有些人會將使用者定為線上遊戲愛好者，這樣的使用者定義就過於廣泛，最好還是要選定特定族群(如：大學生)，先以特定族群為初期的目標使用者，才有辦法進行需求分析，否則也會造成系統很難有特色，選定特定族群後就可以進行抽樣問卷調查或利用焦點群體法或利用工作坊來收集需求。利用焦點群體法或利用工作坊的好處是可以利用比較短的時間聽到較多人的想法，但壞處是有可能只聽到部份人的聲音，所以，要注意到是否發言被少數人所壟斷。

可以利用系統的雛型或初步的系統，透過工作坊讓使用者實際的試用雛型或初步的系統，並且配合訪談、觀察或問卷調查來收集資料以發現雛型或初步系統的問題。

如果已經有現有系統或類似系統(如:競品)，可以利用觀察法，實際觀察現有的作業流程，或觀察類似的系統，收集類似系統所具備的功能及優缺點，來找出系統需求。現在有很多公司會收集使用者的使用頻率及使用路徑，利用使用頻率了解哪些功能常被使用，了解哪些功能不常被使用，並且會有目標的使用路徑並比較實際記錄的使用路徑，以了解使用者是否因為介面設計不良而停止使用或一直卡在哪個步驟。提供這些資料給設計人員做為改進的參考。

請注意，訪談雖然通常是以一對一方式進行，但也可以搭配焦點群體、工作坊來進行，觀察法可以針對個人觀察，也可以利用工作坊進行團體觀察。問卷調查可以獨立進行，也可以搭配工作坊來進行。

• 16 Good Practices for Requirements Elicitation (Friend Link)

系統需求

系統需求又分為兩大類：功能性需求及非功能性需求，一般都會忽略掉非功能性需求(如：最低同時使用系統人數、最低系統回應時間、安全性)。(細節請參考Ashrafi & Ashrafi, 2009, pp.105~108)

有些人會把需求分為功能(Functionality)、可用性(Usability)、 可靠性(Reliability)、效能(Performance)及可支援性(Supportability)  (詳參: FURPS)，大部分教科書所列的與FURPS大同小異。如:

• Ashrafi & Ashrafi (2009)提出五大類型的非功能性需求: Usability、Reliability、Performance、Maintainability。

• Satzinger, et al (2012)認為需求可以分為:Functional requirements、Usability requirements、Reliability requirements、Performance requirements、Security requirements (FURPS)，再加上Design constraints、Implementation requirements、Interface requirements、Physical requirements、Supportability requirements (FURPS+)。

要注意的是遵循法規上(如:資訊安全、個人資料保護法)的要求，通常可以從組織/公司的內部規範裡找到這些要求或規範。

非功能性需求

如果在需求分析階段忽略非功能性需求，就很有可能在系統上線時，才發現非功能性需求成為系統的關鍵失敗因素，比如說:有嚴重的資安漏洞 (如: 北市府智慧支付平台 pay.taipei 剛上線就下線，原因竟是機敏資料未使用 HTTPS 加密)。非功能性需求往往不是使用者會注意到的，所以，一般而言，會透過過去的經驗去檢查是否有遺漏重要的非功能性需求。

可用性 (Usability)

可用性是個很複雜的學問，簡單的說就是系統要可使用或容易使用，例如，曾經有同學設計系統給幼稚園小朋友，但是，系統中卻都是以文字方式引導，這就沒考慮到幼稚園小朋友不認得國字，完全不符合可用性。

可使用的概念中，還有一項很重要的概念就是accessibility，強調能讓所有人都能使用，就一般的網頁而言，要考慮到視障的使用者。

• 【無障礙網頁祕技】

  • 認識無障礙網頁與分級

  • 前端切版前要注意什麼細節呢？

  • 介面設計大補丸

可靠性 (Reliability)

可靠性主要是系統的穩定程度，量測的指標通常有Mean Time Between Failure (MTBF)或者Mean Time To Recovery (MTTR)。系統要能夠穩定有很多考量的因素，最常見的問題是流量，也就是不能因為流量而導致系統無法使用，另外，資訊安全也是另一個影響可靠性的因素，有可能因為有資安漏洞而導致系統無法使用。流量的部分，通常是靠壓力測試來了解是否能在某個流量下維持正常的運作。

效能 (Performance)

量測的指標通常是最高回應速度門檻，例如，每一頁的回應速度不得超過1秒。效能與可靠性常常是高相關的，當效能低的時候，常常可能就是系統不穩定的前兆，以流量而言，當使用者的數量提高之後，通常的問題是系統反應速度開始變慢，接下來可能就是系統無法使用了。資訊安全也一樣，當駭客開始攻擊時，通常一開始就是系統或網路速度降低，接下來就是整個系統癱瘓了。所以，效能可以是可靠性的第一道防線。

安全性 (Security) 

安全性除了會影響可靠性、效能之外，還有另一個問題是資料外洩，在個人資料保護法上路之後，資料外洩是會被處罰款的，所以，資訊安全的重要性也越來越高。通常資訊安全的基本要求有：

• 確保本系統內機敏資料不被外洩、竄改、毀壞

• 確保系統及相關處理必須安全

• 確保系統不受網路惡意攻擊

所以，為達到以上要求，資訊系統就應該有一些基本的功能，例如：儲存在資料庫中的帳號密碼必須要加密，系統上線前必須通過弱點掃描測試，系統不得有常見的弱點。

其他

還有其他的非功能性需求，例如，有些公司會要求系統要容易維護、程式的可讀性要很高、要有完整的說明文件等等。有些會有軟、硬體上的需求，例如，系統要能在手機上使用或者要能夠在現有的設備或作業系統上執行。也有一些公司會要求介面設計風格，例如，公家機關會希望系統能有穩重的感覺，而針對小朋友的系統則會希望能有活潑的感覺。

功能性需求

功能性需求就是系統應該提供哪些功能，通常透過User Story或Use Case紀錄。

從敏捷式開發的觀點來看，通常利用User Story來記錄需求。通常需求有兩個面向，一個是從使用者觀點來看，由使用者描述希望系統能做些什麼以便達到什麼目的，另一個則是從開發者的角度，分析並統整使用者的需求。User Story通常強調三件事: 使用者是誰? 使用者要達到的目的是甚麼? 使用者為了達到目的，需要甚麼樣的功能。這三件事，尤其是前面兩件事，是從使用者的觀點來看。然而，為了更明確的讓開發者了解使用者的需求，通常還會使用User story的驗收條件(或測試案例)來明確的陳述使用者的具體需求(詳參: 使用者故事)，當然，也可以利用雛形介面來說明具體需求 (詳參: 敏捷開發需要哪些文件?)。

就傳統的瀑布式開發的觀點而言，在收集系統需求後，接下來可以利用Use Case整理需求，Satzinger, et al (2012)建議利用三種方法：使用者目標法 (User goal technique)、事件分析法 (Event decomposition technique)、CRUD法 (CRUD technique)。簡單的說，使用者目標法就是去確認需求是否滿足使用者的所有的目標，接下來，利用事件分析法去確認是否包括了每個會發生的事件所對應的動作，最後，用資料的新增(C)、讀取(R)、更新(U)、刪除(D)，再次去確認是否有遺漏的動作。

需求管理

如果採用Scrum，在Sprint Planning時就要決定哪些user story排在這個sprint。所以，就敏捷式開發的觀點來看，所有的User Story都應該有優先順序，依優先順序開發。

就傳統的瀑布式開發的觀點而言，需求管理的方式就不太一樣。Ashrafi & Ashrafi (2009)建議幾個需求管理的重點:

• 記錄並更新需求 

• 記錄需求的來源

• 將需求分割為個別的單元 (distinct units) 

• 個別的命名(identify)每個需求

• 確認需求並且將確認記錄下來

• 排需求的優先順序

  • 當系統使用者很多的時候，就必須找到主要對口單位或主要負責人(如:主管)來確認優先順序，免得排不出優先順序。

• 將需求有意義的分類 

• The 6 Most Important Requirements Practices 

  • Practice #1: Define Business Objectives

  • Practice #2: Understand What Users Need to Do with the Product

  • Practice #3: Prioritize the Requirements

  • Practice #4: Explore Nonfunctional Requirements

  • Practice #5: Review the Requirements

  • Practice #6: Plan for Requirements Change

• Keeping the Project Scope in Focus : Defining clear business requirements for a project lets the team make scoping decisions to stay focused on successful delivery.

常犯的錯誤

• 只注意到部分的使用者，所以，只滿足部分使用者的需求。有時候會發現雖然功能開發好了，但是，因為只滿足部分使用者的需求，系統還是無法運作。例如，只滿足買書者的需求，未滿足賣書者的需求，所以，買書者無書可買，對買書者而言，系統完全沒有價值。

• 只記錄需要甚麼樣的功能，並沒有記錄原因。有時候會發現雖然功能開發好了，卻完全無法(或無法完全)解決使用者的問題。

• 並未明確的紀錄需求，常常會發生開發團隊誤會使用者的原意，一直到使用者測試才發現完全弄錯了。例如，只記錄需要依日期排序，系統依上架日期排序，但是，消費者要的是依出版日期排序。

• 忘了更新需求，一直到使用者測試才發現需求並未更新。

• 常常沒有記錄需求的來源，如果只是記錄「使用者說」或「學生認為」，就會發生系統需求到底從哪裡來完全沒有人知道。當細節有問題時，就不知道需求的細節要和誰確認的問題。

• 有時候不去排優先順序，會發生開發者花很多時間在不重要的功能，或者來不及完成使用者最在意的功能。排優先順序除了重要性之外，還要注意功能相依性，例如，雖然買書的功能比賣書功能重要，但是，如果賣書的功能未完成，無書可買，買書功能就沒有用了，相同的，沒有人可以買書，能賣書也沒有用。所以，這時候可能需要先有基本的買賣書功能，例如，一開始並沒有很多書，書籍的分類及搜尋功能就不急著開發。

• 如果是關鍵性的需求，就要和所有使用者(或使用者代表)確認，尤其是當不同使用者有不同(甚至互相衝突)的要求時，就必須要花很多時間去重新詢問所有相關的使用者，萬一再加上需求也沒寫得很清楚，甚至還必須花更多時間來來回回的去跟使用者確認。

• 另一個常犯的錯誤就是忽略或遺漏重要的非功能性需求，尤其，學生時代的系統資料量都不大，真實的系統通常資料量都很大，可靠性與效能等非功能性需求就會很重要。