需求追溯表有水平追溯表及垂直追溯表.其中垂直追溯表似乎記錄了所有從RFP-->REQUIREMENT-->DESIGN間的對應關係(需求對應到功能的清單).那麼最後UAT(USER ACCEPTANCE TEST)時,似適合拿來做功能驗收之用.
請教高見:
已邀請的邦友 {{ invite_list.length }}/5
可以作為依據，但不是唯一的依據。
原因是因為僅有需求追溯表，不能證明你有達到專案的要求，而應是依據需求追溯表各階段的產出，來說明跟驗證各項的產出符合專案的驗收標準。
例如，可以用需求追溯表，說明某項需求，是被實做在系統的哪個功能上，並經由測試確認功能可被接受，來代表滿足這個需求。
ithomelee提到：
需求追溯表有水平追溯表及垂直追溯表.其中垂直追溯表似乎記錄了所有從RFP-->REQUIREMENT-->DESIGN間的對應關係(需求對應到功能的清單).那麼最後UAT(USER ACCEPTANCE TEST)時,似適合拿來做功能驗收之用.請教高見:
那要看你的
* 需求獲取 Requirements Capture
* 需求分析 Requirements analysis
* 可行性研究 Feasibility study
* 需求定義 Requirements definition
* 撰寫需求規格文件 Prepare Requirements Document
* 需求規格文件審查 Review Requirements Document
* 需求規格確認 Requirements validation
* 需求變更管理 Requirement Change Management
需求定義到有多詳細
我們是規定需求與實作是 需求說明 與 java Code 一行一行對應
我們是規定需求每一欄位要定義來源與關連運算
initial/data entry/before save/after save/
before WorkFlow Complete..Void..Reactive..Close
after WorkFlow Complete..Void..Reactive..Close
1.依上述"需求定義到有多詳細",才能拿來當驗收的依據.我看國內大概很少軟體公司符合要求.
2.就個人所知,cmmi架構缺少驗收 , 安裝 , 維護這幾項,請問以user的角度,如何透過軟體公司開發過程中CMMI產出的文件輔助驗收工作 ??
1.需求需要定義到多詳細，端看『看文件的人』的需求，這也就是為什麼要在milestone進行meeting的理由。如果需求文件SA看不懂，分析文件SD看不懂，設計文件Programmer看不懂，如何進行下一階段的工作？所以，如果文件是內部要溝通用，就應該先討論文件要作到什麼程度，再做文件會比較好。
拿文件做驗收標準的話，不適合直接拿需求文件，比較好的方式還是應該做需求追溯，但必須讓User事先瞭解需求追溯是怎麼做的以及先確認一下，不然驗收還是有得吵。
2.誰說CMMI缺驗收跟安裝？把驗收看成是專案過程中其中的一個milestone，其實準備的方法大同小異，只是驗收會比其他的milestone會要求比較多，比較難過而已。你要是有參與過CMMI的評鑑工作的話，那絕對是比專案驗收還要求更多更多的。安裝請參考CM這個流程領域，但安裝與系統維護的方法論，ITIL會比CMMI講得更多，畢竟兩者著重的目的跟方向不太一樣，不適合拿來比較孰優孰劣。
我不太能夠理解您的問題，請問以User的角度，目前您看到您的廠商有哪些問題是導致驗收無法順利進行的？可能要請您敘述更清楚些。
感謝swift說明.我只是想了解,有CMMI認證的軟體公司,開發過程產出許多文件,客戶這一方是否也能拿某些文件以便輔助驗收作業進行, 驗收最困難的是各說各話,是否有某種雙方從頭至尾都共同接受的文件作為驗收依據??
CMMI文件主要還是提供軟體公司內部作業流程控管為主,對於客戶在監督專案進行時,能夠主動提供什麼樣的監督作用?
這樣說好了，一個專案，其實是受到多方的監督，除了PM以外，還有公司長官，CM（建構管制人員）/QA（品質保證人員）/MA（度量人員），另外，當然還有客戶。這些人再加上專案成員，通稱是這個專案的Stakeholder。
通常公司內部製作的，遵循CMMI的文件，通常就是這個公司依據的過去經驗的累積，定義出的『流程』運作而生的工作產品。一般客戶可能不知道，導入過CMMI的公司，會有一堆文件範本，文件撰寫原則指引，範例，再加上公司內部的教育訓練來讓員工『會寫』，『會看』這些文件，同時內部也會藉由不斷地PDCA，來檢視有問題的流程並調整。
但是，通常我的客戶並沒有受到這方面的訓練，一方面是我的客戶可能不固定，即使都是同一公司同一單位的人，也不是每次的案子都是同一承辦人。所以我跟客戶的溝通，公司內部的文件只是參考，碰到要求比較多的客戶，我可能還需要重新做一份文件給客戶，來滿足客戶的要求。碰到最多的就是我的PEP(專案執行計畫）通常要做兩份，一份給公司內部CMMI用。一份給客戶，內容是依照客戶的要求，把他看不懂或是覺得不重要的地方拿掉。
我前面說過，文件是拿來溝通的，所以如果你是用心的PM，或是用心的客戶，可以在專案一開始的時候，先溝通好需要產出的文件，內容以及寫法。有做CMMI的公司，一定有一些之前的資料可以先拿來討論，有了共識之後，下去做，才不會有重工或是不符合期望的問題。
通常客戶也會有一些驗收範本或是過去的驗收紀錄，如果有的話，也可以先提供給廠商，讓他們在驗收前先準備好。
另外，若您是客戶的身份，對CMMI有興趣的話，建議您可以看一下CMMI-ACQ（籌獲模式）。個人過去的經驗，有一些問題的確是發生在客戶本身的身上，如果客戶本身是可以把內部的籌獲流程也建立起來的話，對專案的執行，幫助也是很大的。
另外，客戶可如何監督專案運作，這邊有一篇文章可供參考，裡面有提到：
http://www.ithome.com.tw/itadm/article.php?c=58458
非常感謝swift君詳細說明,獲益很大.客戶方需要很努力很用心,才有希望得到高品質的軟體.
就好像有什麼樣的選民就有什麼樣的政府.
iThome鐵人賽
看影片追技術