【正文】 的問題 說明在設計過程中尚未解決而設計者認為在完成之前必須解決的各個問題。 3． 1 外部接口 3． 2 內部接口 4． 1 運行控制 說明每一種外界的運行控制的方式方法和操作步驟。 5． 1 邏輯結構設計 給出所使用的每個 數據結構的名稱、標識符以及它們之中每個數據項、記錄、的標識、定義、長度及它們之間的層次相互關系。 5． 2 物理結構設計 給出所使用的每個數據結構中的每個數據項的存儲要求，訪問方法 6． 1 出錯信息 6． 2 補救措施 程序文件 規(guī)劃中組件開發(fā)流程 20xx 年 月 日起生效 文件號 編制 審核 批準 版 次 日期 日期 日期 共 30 頁 第 7 頁 《組件開發(fā)需求》模板 Version 1. 組件簡述 對組件要完成什么，所面向的用戶以及系統(tǒng)運行的環(huán)境的簡短描述，這部分主要來源于需求說明書部分。 2. 組件設計目標 這部分論述組件的設計目標，明確地說明哪些功能是組件 決定實現而哪些是不準備實現的。同時，對于非功能性的需求例如性能、可用性等，亦需提及。如果組件有可視化部分，亦需有簡單的界面描述或圖型描述。需求說明書對于這部分的內容來說是很重要的參考，看看其中明確了的功能性以及非功能性的需求。 這部分必須說清楚設計的全貌如何，務必使讀者看后知道將實現的組件有什么特點和功能。在隨后的相關文檔中，將解釋和設計是怎么來實現這些的。 3 參考資料 列出本文檔中所引用的參考資料。（至少要引用需求說明書） 程序文件 規(guī)劃中組件開發(fā)流程 20xx 年 月 日起生效 文件號 編制 審核 批準 版 次 日期 日期 日期 共 30 頁 第 8 頁 4 修訂版本記錄 列出本文檔修改的歷史紀錄。必須指明修改的內容、日期 以及修改人。 5 術語表 對本文檔中所使用的各種術語進行說明。如果一些術語在需求說明書中已經說明過了，此處不用再重復，可以指引讀者參考需求說明。 《開發(fā)進度周報》 開發(fā)進度周報的編制目的是及時向有關管理部門匯報組件開發(fā)的進展和情況，以便及時發(fā)現和處理開發(fā)過程中出現的問題。具體的內容要求如下： 2． 1 進度 2． 2 狀態(tài) 程序文件 規(guī)劃中組件開發(fā)流程 20xx 年 月 日起生效 文件號 編制 審核 批準 版 次 日期 日期 日期 共 30 頁 第 9 頁 文檔編號： Test005 版本號 ： 文 件 名：缺陷報告 .doc 編 寫： 質量控制部 年 月 日 校 對： 年 月 日 審 核： 年 月 日 批 準： 年 月 日 文檔編號： Test005 版 本編號： 密 級：中 北京 xxx軟件開發(fā)有限公司 質量控制部文檔 XX系統(tǒng) 之 xx 系統(tǒng) 缺陷報告 程序文件 規(guī)劃中組件開發(fā)流程 20xx 年 月 日起生效 文 件號 編制 審核 批準 版 次 日期 日期 日期 共 30 頁 第 10 頁 XXX 系統(tǒng)之 XX 系統(tǒng) 缺陷報告 版本 修訂歷史記錄 日期 版本 說明 作者 首次的缺陷報告 質量控制部 程序文件 規(guī)劃中組件開發(fā)流程 20xx 年 月 日起生效 文件號 編制 審核 批準 版 次 日期 日期 日期 共 30 頁 第 11 頁 缺陷報告 一 .簡介 目的 本文檔作為《 XXX 系統(tǒng)》之 XX 系統(tǒng) 的 “缺陷報告 ”， 有助于實現以下目標： A、 列出測試活動的主要內容。 B、 列出測試活動的測試統(tǒng)計結果。 C、 列出系統(tǒng)的主要缺陷。 D、 對于缺陷提出的修改 建議。 E、 由于本系統(tǒng)的某些需求尚未最后確定，目前只能對系統(tǒng)進行部分的功能測試及完全的用戶界面測試。 F、 本報告為針對測試活動的首次缺陷報告，以后的測試活動還會提交迭代的缺陷報告。 G、 本文檔提交給項目組的管理者及開發(fā)人員審閱。 二 .測試 內容 下面的列表列出了 本次測試活動的主要測試內容。 數據庫測試 核實系統(tǒng)是否能訪問數據庫。 功能測試 核實 .. 用戶界面測試 瀏覽所有的用例，核實是否每個 UI 面板都易于理解 。 核實界面操作是否簡單易行，圖形顯示是否清晰。 程序文件 規(guī)劃中組件開發(fā)流程 20xx 年 月 日起生效 文件號 編制 審核 批準 版 次 日期 日期 日期 共 30 頁 第 12 頁 三 .測試 統(tǒng)計結果及缺陷總結 數據庫 測試 核實系統(tǒng)是否能訪問數據庫。 功能測試 核實是否能夠瀏覽數據庫中保存的電子化文檔； 核實是