敬請註冊 ... !    登入
關於本協會
登入
軟體品質資源專區
主選單
最新討論文章
討論區主頁
   軟體需求規格
     最好的需求書規格為何?
無發表權

樹狀顯示 | 新的在前 前一個主題 | 下一個主題 | 頁尾
發表者 討論內容
johnlcyuan
發表時間: 2007-01-08 22:17
Just popping in
註冊日: 2007-01-08
來自:
發表數: 1
最好的需求書規格為何?
請問一下各位先進最好的使用者需求規格書的格式在台灣比較普遍的是哪一種?謝謝!
Terry
發表時間: 2007-01-10 12:08
Just popping in
註冊日: 2005-04-11
來自:
發表數: 19
Re: 最好的需求書規格為何?
我發現本網站首頁的 [ 演講簡報 ] 檔案下載區有一個 [ How to Produce a good SRS ] 的課程講義, 不錯喔, 登錄會員都可以免費下載來參考.

此外, 我看到 1/27 軟體品質協會也有預告將要再開 [ 如何撰寫需求規格書] 的課程 !
albertchou
發表時間: 2007-01-11 21:19
Just can't stay away
註冊日: 2003-04-21
來自:
發表數: 71
Re: 最好的需求書規格為何?
首先,我們要了解“使用者需求”和“軟體需求”其實是不同的東西,“使用者需求”是寫在RFP(Request for Proposal)或變更申請單(Change Request)中的。而“軟體需求”是記載在軟體需求規格書,即通稱的SRS(Software Requirements Specification)中的。所以,在軟體工程的世界中根本就没有“使用者需求規格書”。

其次,“最好的……需求規格書的格式”這個敍述也是有問題的,因為没有所謂“最好的格式”。軟體需求規格的格式與組織需求資訊的方法不同而不同,無所謂“最好”或“最壞”。說得更明白一點就是:它因軟體本身的特性,開發軟體的組織(或委託開發軟體的組織)以及軟體所處的環境(Context)而異。所以,在軟體工程的世界中根本就没有“最好的需求規格書”。

建議您不妨參閱IEEE-Std-830-1998,IEEE Recommended Practice for Software Requirements Specifications。相信您在那裡面應能找到滿意的答案!

軟體品質協會資深管理師 周茂松 敬上
Member
發表時間: 2007-06-27 17:41
Not too shy to talk
註冊日: 2005-04-07
來自:
發表數: 29
Re: 最好的需求書規格為何?
我相信可能很多人都不知道「軟體需求規格書 ( SRS )」和「徵求建議書 ( RFP )」的區別,其實 RFP 只是籌獲方在完成資訊系統需求規劃後,對供應方提出軟體需求功能的『概要描述』,資訊系統供應方在確定承做後,應依據 RFP 的『概要描述』對籌獲方的使用者進行深入訪談、確認需求細節,進一步提出需求分析、軟體規劃、功能規格 ( 含其與 RFP 功能需求的對應回溯表 ),完成「軟體需求規格書」經籌獲方審核簽認後,做為未來驗收軟體的準據之一,也是下一步交給程式設計人員開發軟體的「軟體設計說明書 ( Software Design Description,SDD )」的參考來源。

如果籌獲方在委請供應商承做軟體開發設計之前已經完成「軟體需求規格書」,那麼「軟體需求規格書」就成為「徵求建議書 ( RFP )」的一部份,供應方只須依據 RFP 的「軟體需求規格」提交「軟體設計說明書 ( SDD )」送審核即可。

如果以營建工程來做比喻,「軟體需求規格書 ( SRS )」就是設計藍圖,「軟體設計說明書 ( SDD )」就是施工圖,前者是籌獲方驗收的重要依據,後者是未來軟體系統維護、更新的重要參考。

