敬請註冊 ... !    登入
關於本協會
登入
軟體品質資源專區
主選單
最新討論文章
討論區主頁
   軟體工程管理
     Needs and Requirements
無發表權

樹狀顯示 | 新的在前 前一個主題 | 下一個主題 | 頁尾
發表者 討論內容
joker
發表時間: 2010-03-12 09:09
Not too shy to talk
註冊日: 2006-12-22
來自:
發表數: 31
Needs and Requirements
在CMMI-ACQ V1.2 P41有一段話:
“Customer needs are established
and translated into customer requirements.”
請問Needs與Requirements之差別為何?上述之轉換程序(translated)為何?

tyrone
發表時間: 2010-04-03 16:33
網站管理員
註冊日: 2003-04-19
來自: CSQA
發表數: 342
Re: Needs and Requirements
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,分析/設計人員除了需要有經驗外,還可以參考字典是如何運作的。


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

凡所有相皆是虛妄。見諸相非相。即見如來。

林泰龍
◎軟體品質協會 理事
◎經濟部標準檢驗局資訊及通信國家標準技術委員會(TC21/SC3資訊軟體分組委員會)委員
Youtube Channel: http://www.youtube.com/user/tyrone9304

albertchou
發表時間: 2010-04-03 21:29
Just can't stay away
註冊日: 2003-04-21
來自:
發表數: 71
Re: Needs and Requirements
關於這個議題,我想補充一下。

首先還是回到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以條列的方式陳述客戶需求時,在需求規格中同時納入使用案例模型和分析模型也是可以的。

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


周茂松 敬上
tyrone
發表時間: 2010-04-03 22:00
網站管理員
註冊日: 2003-04-19
來自: CSQA
發表數: 342
Re: Needs and Requirements
由於Customer needs是由使用者/獲取者所提出,為了避免不必要的麻煩,或者讓一般的使用者(絕大多數都沒有技術背景)再去學習新的表示方法,statement of needs/operational concept documents要讓不論是使用者代表或者使用者群中的一員,都可以看得懂,故應該要避免使用USE CASE diagrams/Activity diagrams/ sequence diagrams等,而是用使用者所可以看得懂的圖(例如,概念圖、方塊圖、流程圖、時線圖等),再加上文字描述。statement of needs /operational concept documents不見得一定是要有技術背景的人才能提。因為,這份文件純粹就是問題的提出及問題的解決方案,而解決方案中,也不必然要涉及技術,儘可能把技術相關都當成黑箱。因為這些與技術相關的東西,未來可能是硬體的,也有可能是軟體的,也有可能會化為人工作業流程,如果一下子就寫死,就有可能會造成技術過時、成本過高、或過於繁瑣等狀況。所以,技術的部分,就留給架構設計、軟體需求分析、初步設計階段再去探討吧。

OCD要像是一本描述系統的故事書(系統是如何打敗企業惡魔的)--從為什麼要有一個系統,系統會經過什麼歷程,在什麼環境或條件下,用什麼方法或能力打敗這些惡魔。就是說故事,不要太技術。要讓一般的使用者都可以看得懂,這樣子才能夠集思廣益地審查這份文件。

另外,不是個人挑剔,大家可以再想想,translate 與 Design又有何不同。在概念階段裡,為何用translate,而不用design?在概念階段後,接著是系統的架構設計(architecture design)階段。

在系統建置案RFP當中,應當提供的資訊應該還要包括:計畫的WBS(PWBS幾乎都漏掉)、工作條款(SOW)(常常寫不清楚)、營運構想文件(OCD)。系統工程作法裡,合理的工作流程是statement of need -> OCD -> PWBS -> SOW -> RFP。當然每個一文件(資訊)產出活動可以是迭代的。常聽到有獲取者叫廠商提SOW來參考,最主要的就是不知道如何提需要、營運構想與情境,所以WBS出不來,當然不就不知道怎麼提SOW了。


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

凡所有相皆是虛妄。見諸相非相。即見如來。

林泰龍
◎軟體品質協會 理事
◎經濟部標準檢驗局資訊及通信國家標準技術委員會(TC21/SC3資訊軟體分組委員會)委員
Youtube Channel: http://www.youtube.com/user/tyrone9304

樹狀顯示 | 新的在前 前一個主題 | 下一個主題 | 頁首

無發表權
 
-=協會通訊地址:330047 桃園市桃園區大林路100號6樓 =-
電話:(03) 367-8567 電子信箱:register@csqa-tw.org.tw=-
-=本網著作權為中華民國資訊軟體品質協會所有,禁止未經授權轉貼節錄=-
Powered by XOOPS , Twe76.net