Needs與requirements之差別，在CMMI框架裡是找不到答案的(至少沒有明顯的答案)。在CMMI架構中，其用語主要係參用IEEE STD 610.12-1991 IEEE Standards Glossay of Software Engineering Terminology.在CMMI的附錄D中，列為IEEE [IEEE 1991]。而在所列的相關用語來源中，是沒有所謂customer needs與customer requirements的釋義的，僅在IEEE Std 610.12列了requirement一項，其意義有三個，(1) 使用者所需要，以解決某個問題或達成某個目標的條件或能力。(2)系統或系統組件必須符合或具備，以滿足合約、標準、規格、或其他以正式方式要求之文件的條件或能力。(3) 如(1)或(2)中所述之條件或能力的文件化表述。當然，在CMMI附錄D中是全文照錄的。而needs，則找不到相關解釋，但是在IEEE Std 1362-1998中，可以找到user need(使用者需要)，其解釋為：系統的一項使用者需求，使用者相信該需求可以解決其所遭遇的問題(A user requirement for a system that a user believes would solve a problem experienced by the user.)。

這樣看來needs與requirements看起來沒有什麼差異。這樣的理解，問題應該出在CMMI架構本身。CMMI架構是以過程為基礎，因此，基礎的生命週期模型(例如瀑布式生命週期模型)被拿掉了，讓生命週期模型變成是一個可以經裁適而選擇的東西，當然，其目的在求取過程的彈性與適用性。當不再重視生命週期模型的時候，有些東西就被忘卻了。customer (或 user) needs，是在生命週期的概念階段要談的，因為使用者或客戶有問題要解決，所以才會有"需要"的產生，通常會以statement of needs 或是Operrational concpets documents來呈現(注意，這些文件是獲取者/使用者的責任)。這份文件是使用者角度的系統描述文件，其內容談的是現行的作法(系統)是什麼，要解決的問題為何，環境情況、新作法(系統)會是什麼，新系統的營運構想、營運情境、可能的衝擊等等。這些資料我們好像在一般的RFP都會提到，但是多半是輕描淡寫，只有系統需求的條列，但沒有營運構想、情境等訊息。當然也是因為使用者/獲取者提不出完整的該等訊息，而造成RFP裡的工作條款寫不出來，更談不到RFP中客戶(含系統)需求的完整性了。

那translate又是在做什麼呢？translate的意義是轉變；變為；賦予某種含義等。

其實customer requirements主要由needs透過分析，轉變或賦予意義而來的。可以從前面提到寫在statement of needs或operational concept document中的問題、新系統構想、環境、營運情境等等轉化而來。客戶需求的充分與完整與分析人員的經驗與能力有關，例如，在statement of needs中，使用者/獲取者可能提到："系統應具有資訊安全保障的能力。"對於需求分析人員來說，轉變出來的客戶需求，可能不只是系統要有防火牆、身分鑑別方法(身分鑑別卡，讀卡機)、防毒軟體，可能會還有人員保密規定、資訊安全作業規範、安全軟體實作規範(因為人也是系統的一部分。)、系統本身也需要成為secure software等等。(這種轉變，有時候會在RFP研提的時候，也可能在委外後，需求分析階段、架構設計階段時迭代實施)。如何translate，分析/設計人員除了需要有經驗外，還可以參考字典是如何運作的。

----------------
引文: