需求規格說明書、需求跟蹤矩陣、需求變更評審報告表單

源檔案擷取評論“評審報告擷取”

需求變更技術評審報告

項目名稱	物聯網大資料平台
項目級别	√公司級 □ 部門級 □ 子部門級	項目經理
要求評審的工作産品的名稱	《物聯網大資料需求規格說明書》
産品作者 (評審申請人)	建議評審時間	20XX年XX月XX日
要求評審的工作産品所屬 開發階段	□規劃階段 √ 需求分析階段 □ 系統設計階段 □ 實作與測試階段 □ 系統驗收階段 □ 安裝運作階段 □ 其它
評審準則	◆ 可追溯性：軟體需求規格說明書中的每一個需求要一一列出并辨別，與别的需求差別開來。每項需求隻應在軟體需求規格說明書中出現一次。 ◆ 正确性：軟體需求都是與使用者所期望的相符合。與涉及的相關行業技術規範相符合。 ◆ 完整性：軟體需求規格說明書中沒有遺漏任何必要的需求。 ◆ 一緻性：各軟體需求之間或軟體需求與高層（系統，業務）需求之間不相沖突。 ◆ 可行性：軟體需求規格說明書中的每一個需求都是可實作的。 ◆ 無二義性：軟體需求規格說明書中的每一個需求都隻有惟一的含義。 ◆ 可驗證性：軟體需求規格說明書中的每一個需求對使用者而言都是可驗證、測試的。 ◆ 必要性：軟體需求規格說明書中的每一個需求對使用者而言都是必須的，沒有畫蛇添足。 ◆ 可了解性：軟體需求規格說明書中的每一個需求都能清楚表達，保證項目幹系人都能看懂。 ◆ 劃分優先級：軟體需求規格說明書中，應根據需求的輕重緩急對需求劃分優先級。 ◆ 具有概要設計所需的相關的輸入資訊。
評審需送出 的資料	《物聯網大資料平台産品需求規格說明書》 《物聯網大資料平台使用者需求調查報告》 《物聯網大資料平台系統使用者需求說明書（系統）》 《物聯網大資料平台系統軟體需求跟蹤矩陣表單》
産品準許人 （稽核人） 意 見	√ 同意評審 由 評審方式：√ 正式技術評審（會議評審） □ 非正式技術評審（□ Email會簽 □ 走查 □其他： ） 評審級别：□ 部門級 √ 子部門級 □ 項目組内 □ 暫不評審 原因是：□ 方案不成熟 □ 資料不完整 □ 其他
簽 字	XXX	日 期	20XX年XX月XX日
技 術 評 審 意 見 及 結 果
評審時間	自 20XX年XX月XX日XX時 至 20XX年XX月XX日 XX 時
評審 問答 記錄	本次評審是針對使用者的新增需求進行評審。 1、 此次需求的增加，對系統的整體進度影響有多大？ 答：由于需求的變更點已經是在準備進行編碼設計的時候了，是以需求增加後，也涉及到了系統設計的增加，整體的進度有偏差，但會進行有效的控制。 2、 此次需求的增加，存在什麼技術上的問題嗎？ 答：此次增加的需求，在技術角度上是完全可以實作的，不存在什麼技術難題，主要是要有時間來做這些增加。
記錄人簽名	日 期	20XX年XX月XX日
評 審 人員簽名
其他參與 人員簽名
評審意見 彙 總	一、缺陷識别 無缺陷 二、總體評價及建議 屬于變更類項目。新增需求分析比較透徹、完善； 基本通過。 20XX-XX-XX
評審結論	√評審通過：工作産品合格，“無需修改”或“需要輕微修改但不必再稽核”； □評審基本通過：工作産品基本合格，需要作少量修改，之後通過稽核即可； □評審不通過：工作産品不合格，需要作比較大的修改，之後必須重新對其評審。
建議整改完成時間	20XX年XX月XX日
評審負責人簽字	XXX	日　期	20XX年XX月XX日
缺陷修正及驗證（如果使用缺陷跟蹤軟體，則無需填寫下表）
序号	缺陷内容	修正措施	實施結果	實施人、日期
缺陷修正 驗證情況	驗證結論： 驗證通過
驗證人簽字	XXX	日 期	20XX年XX月XX日

