【正文】 □ 5. 可使用性 □ 6. 符合《需求分析報告編寫規(guī)范》的要求 □ 評審意見： 風險評估總結： 評審結論： (評審中審議通過的內容在“□”中劃“√”，否則劃“” ) 1. 通過評審，可以進入下一階段 □ 2. 未通過評審，修改后重新評審 □ 填表： 審批： 1. 本頁不足記錄結果時，可以有附頁，附頁格式自定。 數據管理能力 說明需要管理的文卷和記錄的個數、表和文卷的大小規(guī)模，要按可預見的增長對數據及其分量的存儲要求做出估算。 （ 2） 列出輸出錯誤信息的格式。 動態(tài)數值需求可能包括：欲處理的事務和 任務的數量，以及在正常情況下和峰值工作條件下一定時間周期中處理的數據總量等。對于每一類功能或者有時對于每一個功能，這部分通常由引言、輸入、處理、輸出四個部分組成： 引言 （ 1） 描述該功能要達到的目標、所采用的方法和技術； （ 2） 清楚說明功能意圖的由來和背景。 【提醒注意】本節(jié)所描述的既不是設計方案，也不是在方案設計時的約束條件，它僅僅為方案設計時的約束條件提供了一個可以解釋的理由。程序文件 產品研發(fā)流程 20xx 年 月 日起生效 文件號 編制 審核 批準 版 次 日期 日期 日期 共 63 頁 第 15 頁 軟件問題報告 記錄編號： 時間： 年 月 日 項目編號： 項目名稱： 軟件項編號： 軟件項名稱： 版本號： 問題描述： 報告人簽字 /日期 : 修改描述（主要是修改后與修改前的對比，如所用資源的變化、提交時間的變化、功能的變化等）： 修改人簽字 /日期： 填寫： 審批： 1. 問題描 述欄中可以填寫問題現(xiàn)象及其產生原因，如果有用戶的書面說明，則可以直接引用。風險級別：風險發(fā)生造成損失的嚴重程度，以0 ~ 1 0 級表示，其中1 0 級 為最高級。 □ 評審意見： 評審結論 : 填表 審批 1． 本頁不足記述評審意見時，可以加入附頁，附頁格式自行設計，總頁數包括本頁與所有附頁。風險評估與控制 （可行性分析報告評審附頁）立項建議報告名稱： 評估人 / 日期：程序文件 產品研發(fā)流程 20xx 年 月 日起生效 文件號 編制 審核 批準 版 次 日期 日期 日期 共 63 頁 第 10 頁 項目計劃書 項目名稱 項目編號 項目經理 項目任務描述 項目總時間及關鍵里程碑設置 項目資源（人力、技術、設備） 項目費用預計 審批人意見： 總監(jiān)： 副總監(jiān)： 執(zhí)委會： 備注：抄送財務部、人力資源部 項目啟動計劃評審記錄 記 錄編號： 時間： 年 月 日 時間 程序文件 產品研發(fā)流程 20xx 年 月 日起生效 文件號 編制 審核 批準 版 次 日期 日期 日期 共 63 頁 第 11 頁 項目編號： 項目名稱： 項目啟動計劃編號： 開發(fā)部門： PM： 評審地點： 參加評審人員 : 評審內容 (評審中審議通過的內容在“□”中劃“√”否則劃“” )： 1) 項目的目的是否明確？ □ 2) 對項目的規(guī)模是否進行估算？ □ 3) 是否進行項目啟動的預算？ □ 4) 階段輸出結果是否明確？ □ 5) 其它方面 評審意見： 評審結論： 填表： 審批： 1. 項目啟動計劃評審由項目管理部門組織評審?？傢摂蛋ū卷撆c所有附頁。 【提醒注意】 ? 方框圖不是產品的設計，而只是一種有效的解釋方式。其中有名字、操作員活動的描述、控制臺或操作員的位置。 ? 精度 說明對該軟件的輸入、輸出數據精度的要求，可能包括傳輸過程中的精度。 （ 3） 描述軟件與硬件接口之間以及硬件接口與支持設備之間的約定。 【提醒注意】這里的內容有時是“用戶接口”的一部分。并將各項填寫完整。 評審過程的四個階段為 ： 計劃 、 準備 、 執(zhí)行 和 整理。 2. 總體設計 簡要說明對本系統(tǒng)的主要的輸入輸出項目、處理的功能與性能等的要求。 說明為了系統(tǒng)維護的方便而在程序內部設計中做出的安排，包括在程序中專門安排用于系統(tǒng)的檢查與維護的檢測點和專用模塊。 給出對每時每一個輸出項的特性，包括名稱、標識、數據的類型和格式，數據值的有效范圍、輸出的形式、數量和頻度、輸出媒體、對輸出圖形及符號的說明、安全保密條件等等。風險控制措施：預防風險發(fā)生的措施。 第 頁/ 共 頁2 . 風險描述：描述當前過程中可能發(fā)生的風險。 說明對該程序的全部性能要求，包括對精度、靈活性和時間特性的要求。 5. 系統(tǒng)數據結構設計 給出本系統(tǒng)內所使用的每個數據結構的名稱、標識符以及它們之中每個數據項、記錄、文卷和系的標識、定義、長度及它們之間的層次的或表格的相互關系。 （ 4） 待開發(fā)的軟件系統(tǒng)的名稱； （ 5） 本項目的任務提出者、開發(fā)者、用戶及實現(xiàn)該軟件的計算中心或計算機網絡； （ 6） 該軟件系統(tǒng)同其他系統(tǒng)或其他機構的基本的相互來往關系。 作者 作者是指被評審的軟件工作產品的作者，其主要職責如下： 準備相關的評審資料 完成評審后的修改工作 評審組長 評審組長必須為該軟件工作產品所屬領域的高級技術人員，其主要職責如下： 指導作者組織并實施評審活動，對評審材料進行初審，確定參加評審的人員 按照評審規(guī)程主持評審會議 在評審會議上控制評審進度，提醒參加者不要在某一問題上花費過多時間 對評審中發(fā)現(xiàn)的問題進行分析判斷，確定處理辦法，建議為兩類： 1. 問題項：當場確定為問題，需要解決 2. 調查項：無法確定是否為主要問題，需要進 一步調查確認 決定評審結果（通過和再評審） 記錄員 記錄員在評審會議中記錄發(fā)現(xiàn)的問題及相關的數據，其主要職責如下： 填寫評審記錄表 作為評審員參與評審 其他參與人員 其他人員評審軟件工作產品，回答問題、參與討論同時幫助解決問題。 當包括附錄時，需求說明書必須明確地說明附錄是不是需求要考慮的部分。 【提醒注意】如果使用一個現(xiàn)有的數據庫包，這個數據庫包應在“軟件接口”中命名，并在那里詳細說明。例如，如果系統(tǒng)的用戶通過顯示終端進行操作，就必須指程序文件 產品研發(fā)流程 20xx 年 月 日起生效 文件號 編制 審核 批準 版 次 日期 日期 日期 共 63 頁 第 20 頁 定如下要求：對屏幕格式的要求，報表或菜單的頁面顯示格式和內容，用戶命令的格式，輸入輸出的相對時間，程序功能 鍵的可用性。 靜態(tài)數值需求可能包括：支持的終端數，支持并行操作的用戶數，處理的文卷和記錄數， 表和文卷的大小等。 用文字、圖表或數學公式詳細描述被開發(fā)軟件的 輸入、處理、輸出以及在上述過程中發(fā)生的基本操作。 【技巧】在本節(jié)的描述中，用一個方框圖來表達一個較大的系統(tǒng)或項目的主要組成部分、相互聯(lián)系和外部接口是非常有幫助的。風險控制措施：預防風險發(fā)生的措施。風險發(fā)生可能性：風險發(fā)生的概率，以百分數表示，為0 到1 ，增量為0 . 0 5 。 第 頁 /共 頁 程序文件 產品研發(fā)流程 20xx 年 月 日起生效 文件號 編制 審核 批準 版 次 日期 日期 日期 共 63 頁 第 7 頁 評審部門：序號風險描述風險發(fā)生可能性風險級別 風險現(xiàn)值 風險控制措施1目標不明確（如產品定位、市場前景描述不清晰）2時間緊（包括開發(fā)、測試、產品包裝、產品銷售等）3 源碼、文檔資料的控制4市場調研不充分，缺乏對市場上已經有的具有相似功能產品的了解5 預算不合理6 存在技術難點、采用新技術7缺乏對本公司的產品形態(tài)、技術路線、戰(zhàn)略方針、發(fā)展趨勢的全面了解8 缺乏足夠資源9 分工不明確、缺乏計劃性10 多部門配合111 . 評估中風險不限于表中已列出的，應依據評審的具體情況增加風險項。 2. 評審完成后由開發(fā)體系決策層 SMG 批準。 項目資源調度單（借鑒產品中心任務書） 程序文件 產品研發(fā)流程 20xx 年 月 日起生效 文件號 編制 審核 批準 版 次 日期 日期 日期 共 63 頁 第 16 頁 項目名稱 項目編號 項目經理 項目的跨中心（部門）資源調度緣由及 申請人 審批人 正式調用時間： 起： 止： 備注：抄送財務、人力資源部 軟件需求分析說明書 1. 引言 時間 程序文件 產品研發(fā)流程 20xx 年 月 日起生效 文件號 編制 審核 批準 版 次 日期 日期 日期 共 63 頁 第 17 頁 說明編寫軟件需求說明書的目的，指出預期的讀者。 ? 本節(jié)不是具體需求的陳述，只是對具體需求部分中為什么要對一些需求做出描述的鋪墊。例如：當打印檢查時，要求操作員進行格式調整。 ? 時間特性 要 求 說明對于該軟件的時間特性要求，如對響應時間 、 更新處理時間 、 數據的轉換和傳送時間 、 解題時間等的要求。 軟件接口 描述項目待開發(fā)軟件產品與其它有關軟件的接口關系，并指出這些軟件的以下內容：名字、助記符、規(guī)格說明號、版本號、來源。 故障處理 4. 運行環(huán)境規(guī)定 列出運行該軟件所需要的硬設備。 第 頁/共 頁：描述當前過程中可能發(fā)生的風險。 每一階段必須順序地執(zhí)行，才能保證評審成功 。 簡要地說明對本系統(tǒng)的運行環(huán)境（包括硬件環(huán)境和支持環(huán)境）的規(guī)定。 詳細設 計說明書 1. 引言 說明編寫詳細設計說明書的目的，指出預期的讀者。 詳細說明本程序單元所選用的算法，具體的計算公式和計算步驟。風險評估與控制 （系統(tǒng)設計報告評審附頁）系統(tǒng)設計報告名稱： 報告編號：程序文件 產品研發(fā)流程 20xx 年 月 日起生效 文件號 編制 審核 批準 版 次 日期 日期 日期 共 63 頁 第 41 頁 軟件質量保證文檔 （項目名稱） SQA 計劃 計劃編號： SQAL： 日期： 版 本： SQAM： 日期： 分 冊： PM/SM： 日期： 1 質量目標 質量目標，盡可能用測試的條款表達。并將各項填寫完整。 說明該程序單元應具有的功能，可采用 IPO圖（即輸入 —— 輸出圖）的形式。 說明每種運行模塊組合將占用各種資源的時間。 程序文件 產品研發(fā)流程 20xx 年 月 日起生效 文件號 編制 審核 批準 版 次 日期 日期 日期 共 63 頁 第 32 頁 5 附錄 B 評審記錄表 評審會日期： _________________ 開始時間： _________________ 結束時間： _________________ 評審會地點： ___________________________________________________________第 _____次評審 評審主題： __________________________________________________________