需求規(guī)格說明書 需求跟蹤矩陣 需求變更評審報告表單全套

需求規(guī)格說明書、需求跟蹤矩陣、需求變更評審報告表單需求變更技術(shù)評審報告項目名稱物聯(lián)網(wǎng)大數(shù)據(jù)平臺項目級別√公司級□部門級□子部門級項目經(jīng)理要求評審的工作產(chǎn)品的名稱《物聯(lián)網(wǎng)大數(shù)據(jù)需求規(guī)格說明書》產(chǎn)品作者(評審申請人)建議評審時間20XX年XX月XX日要求評審的工作產(chǎn)品所屬開發(fā)階段□規(guī)劃階段√需求分析階段□系統(tǒng)設計階段□實現(xiàn)與測試階段□系統(tǒng)驗收階段□安裝運行階段□其它評審準則◆可追溯性：軟件需求規(guī)格說明書中的每一個需求要一一列出并標識，與別的需求區(qū)別開來。每項需求只應在軟件需求規(guī)格說明書中出現(xiàn)一次。◆正確性：軟件需求都是與用戶所期望的相符合。與涉及的相關(guān)行業(yè)技術(shù)規(guī)范相符合?！敉暾裕很浖枨笠?guī)格說明書中沒有遺漏任何必要的需求?！粢恢滦裕焊鬈浖枨笾g或軟件需求與高層（系統(tǒng)，業(yè)務）需求之間不相矛盾?！艨尚行裕很浖枨笠?guī)格說明書中的每一個需求都是可實現(xiàn)的?！魺o二義性：軟件需求規(guī)格說明書中的每一個需求都只有惟一的含義?！艨沈炞C性：軟件需求規(guī)格說明書中的每一個需求對用戶而言都是可驗證、測試的?！舯匾裕很浖枨笠?guī)格說明書中的每一個需求對用戶而言都是必須的，沒有畫蛇添足。◆可理解性：軟件需求規(guī)格說明書中的每一個需求都能清楚表達，保證項目干系人都能看懂?！魟澐謨?yōu)先級：軟件需求規(guī)格說明書中，應根據(jù)需求的輕重緩急對需求劃分優(yōu)先級?！艟哂懈乓O計所需的相關(guān)的輸入信息。評審需提交的資料《物聯(lián)網(wǎng)大數(shù)據(jù)平臺產(chǎn)品需求規(guī)格說明書》《物聯(lián)網(wǎng)大數(shù)據(jù)平臺用戶需求調(diào)查報告》《物聯(lián)網(wǎng)大數(shù)據(jù)平臺系統(tǒng)用戶需求說明書（系統(tǒng)）》《物聯(lián)網(wǎng)大數(shù)據(jù)平臺系統(tǒng)軟件需求跟蹤矩陣表單》產(chǎn)品批準人（審核人）意見√同意評審由

XXX

