敬兒(cnitpm.com) 22:55:18
請教大家一個問題，需求跟蹤矩陣里面的需求都是項目定義范圍里要做的嗎
敬兒(cnitpm.com) 22:55:32
還有需求評審是在什么時候做的？
Frank(cnitpm.com) 9:07:58
@敬兒 需求跟蹤矩陣是范圍管理里面收集需求的輸出
Frank(cnitpm.com) 9:08:12
收集需求之后才是定義范圍
敬兒(cnitpm.com) 9:48:25
需求跟蹤矩陣不是有個跟蹤能力鏈嗎？這個正向跟蹤的時候，要跟蹤到產(chǎn)品，是不是就是說需求跟蹤矩陣中的需求都是范圍定義后的需求呢？
Frank(cnitpm.com) 9:50:05
需求跟蹤矩陣是在定義范圍之前就已經(jīng)有了
敬兒(cnitpm.com) 9:50:38
說上說需求文件里面的內容都要跟蹤到產(chǎn)品元素是不是有問題？
敬兒(cnitpm.com) 9:50:44
書上說的
Frank(cnitpm.com) 9:52:13
定義范圍的輸入有需求文件
Frank(cnitpm.com) 9:52:56
你覺得會有什么問題？不是很明白你的意思
敬兒(cnitpm.com) 9:53:31
需求跟蹤能力鏈不是每個需求都要有相應的產(chǎn)品元素嗎
敬兒(cnitpm.com) 9:54:22
如果這個需求跟蹤矩陣是所有的需求，包括范圍內的和范圍外的話，外圍外的需求就不可能跟蹤到產(chǎn)品元素吧
Frank(cnitpm.com) 10:19:12
需求跟蹤矩陣是把產(chǎn)品需求從其來源連接到能滿足需求的可交付成果的一種表格。使用需求跟蹤
矩陣，把每個需求與業(yè)務目標或項目目標聯(lián)系起來，有助于確保每個需求都具有商業(yè)價值。需求跟
蹤矩陣提供了在整個項目生命周期中跟蹤需求的一種方法，有助于確保需求文件中被批準的每項需
求在項目結束的時候都能交付。最后，需求跟蹤矩陣還為管理產(chǎn)品范圍變更提供了框架。
Frank(cnitpm.com) 10:19:42
有助于確保需求文件中被批準
敬兒(cnitpm.com) 10:20:35
明白了，也就是批準的對應產(chǎn)品元素
Frank(cnitpm.com) 10:20:41
注意是被批準的，只要是被批準的，最終都要轉化為產(chǎn)品元素，肯定就是可被追溯的
敬兒(cnitpm.com) 10:20:54
玫瑰/
Frank(cnitpm.com) 10:21:01
范圍外的肯定就不在批準之內了
Frank(cnitpm.com) 10:21:04
屬于鍍金了
敬兒(cnitpm.com) 10:21:16
恩，謝了
向前，努力奔跑！(cnitpm.com) 10:23:54
@Frank 范圍也會變更，也就意味著，早先被批準的需求，在后續(xù)可能會被否定，此時，需求跟蹤矩陣中難道還會剔除該條被否定的需求？
牧馬人(cnitpm.com) 10:28:39
需求跟蹤矩陣和范圍說明書是從兩個方面對需求進行的描述，前者關注產(chǎn)品需求，后者還包含項目需求。一般來說，需求跟蹤矩陣中所列出的需求與項目范圍說明書中的產(chǎn)品范圍描述的需求是同源的
牧馬人(cnitpm.com) 10:28:42