因為軟體系統在開發期間可能會有需求變更或修正,因此「軟體需求規格書 ( SRS )」和「軟體設計說明書 ( SDD )」也需要配合修訂,並且確保軟體系統在完工驗收時,文件內容必須與最新版本的軟體一致。
alex.yin
發表時間: 2007-11-01 08:27
Just can't stay away
註冊日: 2007-09-04
來自: 國防工業發展協會
發表數: 77
需求規格書與採購
1.政府採購策略(以美國政府為參考)希望專案需求明確以易於估價,所以通常PM需要在發RFP之前將需求弄清楚。因此在Traditional Requirement Engineering中介於買方Acquirer與發展方Developer或Supplier中間有一道透明牆(Wall),在Wall的上游是甲方要執行完整的Requirements Development,在Wall的下游是乙方要進行需求變更管理的Requirements Management。Acquirer要在RFP中敘述Specification,Specification用以說明專案所要採購的Goods (當然,要有Specification之前,先要有WBS),也就是所謂的“What”。等於是邀請Supplier由Waterfall mode的“System Requirements Analysis/Design”開始執行(參考DoD-STD-2167)。1998年之後美國政府希望用Performance Based Specification,也就是PM要敘述所謂的“How Well”方式。有了正確且完整的Specification,接下來就可以敘述需要那些工“works”方可以完成Goods的Statement of Works (SOW)文件,SOW用以說明“Where”、“When”與 “How many”、“ How long”。有了完整的SOW與Specification,同時參考WBS以及當作附件用以說明“Why”的Needs (參考12207 - 5.1.1),乙方Supplier就可以依據甲方要採購的品項CLIN,進行估價。以上所敘述的都是基於PM能夠完成需求確認的假設,因此在執行RFP之前要進行Requirements Elicitation、Requirements Analysis、Requirements Documentation、Requirements Validation等Requirements Development的程序以完成Specification;Elicitation就可以包括Interview、Prototyping、Meeting、Questionary、…等技巧。因為RFP的需求明確所以在採購合約之價金方式(Contract Type)通常會選用對於乙方最不利的固定價金契約(Firm-Fixed-Price,FFP,國內採購法並無相對應之名辭,較接近的是“總包價方式”加上“禁止調整”),這對於甲方是最有保障的。所以對於甲方最有利的採購方式是要完整且正確的在RFP中提供SOW、Specification,以便乙方不需要有任何“Assumption”之下進行報價。
2.但事實上以系統複雜性日增、科技產品生命週期日漸縮短環境下要在發RFP之前完成Specification與SOW已日漸困難,因此已演進為需求不明確之下進行採購,RFP Package中不說明Specification,通常僅說明尚未達到system level的高層次構想文件Requirements Documentation,因為無specification所以通常也無SOW,改以提供Statement of Object,前面所提的requirements development就交給developer去做,乙方要代甲方完成specification與SOW。在Requirements不完整下要乙方估價,是屬於高方風險的合約,因此在計價方面就必須採用成本價金補償方式cost reimbursement,國內採購法有相近似的“成本加公費”。此種採購方式就是Evolutional Acquisition and Spiral Development Model,其特徵是 “I can not tell you what I want, but I’ll know it when I see it.”。
3.因此需求明確與否皆可執行採購作業之RFP Release程序,但採購人員最重要的是依據當時需求是否明確狀態選擇適當之契約價金方式,PM選定適當的Life Cycle Model。如同軟體工程一般教科書所提到的life cycle中由Conception phase至production phase,其risk由最高降至最低,因此如果甲方不能於RFP完整敘述Specification,較佳的避險方式是合約應採取多階段計價方式。風險高的階段要採用成本價金補償方式,風險低的階段要採用固定價金方式。選錯契約價金方式與Life Cycle Model將導致合約最高風險,此就是所謂的Cost Risk。
4.需求明確且採用固定價金契約在專案管理方面有極大之影響,例如美國政府即明定FFP類型合約不得以實獲值工程EVMS進行計畫成本與時程分析,同時要盡量減少履約監控,否則會提高乙方的風險。
albertchou
發表時間: 2007-11-01 12:27
Just can't stay away
註冊日: 2003-04-21
來自:
發表數: 71
Re: 美國政府獲取作法說明與探討
感謝Alex的解說。

不過,有關第4點小弟有些不明白。即:為何美國政府要明定FFP類型合約不得以實獲值工程EVMS進行計畫成本與時程分析?又為何對FFP類型的合約進行履約監控會提高乙方的風險?