擔任評審負責人，按技術(shù)評審流程開展評審工作。評審方式：√正式技術(shù)評審（會議評審）□非正式技術(shù)評審（□Email會簽□走查□其他：）評審級別：□部門級√子部門級□項目組內(nèi)□暫不評審原因是：□方案不成熟□資料不完整□其他簽字XXX日期20XX年XX月XX日技術(shù)評審意見及結(jié)果評審時間自20XX年XX月XX日XX時至20XX年XX月XX日XX時評審問答記錄本次評審是針對用戶的新增需求進行評審。1、此次需求的增加，對系統(tǒng)的整體進度影響有多大？答：由于需求的變更點已經(jīng)是在準備進行編碼設計的時候了，所以需求增加后，也涉及到了系統(tǒng)設計的增加，整體的進度有偏差，但會進行有效的控制。2、此次需求的增加，存在什么技術(shù)上的問題嗎？答：此次增加的需求，在技術(shù)角度上是完全可以實現(xiàn)的，不存在什么技術(shù)難題，主要是要有時間來做這些增加。記錄人簽名日期20XX年XX月XX日評審人員簽名其他參與人員簽名評審意見匯總一、缺陷識別無缺陷二、總體評價及建議屬于變更類項目。新增需求分析比較透徹、完善；基本通過。20XX-XX-XX評審結(jié)論√評審通過：工作產(chǎn)品合格，“無需修改”或“需要輕微修改但不必再審核”；□評審基本通過：工作產(chǎn)品基本合格，需要作少量修改，之后通過審核即可；□評審不通過：工作產(chǎn)品不合格，需要作比較大的修改，之后必須重新對其評審。建議整改完成時間20XX年XX月XX日評審負責人簽字XXX日期20XX年XX月XX日缺陷修正及驗證（如果使用缺陷跟蹤軟件，則無需填寫下表）序號缺陷內(nèi)容修正措施實施結(jié)果實施人、日期缺陷修正驗證情況驗證結(jié)論：驗證通過驗證人簽字XXX日期20XX年XX月XX日需求跟蹤矩陣表技術(shù)評審報告項目名稱物聯(lián)網(wǎng)大數(shù)據(jù)系統(tǒng)項目級別√公司級□部門級□子部門級項目經(jīng)理要求評審的工作產(chǎn)品的名稱《物聯(lián)網(wǎng)大數(shù)據(jù)平臺產(chǎn)品需求規(guī)格說明書》《物聯(lián)網(wǎng)大數(shù)據(jù)平臺用戶需求調(diào)查報告》《物聯(lián)網(wǎng)大數(shù)據(jù)平臺用戶需求說明書》《物聯(lián)網(wǎng)大數(shù)據(jù)平臺設計文檔》《物聯(lián)網(wǎng)大數(shù)據(jù)平臺軟件需求跟蹤矩陣表單》產(chǎn)品作者(評審申請人)建議評審時間20XX年3月12日要求評審的工作產(chǎn)品所屬開發(fā)階段□規(guī)劃階段√需求分析階段□系統(tǒng)設計階段□實現(xiàn)與測試階段□系統(tǒng)驗收階段□安裝運行階段□其它評審準則◆可追溯性：用戶需求ID、產(chǎn)品需求ID、設計文檔、測試用例等能找到一一對應關(guān)系。◆正確性：用戶需求ID、產(chǎn)品需求ID、設計文檔、測試用例等對應正確?！敉暾裕很浖枨笠?guī)格說明書中沒有遺漏任何必要的需求?！粢恢滦裕焊鬈浖枨笾g或軟件需求與高層（系統(tǒng)，業(yè)務）需求之間不相矛盾。◆可行性：軟件需求規(guī)格說明書中的每一個需求都是可實現(xiàn)的。◆無二義性：軟件需求規(guī)格說明書中的每一個需求都只有惟一的含義。◆可驗證性：軟件需求規(guī)格說明書中的每一個需求對用戶而言都是可驗證、測試的?！糇兏刂疲盒枨笙嚓P(guān)的產(chǎn)品的變更也放映到RTM中。評審需提交的資料《物聯(lián)網(wǎng)大數(shù)據(jù)平臺產(chǎn)品需求規(guī)格說明書》《物聯(lián)網(wǎng)大數(shù)據(jù)平臺用戶需求調(diào)查報告》《物聯(lián)網(wǎng)大數(shù)據(jù)平臺用戶需求說明書》《物聯(lián)網(wǎng)大數(shù)據(jù)平臺設計文檔》《物聯(lián)網(wǎng)大數(shù)據(jù)平臺軟件需求跟蹤矩陣表單》產(chǎn)品批準人（審核人）意見√同意評審由