向前，努力奔跑！(cnitpm.com) 10:30:54
我覺得，被批準的需求 肯定是應該羅列在 矩陣中的，至于 之后被否定的需求，是否需要被剔除，應該是團隊用法的問題吧；如此，在項目初期，所有能被考慮到的需求全（無論是否被批準）全都放在矩陣中，這又有何不可？
敬兒(cnitpm.com) 10:32:19
不做的需求應該也在需求跟蹤矩陣中，因為需求跟蹤矩陣有個狀態(tài)
向前，努力奔跑！(cnitpm.com) 10:32:21
沒有人規(guī)定，在收集需求時，非得等到該需求被批準后 才能被列入 矩陣中
向前，努力奔跑！(cnitpm.com) 10:32:35
@敬兒 
就是嘛
牧馬人(cnitpm.com) 10:34:41
作用不同。二者所列出的需求是一致的（名詞規(guī)范后，需求的名稱都是一致的）。需求跟蹤矩陣用來驗收產(chǎn)品用。范圍說明書用來分解項目工作用。項目工作的目的就是生產(chǎn)出符合需求文件的產(chǎn)品。二者的最終目的相同。用項目管理系統(tǒng)進行需求管理后，二者是一致的，可驗證和追蹤的
牧馬人(cnitpm.com) 10:35:22
項目變更后，如果影響到需求的變更，范圍說明書和跟蹤矩陣都要做響應的變更
向前，努力奔跑！(cnitpm.com) 10:36:49
@牧馬人 是的，但是，便跟的應該是狀態(tài)，或者 新增需求，我個人覺得不應該刪除已經(jīng)羅列的需求，否則，不利于“需求跟蹤”
牧馬人(cnitpm.com) 10:37:26
需求評審是一個里程碑，一般在需求收集完成后召開評審會。當然重大的需求變更，召開的變更評審會一定包含對需求的評審內容
牧馬人(cnitpm.com) 10:40:34

這是一個可使用的實際的需求跟蹤矩陣
牧馬人(cnitpm.com) 10:41:42
范圍說明書最終要演化為WBS才能實用，是個中間產(chǎn)品
牧馬人(cnitpm.com) 10:42:14
需求跟蹤矩陣具有實用的價值
牧馬人(cnitpm.com) 10:42:53
對，還未進行需求評審
牧馬人(cnitpm.com) 10:43:38
當前狀態(tài)還處于需求收集階段?！靶枨箝_發(fā)”
敬兒(cnitpm.com) 10:44:41
在工作中我們都是寫需求規(guī)格說明書，然后給用戶簽字確認，這樣是不是不對
敬兒(cnitpm.com) 10:45:35
需求規(guī)格說明書的內容應該是范圍內的需求吧
牧馬人(cnitpm.com) 10:46:58
對。因為召開需求評審會的時候，讓甲方參加比較難。一般是先讓甲方確認需求，之后再召開需求評審會，這時甲方可不參加
牧馬人(cnitpm.com) 10:47:44
范圍內的需求更廣，包含項目需求，比如開發(fā)用的計算機、人力、時間、資金等資源
牧馬人(cnitpm.com) 10:49:52
需求跟蹤矩陣只包含針對產(chǎn)品的需求。產(chǎn)品需也是范圍內包含的需求之一
牧馬人(cnitpm.com) 10:51:12
用項目管理系統(tǒng)，需求跟蹤矩陣、范圍說明書將自動生成
敬兒(cnitpm.com) 10:51:44
需求規(guī)格說明書所有需求都是范圍內的，但是跟蹤矩陣中的所有需求并不一定是范圍內的，我可以這么理解吧
牧馬人(cnitpm.com) 10:53:04
依據(jù)就是需求規(guī)格說明書。需求規(guī)格說明書評審通過后，就可以生成這兩個文件了。當然還需要對這兩個文件進行修改
敬兒(cnitpm.com) 10:54:09
需求規(guī)格說明書是收集需求的輸出
老馮(cnitpm.com) 10:55:32
我們這類考試，有時題目不是很精確，知識點既要弄懂，又不要鉆牛角尖。
尤其選擇題，可能覺得都不對，或不只一個對的，這時候，選最對的那個。
牧馬人(cnitpm.com) 10:56:31
老馮對。實際工作就需要弄清楚。干過就知道啦
夢(cnitpm.com) 10:57:26
書上的跟實際工作肯定有出入
老馮(cnitpm.com) 10:57:35
考后核對答案時，有考友覺得老師的答案好像不對就是這個問題。
夢(cnitpm.com) 10:57:39
每個公司都有自己的一套標準
牧馬人(cnitpm.com) 10:57:44
系統(tǒng)就設計好了，自動生成，一般兩個文件的需求是不是一直都不核對，應該是
牧馬人(cnitpm.com) 10:58:15
對。遵循國家標準，就是一致的
夢(cnitpm.com) 10:59:06
大致流程是一致的，中間流程沒有那么繁瑣
牧馬人(cnitpm.com) 10:59:13
誰有那個時間，對上千上萬條需求一一核對呀
夢(cnitpm.com) 10:59:27
對呀