關於這個議題，我想補充一下。

首先還是回到IEEE Std 610.12對需求(Requirement)的定義：
(1) 使用者為了解決某個問題或達成某個目標所需要的條件或能力。(2)系統或系統組件為了滿足合約、標準、規格、或其他正式提出的文件，所必須符合或具備的條件或能力。(3) 記錄(1)或(2)中所述之條件或能力的文件。

其中(1)+(3)就是客戶需求，(2)+(3)就是系統、產品或軟體需求，端視這個系統所指為何而定。任何系統、產品或軟體的開發都是由於客戶“需要”解決某個問題或達成某個目標而展開。換句話說這個客戶要解決的問題或要達成的目標就是“客戶需要(Customer Needs)”。而客戶為了解決這個問題或為了達成這個目標所須具備的能力或條件，就是客戶需求(Customer Requirements)。客戶需要是在問題領域(Problem Domain)，而客戶需求已進入解決方案領域(Solution Domain)。將客戶需要變成客戶需求，是一種具象的轉換過程。在需求工程中須將客戶需求再進一步的具象化，使其成為某一系統/產品或軟體必須具有的能力或條件(這就是系統/產品或軟體需求)，以協助客戶解決問題或達成目標。

一般而言，“客戶需要”以問題陳述(Problem Statement)、 statement of needs 或是Operational concepts documents來呈現。“客戶需求”會記載於RFP中，過去它通常以條列的方式陳述，現在也有人以使用案例 (Use Case)來呈現。“系統需求”通常記載於需求規格書(SRS)中，通常以分析模型(Analysis Model)來呈現。當RFP以條列的方式陳述客戶需求時，在需求規格中同時納入使用案例模型和分析模型也是可以的。

希望以上的補充能對各位有所幫助。最後還是祝福大家 能力精進！工作順利！！


周茂松　敬上