需求跟蹤矩陣表技術評審報告

項目名稱	物聯網大資料系統
項目級别	√公司級 □部門級 □ 子部門級	項目經理
要求評審的工作産品的名稱	《物聯網大資料平台産品需求規格說明書》 《物聯網大資料平台使用者需求調查報告》 《物聯網大資料平台使用者需求說明書》 《物聯網大資料平台設計文檔》 《物聯網大資料平台軟體需求跟蹤矩陣表單》
産品作者 (評審申請人)	建議評審時間	20XX 年3月12日
要求評審的工作産品所屬 開發階段	□ 規劃階段 √需求分析階段 □ 系統設計階段 □ 實作與測試階段 □ 系統驗收階段 □ 安裝運作階段 □ 其它
評審準則	◆ 可追溯性：使用者需求ID、産品需求ID、設計文檔、測試用例等能找到一一對應關系。 ◆ 正确性：使用者需求ID、産品需求ID、設計文檔、測試用例等對應正确。 ◆ 完整性：軟體需求規格說明書中沒有遺漏任何必要的需求。 ◆ 一緻性：各軟體需求之間或軟體需求與高層（系統，業務）需求之間不相沖突。 ◆ 可行性：軟體需求規格說明書中的每一個需求都是可實作的。 ◆ 無二義性：軟體需求規格說明書中的每一個需求都隻有惟一的含義。 ◆ 可驗證性：軟體需求規格說明書中的每一個需求對使用者而言都是可驗證、測試的。 ◆ 變更控制：需求相關的産品的變更也放映到RTM中。
評審需送出 的資料	《物聯網大資料平台産品需求規格說明書》 《物聯網大資料平台使用者需求調查報告》 《物聯網大資料平台使用者需求說明書》 《物聯網大資料平台設計文檔》 《物聯網大資料平台軟體需求跟蹤矩陣表單》
産品準許人 （稽核人） 意 見	√同意評審 由擔任評審負責人，按技術評審流程開展評審工作。 評審方式：√正式技術評審（會議評審） □ 非正式技術評審（□ Email會簽 □ 走查 □其他： ） 評審級别：□ 部門級 □ 子部門級 □ 項目組内 □ 暫不評審 原因是：□ 方案不成熟 □ 資料不完整 □ 其他
簽 字	日 期	20XX 年3月12日
技 術 評 審 意 見 及 結 果
評審時間	自 20XX 年3月12日10時 至 20XX 年3月12日 11 時
評審 記錄	按照RTM的記錄對項目需求、設計文檔等進行了檢查。記錄完整。但還是存在一些問題： （1）、在系統設計文檔中，有部分需求與設計文檔對應章節不上； （2）、需求規格說明書的版本好變化後沒有更改過來。
記錄人簽名	日 期	20XX 年3月12日
評 審 人員簽名
其他參與 人員簽名
評審意見 彙 總	一、缺陷識别 序号 缺陷描述 嚴重性 建議缺陷解決方案 1 在《軟體需求跟蹤矩陣表單》的第3條記錄中SRS清單與設計文檔對應不正确。 嚴重 修改 2 需求規格說明書對應的版本号未更新。 一般 修改 二、總體評價及建議 需求分析比較透徹、完善，而且能夠将客戶需求與産品需求、高層設計、單元測試、內建測試和系統測試等統一起來管理，工作進行的比較認真。 基本通過。 20XX-3-12
評審結論	□評審通過：工作産品合格，“無需修改”或“需要輕微修改但不必再稽核”； √評審基本通過：工作産品基本合格，需要作少量修改，之後通過稽核即可； □評審不通過：工作産品不合格，需要作比較大的修改，之後必須重新對其評審。
建議整改完成時間	20XX 年3月12日
評審負責人簽字	日　期	20XX 年3月12日
缺陷修正及驗證（如果使用缺陷跟蹤軟體，則無需填寫下表）
序号	缺陷内容	修正措施	實施結果	實施人、日期
1	在《軟體需求跟蹤矩陣表單》的第3條記錄中SRS清單與設計文檔對應不正确。	修改RTM。	完成	20XX 年3月12日
2	需求規格說明書對應的版本号未更新。	修改RTM。	完成	20XX 年3月12日
缺陷修正 驗證情況	驗證結論： 驗證通過
驗證人簽字	日 期	20XX 年3月12日