擔任評審負責人，按技術(shù)評審流程開展評審工作。評審方式：√正式技術(shù)評審（會議評審）□非正式技術(shù)評審（□Email會簽□走查□其他：）評審級別：□部門級□子部門級□項目組內(nèi)□暫不評審原因是：□方案不成熟□資料不完整□其他簽字日期20XX年3月12日技術(shù)評審意見及結(jié)果評審時間自20XX年3月12日10時至20XX年3月12日11時評審記錄按照RTM的記錄對項目需求、設計文檔等進行了檢查。記錄完整。但還是存在一些問題：（1）、在系統(tǒng)設計文檔中，有部分需求與設計文檔對應章節(jié)不上；（2）、需求規(guī)格說明書的版本好變化后沒有更改過來。記錄人簽名日期20XX年3月12日評審人員簽名其他參與人員簽名評審意見匯總一、缺陷識別序號缺陷描述嚴重性建議缺陷解決方案1在《軟件需求跟蹤矩陣表單》的第3條記錄中SRS列表與設計文檔對應不正確。嚴重修改2需求規(guī)格說明書對應的版本號未更新。一般修改二、總體評價及建議需求分析比較透徹、完善，而且能夠?qū)⒖蛻粜枨笈c產(chǎn)品需求、高層設計、單元測試、集成測試和系統(tǒng)測試等統(tǒng)一起來管理，工作進行的比較認真。基本通過。20XX-3-12評審結(jié)論□評審通過：工作產(chǎn)品合格，“無需修改”或“需要輕微修改但不必再審核”；√評審基本通過：工作產(chǎn)品基本合格，需要作少量修改，之后通過審核即可；□評審不通過：工作產(chǎn)品不合格，需要作比較大的修改，之后必須重新對其評審。建議整改完成時間20XX年3月12日評審負責人簽字日期20XX年3月12日缺陷修正及驗證（如果使用缺陷跟蹤軟件，則無需填寫下表）序號缺陷內(nèi)容修正措施實施結(jié)果實施人、日期1在《軟件需求跟蹤矩陣表單》的第3條記錄中SRS列表與設計文檔對應不正確。修改RTM。完成20XX年3月12日2需求規(guī)格說明書對應的版本號未更新。修改RTM。完成20XX年3月12日缺陷修正驗證情況驗證結(jié)論：驗證通過驗證人簽字日期20XX年3月12日需求規(guī)格技術(shù)評審報告項目名稱物聯(lián)網(wǎng)大數(shù)據(jù)平臺項目級別√公司級□部門級□子部門級項目經(jīng)理要求評審的工作產(chǎn)品的名稱《物聯(lián)網(wǎng)大數(shù)據(jù)平臺產(chǎn)品需求規(guī)格說明書》產(chǎn)品作者(評審申請人)建議評審時間20XX年3月9日要求評審的工作產(chǎn)品所屬開發(fā)階段□規(guī)劃階段√需求分析階段□系統(tǒng)設計階段□實現(xiàn)與測試階段□系統(tǒng)驗收階段□安裝運行階段□其它評審準則◆可追溯性：軟件需求規(guī)格說明書中的每一個需求要一一列出并標識，與別的需求區(qū)別開來。每項需求只應在軟件需求規(guī)格說明書中出現(xiàn)一次?！粽_性：軟件需求都是與用戶所期望的相符合。與涉及的相關(guān)行業(yè)技術(shù)規(guī)范相符合?！敉暾裕很浖枨笠?guī)格說明書中沒有遺漏任何必要的需求?！粢恢滦裕焊鬈浖枨笾g或軟件需求與高層（系統(tǒng)，業(yè)務）需求之間不相矛盾?！艨尚行裕很浖枨笠?guī)格說明書中的每一個需求都是可實現(xiàn)的?！魺o二義性：軟件需求規(guī)格說明書中的每一個需求都只有惟一的含義?！艨沈炞C性：軟件需求規(guī)格說明書中的每一個需求對用戶而言都是可驗證、測試的。◆必要性：軟件需求規(guī)格說明書中的每一個需求對用戶而言都是必須的，沒有畫蛇添足?！艨衫斫庑裕很浖枨笠?guī)格說明書中的每一個需求都能清楚表達，保證項目干系人都能看懂?！魟澐謨?yōu)先級：軟件需求規(guī)格說明書中，應根據(jù)需求的輕重緩急對需求劃分優(yōu)先級?！艟哂懈乓O計所需的相關(guān)的輸入信息。評審需提交的資料《物聯(lián)網(wǎng)大數(shù)據(jù)平臺產(chǎn)品需求規(guī)格說明書》《物聯(lián)網(wǎng)大數(shù)據(jù)平臺用戶需求調(diào)查報告》《物聯(lián)網(wǎng)大數(shù)據(jù)平臺系統(tǒng)用戶需求說明書（系統(tǒng)）》《物聯(lián)網(wǎng)大數(shù)據(jù)平臺系統(tǒng)軟件需求跟蹤矩陣表單》產(chǎn)品批準人（審核人）意見√同意評審由

擔任評審負責人，按技術(shù)評審流程開展評審工作。評審方式：√正式技術(shù)評審（會議評審）□非正式技術(shù)評審（□Email會簽□走查□其他：）評審級別：√部門級□子部門級□項目組內(nèi)□暫不評審原因是：□方案不成熟□資料不完整□其他簽字日期20XX年3月9日技術(shù)評審意見及結(jié)果評審時間自20XX年3月9日11時至20XX年3月9日12時評審問答記錄1、在《產(chǎn)品需求規(guī)格說明書》中“1.3文本讀者”。描述相關(guān)讀者對象，但不用描述他們用此文檔做什么。2、1.6名詞解釋。3、“界面需求”，在對具體的功能模塊描述的時候，要有相應的界面與之對應。4、要有對需求優(yōu)先級別的定義。5、“內(nèi)部文管理”模塊，在總體結(jié)構(gòu)中沒有體現(xiàn)。6、給出相關(guān)模塊的界面圖。記錄人簽名日期20XX年3月9日評審人員簽名其他參與人員簽名評審意見匯總一、缺陷識別無缺陷二、總體評價及建議總體需求分析比較透徹、完善；但需求優(yōu)先級，相關(guān)需求界面沒有進行描述，要進行詳細補充?；就ㄟ^。20XX-3-9評審結(jié)論□評審通過：工作產(chǎn)品合格，