是否能請Alex再進一步解釋。謝謝!
alex.yin
發表時間: 2007-11-01 16:44
Just can't stay away
註冊日: 2007-09-04
來自: 國防工業發展協會
發表數: 77
Re: 需求規格書與採購
FFP型式合約屬於需求明確,所以一般會應用在幾乎是現貨件COTS或是確認COTS件之修改項目為可行以及已經由研發測試確定工程技術可行之進入生產階段的製造合約。對於Works易於掌握且沒有不明確之處,因此對於政府端而言製造成本以及利潤皆是屬於透明狀態,由乙方報出Lump sum price類型的firm-fixed-price contract,對雙方都是有利的,政府不須去承擔物價變動等不確定因素,乙方僅須依時依地點交付產品即可。此等類型合約等於是“一個價包工”,利潤由乙方自行承擔風險,不像Cost Type Contract,等於是政府向乙方公司買人頭委辦設計,究竟規畫多少人力、實際投入多少人力、實獲值為何,都必須由乙方的成本會計系統提報薪資資料、工時卡、加班工時、產量或進度,俾甲方能計算所投入的研發成本同時對於時程或進度進行監控,並將此等成本補償予乙方,如果在此情形下要由甲方進行過多的履約監控,會將乙方原有的利潤空間壓縮的風險。事實上不將 EVMS套用於FFP類型合約,是由美國採購協會Contract Services Association of America (CSA) 站在對於政府端與承約商皆有利的考量下所建議且為政府所接受。在該建議中尚包括研發RD案應該在合約金額達到美金2000萬元以上方具有使用EVMS的效益,目前似乎已將EVMS的門檻調高到美金5000萬元以上,且在議約階段必須確認乙方的成本會計系統確定能與政府會計系統銜接,EVMS的計算也是由專責部門執行並非由甲方的PM執行(例如國防部即由國防合約管理局(Defense Contract Management Agency)執行)。
albertchou
發表時間: 2007-11-02 17:49
Just can't stay away
註冊日: 2003-04-21
來自:
發表數: 71
Re: 美國政府獲取作法說明與探討
感謝Alex的詳盡解說,原來的問題沒了,不過又演申了另外的問題。

只有在美金5000萬元以上的專案,再加上其它條件的配合,才使用EVMS來管控進度。我的問題是:
1. 那麼,在美國低於此金額的專案用什麼方式管控進度?
2. 以我國的情況而言,既無專責的機構,廠商(乙方)的成本會計系統又不夠成熟。在此情況下您建議用什麼方式管控專案進度較佳?

再有勞Alex為我們說明一下。
alex.yin
發表時間: 2007-11-03 22:56
Just can't stay away
註冊日: 2007-09-04
來自: 國防工業發展協會
發表數: 77
Re: 需求規格書與採購
採用成本價金(Cost Type)或是有附加獎勵金(Incentive)的固定合約價金契約(Foxed Price)等類型合約,如果達到5000萬美金門檻,依據EVMS的需求乙方必須按預算管理局(OMB)的表單 Contract Performance Report formats (CPR,DID-MGMT-81466)提報專案執行報告(Cost and Schedule status),此份表單共計有5種format,分別依據(1)所採購品項之WBS、(2)依據乙方之組織如OBS或IPT、(3) 成本價金協議基準(以budget為基準)、(4)執行人力分布(如full time、part time)敘述這些專案原始資料、以及(5)問題與解決方案等5種Format資料。這些資料經由計算出EVMS各項Variance與Index,在審查會議中配合Integrated Master Schedule (IMS) 進行Integrated Baseline Reviews (IBR),IBR將對於work, schedule, and budget進行執行績效審查,並且要執行時程風險評估Schedule Risk Assessment (SRA)。因此達到5000萬美金門檻要涵括至少
1.Contract Performance Report
2.Integrated Master Schedule
3.Integrated Baseline Reviews
4.Schedule Risk Assessment
5.Ongoing surveillance。

由於EVMS大部份應用於需求不明確,甲方支付價金以補償乙方之開發人力支出,所以IMS與預算(negotiated budget)是處於隨需求逐步明確以及設計架構確認而調整之狀態。

至於未達門檻之專案,CPR Format 2、3、4與SRA屬於optional,IMS為可裁適。裁適範圍由PM依據引用EVMS之成本、效益而決定。

以上工作都需要甲方有足夠且夠資格的工程人員參予且派駐乙方監控(surveillance),否則CPR的資料有問題,整個EVMS與IMS將形同破功。這些工程人員稱之為契約官工程代表Contracting Officer's Technical Representative (COTR),必須經政府檢定,COTR要上採購法、軟體工程、系統工程、建構管理、風險管理、…等課程。COTR是專案執行期間,甲方與乙方溝通的最重要橋樑,此是提升採購品質最值得推動的方向。

國內現有資訊採購案大部分是需求不明確且採用固定價金合約,所以剛好是美國政府所言雙方皆輸的最糟情境風險。
albertchou
發表時間: 2007-11-06 12:05
Just can't stay away
註冊日: 2003-04-21
來自:
發表數: 71
Re: 需求規格書與採購
感謝 Alex 詳細地解說。

也願國內與資訊採購案相關的人員,能早日脫離此一最糟的情境。
樹狀顯示 | 新的在前 前一個主題 | 下一個主題 | 頁首

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