需求規格技術評審報告

項目名稱	物聯網大資料平台
項目級别	√公司級 □部門級 □ 子部門級	項目經理
要求評審的工作産品的名稱	《物聯網大資料平台産品需求規格說明書》
産品作者 (評審申請人)	建議評審時間	20XX 年3月9日
要求評審的工作産品所屬 開發階段	□規劃階段 √ 需求分析階段 □ 系統設計階段 □ 實作與測試階段 □ 系統驗收階段 □ 安裝運作階段 □ 其它
評審準則	◆ 可追溯性：軟體需求規格說明書中的每一個需求要一一列出并辨別，與别的需求差別開來。每項需求隻應在軟體需求規格說明書中出現一次。 ◆ 正确性：軟體需求都是與使用者所期望的相符合。與涉及的相關行業技術規範相符合。 ◆ 完整性：軟體需求規格說明書中沒有遺漏任何必要的需求。 ◆ 一緻性：各軟體需求之間或軟體需求與高層（系統，業務）需求之間不相沖突。 ◆ 可行性：軟體需求規格說明書中的每一個需求都是可實作的。 ◆ 無二義性：軟體需求規格說明書中的每一個需求都隻有惟一的含義。 ◆ 可驗證性：軟體需求規格說明書中的每一個需求對使用者而言都是可驗證、測試的。 ◆ 必要性：軟體需求規格說明書中的每一個需求對使用者而言都是必須的，沒有畫蛇添足。 ◆ 可了解性：軟體需求規格說明書中的每一個需求都能清楚表達，保證項目幹系人都能看懂。 ◆ 劃分優先級：軟體需求規格說明書中，應根據需求的輕重緩急對需求劃分優先級。 ◆ 具有概要設計所需的相關的輸入資訊。
評審需送出 的資料	《物聯網大資料平台産品需求規格說明書》 《物聯網大資料平台使用者需求調查報告》 《物聯網大資料平台系統使用者需求說明書（系統）》 《物聯網大資料平台系統軟體需求跟蹤矩陣表單》
産品準許人 （稽核人） 意 見	√ 同意評審 由 評審方式：√ 正式技術評審（會議評審） □ 非正式技術評審（□ Email會簽 □ 走查 □其他： ） 評審級别：√ 部門級 □ 子部門級 □ 項目組内 □ 暫不評審 原因是：□ 方案不成熟 □ 資料不完整 □ 其他
簽 字	日 期	20XX 年3月9日
技 術 評 審 意 見 及 結 果
評審時間	自20XX 年3月9日11時 至 20XX 年3月9日 12 時
評審 問答 記錄	1、在《産品需求規格說明書》中“1.3 文本讀者”。描述相關讀者對象，但不用描述他們用此文檔做什麼。 2、1.6名詞解釋。 3、“界面需求”，在對具體的功能子產品描述的時候，要有相應的界面與之對應。 4、要有對需求優先級别的定義。 5、“内部文管理”子產品，在總體結構中沒有展現。 6、給出相關子產品的界面圖。
記錄人簽名	日 期	20XX 年3月9日
評 審 人員簽名
其他參與 人員簽名
評審意見 彙 總	一、缺陷識别 無缺陷 二、總體評價及建議 總體需求分析比較透徹、完善；但需求優先級，相關需求界面沒有進行描述，要進行詳細補充。 基本通過。 20XX-3-9
評審結論	□評審通過：工作産品合格，“無需修改”或“需要輕微修改但不必再稽核”； √評審基本通過：工作産品基本合格，需要作少量修改，之後通過稽核即可； □評審不通過：工作産品不合格，需要作比較大的修改，之後必須重新對其評審。
建議整改完成時間	20XX 年3月9日
評審負責人簽字	日　期	20XX 年3月9日
缺陷修正及驗證（如果使用缺陷跟蹤軟體，則無需填寫下表）
序号	缺陷内容	修正措施	實施結果	實施人、日期
1
2
3
缺陷修正 驗證情況	驗證結論： 驗證通過
驗證人簽字	日 期	20XX 年3月9日