Ⅰ 資料庫需求分析
用戶的需求具體體現在各種信息的提供、保存、更新和查詢，這就要求資料庫結構能充分滿足各種信息的輸出和輸入。收集基本數據、數據結構以及數據處理的流程，組成一份詳盡的數據字典，為後面的具體設計打下基礎。
在本系統設計中，由於考慮到各種數據信息均具有空間屬性，即與區域或位置相關，因此在資料庫設計時，使用空間資料庫和屬性資料庫共同管理數據的方式，實現空間數據屬性和非幾何屬性的協同管理。
Ⅱ 需求規格說明書包括哪兩個部分
三、需求規格說明書
1．引言 1
1.1編寫目的 1
1.2項目背景 2
1.3定義 2
1.4參考資料 2
2．任務概述 2
2.1目標 2
2.2運行環境 2
2.3條件與限制 2
3．數據描述 3
3.1靜態數據 3
3.2動態數據 3
3.3資料庫介紹 3
3.4數據詞典 3
3.5數據採集 3
4．功能需求 3
4.1功能劃分 3
4.2功能描述 3
5．性能需求 3
5.1數據精確度 3
5.2時間特性 3
5.3適應性 4
6．運行需求 4
6.1用戶界面 4
6.2硬體介面 4
6.3軟體介面 4
6.4故障處理 4
7．其它需求 4
1．引言
1.1編寫目的
【闡明編寫需求說明書的目的，指明讀者對象。】
為明確軟體需求、安排項目規劃與進度、組織軟體開發與測試，撰寫本文檔。
本文檔供項目經理、設計人員、開發人員參考。
1.2項目背景
a. 項目的委託單位、開發單位和主管部門
b. 該軟體系統與其他
1.3定義
【列出文當中所用到的專門術語的定義和縮寫詞的原文。】
1.4參考資料
a. 項目經核準的計劃任務書、合同或上級機關的批文
b. 項目開發計劃
c. 文檔所引用的資料、標准和規范。列出這些資料的作者、標題、編號、發表日期、出版單位或資料來源
2．任務概述
2.1目標
2.2運行環境
操作系統：Microsoft Windows 2000 Advanced Server
支持環境：IIS 5.0
數 據 庫：Microsoft SQL Server 2000
2.3條件與限制
3．數據描述
3.1靜態數據
3.2動態數據
【包括輸入數據和輸出數據。】
3.3資料庫介紹
【給出使用資料庫的名稱和類型。】
3.4數據詞典
3.5數據採集
4．功能需求
4.1功能劃分
4.2功能描述
5．性能需求
5.1數據精確度
5.2時間特性
【如響應時間、更新處理時間、數據轉換與傳輸時間、運行時間等。】
5.3適應性
【在操作方式、運行環境、與其它軟體的介面以及開發計劃等發生變化時，應具有的適應能力。】
6．運行需求
6.1用戶界面
【如屏幕格式、報表格式、菜單格式、輸入輸出時間等。】
6.2硬體介面
6.3軟體介面
6.4故障處理
7．其它需求
【如可使用性、安全保密、可維護性、可移植性等。】
Ⅲ 怎麼寫需求說明書
需求說明書範文
漢語編程企業管理應用軟體
需求說明書
1 引言
對軟體需求完全理解對於軟體開發工作的成功是至關重要的，需求說明的任務是發現、規范的過程，有益於提高軟體開發過程中的能見度，便於對軟體開發過程中的控制與管理，便於採用工程方法開發軟體，提高軟體的質量，便於開發人員、維護人員、管理人員之間的交流、協作，並作為工作成果的原始依據，並且在向潛在用戶傳遞軟體功能、性能需求，使其能夠判斷該軟體是否與自己的需求相關。
1.1 編寫目的
1.1.1 為開發人員、維護人員、客戶之間提供共同的協議而創立基礎，對企業管理軟體功能的實現作使命描述。
1.1.2 本說明書的預期讀者為客戶、業務或需求分析人員、測試人員、用戶文檔編寫者、項目管理人員。
1.2 背景及范圍
1.2.1 工程的名稱：漢語編程企業管理應用軟體 1.2.2 工程產品的名稱：漢語編程企業管理應用軟體 1.2.3 工程的組織者：北京元易達科技發展有限責任公司 產品的生產者：漢語編程企業管理應用軟體開發課題組 產品的設計者：漢語編程企業管理應用軟體開發課題組
1.2.4 產品的所有權：漢語編程企業管理應用軟體開發課題組
1.3 定義,術語,縮寫詞和略語 企業管理應用系統軟體：它是由企業管理應用系統軟體課題組完全自主開發的企業管理軟體，以企業各部門為基本元素的、用漢語編程來實現其功能的軟體。 需求：用戶解決問題或達到目標所需的條件或功能；系統或系統部件要滿足合同、標准，規范或其它正式規定文檔所需具有的條件或權能。
需求分析：包括提煉，分析和仔細審查已收集到的需求，以確保所有的風險承擔者都明其含義並找出其中的錯誤，遺憾或其它不足的地方。
模塊的獨立性：是指軟體系統中每個模塊只涉及軟體要求的具體的子功能，而和軟體系統中其他的模塊的介面是簡單的。 1.4 參考資料
《漢語程序設計語言》---- 沈志斌 編著 電子工業出版社
《 計算機系統導論》 ---- 劉瑞挺 編著 高等教育出版社
《 資料庫原理與方法》---- 鄭若忠 王鴻武 編著 湖南科學技術出版社 《 軟體需求 》 ---- （美） Karl E.Wiegers 著
陸麗娜 王忠民 王志敏 等譯
2 項目概述
2.1 目標
本軟體的目標使企業管理電子化、簡單化，以節省企業管理方面的不必要的資源浪費。對於企業管理應用系統軟體最終用戶為企業的管理人員。 2.1.1 開發意圖
目前中小企業在日常工作中採用人工管理，因而存在著大量的浪費和多餘，本軟體根據此要求進行開發。 2.1.2 應用目標
企業管理應用系統軟體將解決企業管理人工化，工作繁余的問題，實現企業管理電子化。
2.1.3 作用及范圍
本企業管理應用系統軟體是應用於中小企業的。目前，中小企業管理比較落後，它將產生的影響將使中小企業管理從人力化到數字化進展，使管理人員思想上向數字化轉變，能使企業的管理在機制上轉換，人員上得到精簡。 2.1.4 背景
企業管理應用系統軟體以漢語編程為開發語言，各部門以模塊的形式完成。 2.2 產品描述
本產品開發語言核心為漢語編程語言，具體實現是漢語編程和VF資料庫技術相結合開發而成的。本產品面向中小企業，易懂好學，幫助企業管理人員從手工勞動向電子化、數字化轉變。 2.2.1 相關關系
本產品是一項獨立的軟體，全部內容自含。 2.2.2 子集說明
本產品分別有五個模塊組成，每個模塊各有不同的功能。但都能完成查詢和存儲功能，各模塊的數據都存放在資料庫中。數據的調用和連接都有程序來完成，硬體外部設備需奔騰133以上的pc機，內存需16兆以上。
2.3 產品功能 2.3.1 外部功能
企業管理應用系統軟體外部功能包括可視化窗口，查找存儲。 2.3.2 內部功能
企業管理應用系統軟體內部功能：過濾、定位、使用庫等。 2.3.3 功能表
2.3.4 功能表述圖
2.4 用戶特點
漢語編程企業管理應用軟體面向於中小企業，其使用人員應為具備一定的計算機基礎知識和企業管理基本知識。而本產品的維護人員需要具備有漢語編程知識。
2.5 一般約束
a. 本系統開發人員為12人。
b. 有CPU133、16兆內存配置的計算機就可運行本系統。 c. 在管理方針、並行操作、安全與保密方面無約束。
2.6 假設與依據
本軟體在開發的過程中，分為技術實現與軟體工程兩大部分，兩部分都有側重點，若技術支持出現故障或疑難問題無法解決、程序開發出現偏差，會延誤工程進度，影響工程的按期完工。若軟體工程陳述出現問題，部分描述含混不清，
則會影響系統的完整性與可繼承性。在管理方面，如管理者沒有預見性，對出向的問題無法採用可行的解決手段，都會影響開發模塊之間的互動，從而影響工程的順利開展，導致工程無法按期完工。 3 具體需求 3.1 功能需求 3.1.1 使用庫
3.1.1.1 規格說明
3.1.1.2 引言
顯示所調用的資料庫。 3.1.1.3 輸入
指定的庫文件名。 3.1.1.4 加工
調用指定的資料庫。 3.1.1.5 輸出
顯示所指定的資料庫的庫結構。 3.1.2 編輯框控制 3.1.2.1 規格說明
生成編輯框。 3.1.2.3 輸入 編輯框名稱。 3.1.2.4 加工 生成編輯框。 3.1.2.5 輸出
顯示生成的編輯框。 3.1.3 為當前記錄 3.1.3.1 規格說明
3.1.3.2 引言
將指定的記錄置為當前記錄，下一步可以開始對此記錄進行操作。 3.1.3.3 輸入
指定的項名及庫文件名。 3.1.3.4 加工
將指定的資料庫里指定的記錄置為當前記錄。 3.1.4 建庫文件 3.1.4.1 規格說明
輸入庫文件名,使用"建庫文件"命令，建立一個新的資料庫。 3.1.4.3 輸入 庫文件名。 3.1.4.4 加工
建立新的資料庫。 3.1.4.5 輸出 新建的資料庫。 3.1.5 開始尺寸 3.1.5.1 規格說明
3.1.5.2 引言 在程序中，在"開始尺寸"前給出參數值，能確定指定的對象的開始尺寸的大小。
3.1.5.3 輸入 參數值。 3.1.5.4 加工
確定指定對象在窗體中的開始尺寸的大小 3.1.5.5 輸出
確定開始尺寸的四個參數 3.1.6 開始位置 3.1.6.1 規格說明
3.1.6.2 引言 在程序中，在"開始位置"前給出參數值，能確定指定的對象的開始尺寸的大小。
3.1.6.3 輸入 參數值。 3.1.6.4 加工
確定指定對象在窗體中的開始位置。 3.1.6.5 輸出
確定開始位置的四個參數 3.1.7最大尺寸 3.1.7.1 規格說明
3.1.7.2 引言 在程序中，在"最大尺寸"前給出參數值，能確定指定的對象在窗體中的最大尺寸。
3.1.7.3 輸入 參數值。 3.1.7.4 加工
確定指定對象在窗體中的最大尺寸。 3.1.7.5 輸出
確定指定對象最大尺寸的四個參數。
3.1.8 最小尺寸 3.1.8.1 規格說明
3.1.8.2 引言 在程序中，在"最小尺寸"前給出參數值，能確定指定的對在窗體中的最小尺寸。
3.1.8.3 輸入 參數值。 3.1.8.4 加工
確定指定對象在窗體中的最小尺寸。 3.1.8.5 輸出
確定指定對象最小尺寸的四個參數 3.1.9 查詞編輯框（編輯框控制） 3.1.9.1 規格說明
3.1.9.2 引言
主要是定義的一個編輯框，供用戶輸入一個詞名，為程序生成查找條件做准備。
3.1.9.3 輸入
在查詞編輯框中輸入要查找的詞名。 " 編輯框控制 查找編輯框 " 3.1.9.4 加工
用輸入的詞名以供程序生成查找條。 3.1.9.5 輸出
地址、長度。 。
3.1.10 內容編輯框（編輯框控制） 3.1.10.1 規格說明
3.1.10.2 引言
主要是定義的一個編輯框，將程序查找到的用戶所輸入詞的相關內容顯示出來，為用戶提供幫助信息。 3.1.10.3 輸入
資料庫中查找到的記錄的項的內容的地址、長度。 " 編輯框控制 內容編輯框 " 3.1.10.4 加工 置控制標題或值。 3.1.10.5 輸出
顯示用戶所輸入詞的相關內容（如該詞的格式、用法……）。 3.1.11 過濾
3.1.11.1 規格說明
3.1.11.2 引言
定義用戶輸入的詞名與內容庫中的詞名欄位中的詞名進行串比較，即定義詞名欄位為過濾欄位。 3.1.11.3 輸入 用戶輸入的詞名。 3.1.11.4 加工
把代碼寫入過濾條件指針之中。 3.1.11.5 輸出 查找條件。
3.1.12 執行過濾 3.1.12.1 規格說明
3.1.12.2 引言
將定義的過濾作為內容庫的過濾條件。 3.1.12.3 輸入 查找條件。
3.1.12.4 加工
與查找編輯框中的內容比較。 3.1.12.5 輸出 庫過濾顯 。 3.1.13 取低字 3.1.13.1 規格說明
3.1.13.2 引言
取數摞中的一個32位數的低16位放在數摞上。 3.1.13.3 輸入
調用WINDOWS API 函數。 3.1.13.4 加工 3.1.13.5 輸出 相應的執行功能 3.1.14 白線框 3.1.14.1 規格說明
3.1.14.2 引言
定義查看區一個白顏色的線框。
3.1.14.3 輸入
參數、顏色
3.1.14.4 加工
空心矩形： 設備描述表
3.1.14.5 輸出
線框。
3.2.1 動態數值需求
預處理的窗口正常情況下和峰值工作條件下為20個，一定時間周期中要處理的數據的數量：窗口開始尺寸2個數據，開始位置2個數據，最大尺寸2個數據，最小尺寸2個數據，編輯框位置4個數據，按鈕位置4個數據，平均處理的數據約為16個數據。
3.2.2 靜態數值需求
a. 支持的終端數為1台；
b. 支持並行操作的用戶總數為5位；
c. 處理5個文件及10條記錄；
d. 表或文件的最小為266位元組,最大為4位元組；
3.2.3 精度需求
在進行向資料庫文件提取數據時，要求數據記錄定位準確，在往資料庫文件數組中添加數時，要求輸入數准確。
3.2.4 時間特性需求
a. 響應時間應在人的感覺和視覺事件范圍內；
b. 更新處理時間，隨著漢語編程系統的版本升級，漢語編程企業管理應用系統將相應的進行更新；
3.2.5 靈活性
當需求發生某些變化時，漢語編程企業管理應用軟體操作方式、數據結構、運行環境基本不會發生變化，變化只是將對應的資料庫文件內的記錄改變，或將過濾條件改變即可。
3.2.6 數據管理能力需求
漢語編程企業管理應用軟體需要管理5個文件和10條記錄，表文件的大小平均約為1.5k位元組，漢語編程企業管理應用軟體基本約用10 M位元組空間，所有文件均放置在資料庫中，調用，查詢數據，文件，記錄時，通過庫文件名直接進行操作。
3.2.7 故障處理需求
無故障。
3.3 設計約束條件
3.3.1 技術約束
本工程產品的約束條件包括：
a. 資料庫、各種控鍵的使用和消息的調用；
b. 漢語資料庫過濾完成、編輯框的觸發等；
3.3.2 環境約束
運行本軟體需要奔騰133以上 PC，內存需要在16兆以上，對使用設備的速度、規模要求不高。
3.3.3 標准約束
漢語編程企業管理應用軟體完全按照北京元易達科技發展有限責任公司企業標准開發，包括硬體、軟體和文檔規模。
3.4 介面需求
3.4.1 用戶介面
本工程產品通過PC機進行運行、操作，對報表、菜單的列印將使用漢語編程編輯器或調入WORd進行列印。輸出、輸入的相對時間將由pc機本身處理速度來決定。對程序的維護，需進行必要的備份。
3.4.2 硬體介面
本工程產品不需要特定的硬體或硬體介面進行支撐。
3.4.3 軟體介面
本工程產品的軟體介面由漢語編程操作系統、漢語編程資料庫以及漢語編程企業管理應用軟體的詞典和數據結構組成。
3.4.4 通訊介面
本工程產品的沒有特殊的通訊介面，通訊介面由所使用的pc機決定。
3.5 屬性
3.5.1 可用性
本軟體是完全由漢語程序設計語言開發的，漢語編程最大特點編譯解釋和一，它可以進行單步跟蹤。一旦出現錯誤就可以通過單步跟蹤進行查找處理，所以本軟體也可以通過單步跟蹤的操作進行檢查處理。
3.5.2 安全性
本軟體大量的參數及文本內容全部放於漢語編程資料庫中，所以參數不容易被錯改、破壞，萬一參數受到破壞也不會影響源程序。
3.5.3 可維護性
本軟體利用資料庫進行編程，系統結構由程序基本確定，大量的參數及文本內容全部放於漢語編程中。修改、更新數據只要在資料庫進行修改添加，而不需要對系統結構進行修改，這樣系統維護性、升級都十分方便。
3.5.4 可轉移、可轉換性
漢語編程的兼容性很高，在windows95/98 .windowsNT .windows1700 .操作系統都可以直接運行。
3.5.5 注釋
通過"看數摞"、"看內存"、"印字元"三條漢編基本指令，就可以將所有漢編
成程序進行調試和檢查。本系統的大量參數和文本全部放在資料庫中，通過"使用庫"、"庫顯"等一些漢編資料庫基本操作就可以查看、添加、修改系統。 4 支持信息
4.1 支持軟體
本軟體開發是使用漢語編程編寫，編譯系統為"32位漢語編程系統"，版本號為2.01.0061。在庫調用時兼容Visual Foxpro 6.0英文版，源程序的測試是使用漢語編程自身含有的"看數摞、看內存、看詞"的方法進行測試，即支持測試的軟體也是漢語編程操作系統本身。由於漢語編程本身的特點，它的關鍵詞、命令等全部為中文，所以在使用漢語編程系統時需要中文輸入法的支持。
4.2 設備
a. 具有奔騰133、16兆內存配置的計算機；
b. Microsoft滑鼠或其它兼容滑鼠；
c. 最少15MB的硬碟空間，常規安裝需要100MB硬碟空間，完全安裝需要240MB硬碟空間。
d. 最少8MB的RAM存儲器。
e. VGA顯示器或更高。
f. Windows95中文版或Windows NT中文版或更高。
g. 一般計算機外設，如：列印機、掃描儀。如要配置網路環境，還需網路連接設備。
4.3 控制
本軟體是在漢語編程系統的支持下，展示界面由主窗口與子窗口嵌套而成，窗口操作通過按鈕控制，不同的按鈕進行不同的操作實現不同的功能。
4.4 介面
本軟體在庫的調用時兼容Visual Foxpro 6.0英文版的表結構文件，但不能與Visual Foxpro 6.0英文版在一個操作系統環境中同時運行。
4.5 文檔 本系統相關的文檔為： 《漢語編程企業管理應用軟體可行性研究報告》 編號：MNQB01-QG-01 《漢語編程企業管理應用軟體需求說明書》 編號：MNQB03-QG-01 《漢語編程企業管理應用軟體操作手冊》 編號：MNQB11-QG-01
4.6 附錄
a. 輸入輸出格式樣本採用IPO表逐項定量的敘述對本系統軟體提出的功能需求，如下圖：
b. 本系統軟體的背景信息如下：
漢語編程是本公司自行開發，自主版權的以漢語為描述語言的計算機程序設計語言。該語言絕非曾流行過的任何一種計算機語言的簡單漢化，或是為某種軟體製造一個中文環境。這是一個完全由本公司自行開發，由本公司掌握全部源代碼，從形式到內容全面符合中國人的思維方式，使用漢文字表達的計算機程序設計通用語言。Windows環境下的漢語編程，可以用於Windows窗口程序、多媒體應用、資料庫開發、網路傳輸、電子商務等應用領域。對於較初級計算機用戶，在極短的時間內，可以達到很高的編程水平。
Ⅳ 基於asp,access資料庫的圖書管理系統需求規格說明書
摘要 介紹了信息中心圖書管理系統資料庫的設計。該系統是運行在學校內的圖書管理系統，實現了圖書資料的計算機管理和圖書查詢功能。
關鍵詞 圖書 網路 管理系統 資料庫
1 引言
一直以來人們使用傳統的人工方式管理圖書館的日常工作，對於圖書館的借書和還書過程，想必大家都已很熟悉。在計算機尚未在圖書館廣泛使用之前，借書和還書過程主要依靠手工。一個最典型的手工處理還書過程就是：讀者將要借的書和借閱證交給工作人員，工作人員將每本書上附帶的描述書的信息的卡片和讀者的借閱證放在一個小格欄里，並在借閱證和每本書貼的借閱條上填寫借閱信息。這樣借書過程就完成了。還書時，讀者將要還的書交給工作人員，工作人員根據圖書信息找到相應的書卡和借閱證，並填好相應的還書信息，這樣還書過程就完成了。
以上所描述的手工過程的不足之處顯而易見，首先處理借書、還書業務流程的效率很低，其次處理能力比較低，一段時間內，所能服務的讀者人數是有限的。利用計算機來處理這些流程無疑會極大程度地提高效率和處理能力。我們將會看到排隊等候借書、還書的隊伍不再那麼長，工作人員出錯的概率也小了，讀者可以花更多的時間在選擇書和看書上。
為方便對圖書館書籍、讀者資料、借還書等進行高效的管理，特編寫該程序以提高圖書館的管理效率。使用該程序之後，工作人員可以查詢某位讀者、某種圖書的借閱情況，還可以對當前圖書借閱情況進行一些統計，給出統計表格，以便全面掌握圖書的流通情況。
本次作業設計題目：「圖書管理系統」主要目的是利用資料庫軟體編制一個管理軟體，用以實現圖書、讀者以及日常工作等多項管理。同時對整個系統的分析、設計過程給出一個完整論證。
圖書管理系統是一種基於集中統一規劃的資料庫數據管理新模式。在對圖書、讀者的管理，其實是對圖書、讀者數據的管理。本系統的建成無疑會為管理者對圖書管理系統提供極大的幫助。
2 系統設計
2.1 系統指導思想和建設目標
2.1.1 系統指導思想
立足於校園實際，著眼於未來發展，建成符合標准化協議、通用性較強、實用的系統，以提高圖書信息的現代化管理水平，實現信息資源的共享。
2.1.1 系統建設目標
（1）要解決的問題：（以某學校為參照） 隨著辦公自動化水平的不斷提高，現在學校管理學生信息也逐步從手工轉到計算機自動化信息處理階段。設計一個功能完整、操作簡便、界面友好的學生信息管理系統已經是勢在必行的了。
（2）系統開發的目的：提高圖書管理工作的效率，減少相關人員的工作量，使學校的圖書管理工作真正做到科學、合理的規劃，系統、高效的實施。
（3）系統名稱：圖書管理系統
2.2 總體功能設計
系統要能實現如下功能：
l 登錄系統：注銷用戶、系統退出。
l 管理：用戶管理、圖書管理、讀者管理、借閱管理。
l 查詢：圖書查詢、讀者查詢、借閱查詢。
l 報表列印：所有圖書、借出圖書、庫存圖書、所有讀者。
l 幫助：使用說明、關於。
3 資料庫設計
3.1 資料庫系統的選擇
本系統是一個中小型管理系統，運行環境是Windows2000 server，因此使用Windows環境下最容易使用且功能還可以的Microsoft Access 2000 作為後台的資料庫系統。
3.2 需求分析
圖3 圖書流通數據流圖
1．2
判斷能
否借書
索書
信息
讀 者
1．2
辦理借
書手續
讀者信息
查詢結果
借書申請
被借圖書
借書結果
借書信息
被借圖書復本量
(b) 借書
借閱
3
讀者
1
圖書
5
1．1
圖書
查詢
借書信息
查詢
4
判斷
2
判斷結果
索書
信息
圖書信息
讀 者
1
借書
2
還書
讀 者
申請借書
還書申請
借書結果
還書結果
(a) 頂層數據流圖
3
辦借
書證
讀者信息
辦證信息
需求分析是資料庫設計首先要做的工作，通過需求分析，我們作出了圖書管理系統的各層數據流圖，圖3是圖書流通數據流圖（圖中省略了「還書」和「辦理借書證」的數據流圖）。
在數據流圖的基礎上，定義數據字典。數據字典是關於資料庫中數據的描述，它的作用是在軟體分析和設計過程中為有關人員提供關於數據描述信息的查詢，以保證數據的一致性。下面在圖3的基礎上舉例說明數據字典的定義。
圖3中涉及很多數據項，其中數據項「讀者編號」可以描述如下：
數據項名：讀者編號
別名：讀者條碼
含義：唯一標識每個讀者
類型：字元型
取值范圍：00000000至99999999
取值含義：順序編號
「讀者」一個數據結構，它可以描述如下：
數據結構名：讀者
含義說明：是圖書管理系統的數據結構之一，定義了一個讀者的有關信息
組成：讀者編號，姓名，性別，單位
數據流「借閱記錄」可描述如下：
數據流名：借閱記錄
說明：讀者的借書記錄
數據來源：辦理借閱手續
數據去向：借閱
數據結構：讀者編號、圖書館藏號、借閱日期
數據存儲「借閱」可以描述如下：
數據存儲名：借閱
說明：記錄讀者的借書情況
流出數據流：借閱記錄
流入數據流：借閱記錄
數據描述：讀者編號、圖書館藏號、借閱日期
數據量：每年5000條以上
存取方式：隨機存取
處理過程「判斷能否借書」可描述如下：
處理過程「判斷能否借書」
說明：根據讀者的已借書情況可被借圖書的館藏情況判斷讀者能否借書
輸入：借閱記錄、讀者信息、被借圖書信息
輸出：能否借書的標志
處理：讀者提出借書請求後，先判斷該讀者以前的借書量是否達到了10本，如果達到了10本，則不能再借書，如果沒有達到10本，則再判斷讀者要借的圖書的可借量是否為0，如果不為0，則該書可以借出。
3.3 資料庫設計
在圖書管理系統中，資料庫設計占重要位置，資料庫設計質量的優劣，可直接影響到資料庫數據的冗餘度、數據的一致性、數據丟失等問題。下面就系統資料庫規范化設計進行說明。
3.3.1 資料庫設計的理論指導
資料庫設計的理論指導是範式理論，其主要內容如下：
1）如果關系模式R，其所有的域為單純域則稱R是規范化的關系，或稱第一範式 (1NF)
2）如果關系模式R為第一範式，且每個非主屬性完全函數依賴於碼，則模式R為第二範式（2NF）。
3) 如果關系模式R為第二範式，且每個非主屬性非傳遞依賴於碼，則稱關系模式R為第三範式(3NF)。
4)關系模式R為第一範式，滿足函數依賴集合F，X和A均為R的屬性集合，且X不包含A，如果R滿足X－>A且X必包含R的碼，稱關系模式R為BCNF範式。
3.3.2 資料庫設計
圖書管理系統資料庫常常要設計含有如下數據項：借書證號、姓名、單位、館藏號(館藏號為每本書上的條形碼號)、書名、分類號、作者、價格等。如何進行模式的設計呢？下面以圖書流通模塊所涉及的資料庫為例來說明。
圖 書
讀 者
借閱
m
n
借閱時間
館藏號
書名
分類號
作者
價格
借書證號
姓名
性別
圖4 圖書流通的E-R圖
屬於
單 位
1
n
單位名稱
單位編號
先設計圖書流通的實體－關系圖(E-R圖)。E-R圖由3個相關聯的部分構成，即實體、實體與實體之間的關系以及實體和關系的屬性。圖書流通過程中實體「圖書」與「讀者」之間的關系是借閱和被借閱的關系，實體「讀者」與「單位」之間的關系是屬於和被屬於的關系，「圖書」的屬性有「館藏號」、「書名」、「分類號」、「作者」、「價格」，「讀者」的屬性有「借書證號」、「姓名」、「性別」，「單位」的屬性有「單位編號」和「單位名稱」，「借閱」屬性「借書日期」，由此得出E-R圖如圖4。
從圖中可以知道：
①「借書證號」是唯一的，所以「借書證號」決定「姓名」，每位讀者應只屬於一個性別，所以「借書證號」也決定「性別」；
②「館藏號」是唯一的，所以「館藏號」決定「書名」、「分類號」、「作者」、「價格」；
③ 「單位編號」是唯一的，所以「單位編號」決定「單位名稱」；
④ 每位讀者在一個時間只能借一本書，所以「借書證號」 +「館藏號」決定「借閱時間」。
如果將這些數據項置於一個關系模式中，根據範式理論，該關系模式屬於1NF（第一範式），它存在刪除異常和冗餘等問題，不是理想的模式，因此要把它分解成滿足3NF或BCNF的關系模式。根據範式理論和E-R圖轉換成關系模型的規則，上面的E-R圖可轉換為4個關系模式：①圖書（館藏號、書名、分類號、作者、價格）；②讀者（借書證號、姓名、性別、單位編號）；③借閱（借書證號、館藏號、借閱時間），④單位(單位編碼、單位名稱)，其中打下劃線的為碼，這樣就解決了插入、刪除和數據冗餘等問題。
我們對數據的結構進行詳細的分析，按照上述的設計思想，共設計了讀者表，書目表，館藏表，流通表等百餘張數據表，然後創建視圖和存儲過程。下面舉例說明：
讀者表：借書證號、姓名、單位、讀者類別、職稱等欄位；
書目表：館藏號、ISBN、題名、作者、出版社、復本數、語種、文獻類型、版次等欄位；
館藏表：館藏號、索書號、分類號、種次號、館藏位置、單價、出版日期等欄位；
流通表：借書證號、館藏號、借期、還期、續借、應還期、操作員等欄位；
借閱規則表：讀者類別編碼、圖書類別編碼、限借冊數、每期天數、續借天數、過期日期、罰金等欄位。
讀者類別表：讀者類別編碼、讀者類別等欄位。
圖書類別表：圖書類別編碼、圖書類別等欄位。
3.4 資料庫索引
建立索引是加快查詢速度的有效手段，資料庫的每一個表建立了主鍵，主鍵由一個或幾個欄位組成，每一個表都按主鍵建立了索引，部分表為了滿足查詢和排序的需要，除建立主索引外，還建立了次索引。例如在查詢時要用到「館藏號」、「作者」、「題名」等條件來查找圖書，因此，在書目表上除了對主鍵「館藏號」建立了主索引外，也對「作者」、「書名」等建立了次索引。
3.5 視圖
視圖是從一個或幾個基本表導出的表，它是定義在基本表之上的，它是一個虛表，資料庫中只存放視圖的定義，而不存放視圖對應的數據，數據仍然存放在原來的基本表中。通過定義視圖，可以使用戶眼中的資料庫結構簡單、清晰，並可以簡化用戶的數據查詢操作。由於本系統數據表較多，表中的欄位多，為了簡化對表的操作，我們創建了圖書_按書名查詢、期刊_按刊名查詢、期刊_按編輯部查詢、借閱規則查詢、待還書查詢、超期記錄查詢等30餘個視圖。
3.6 存儲過程
存儲過程是一段經過編譯的程序代碼，存放在資料庫伺服器端。通過調用適當的存儲過程，可在伺服器端處理大量數據，再將處理結果送到客戶端。這樣可減少數據在網路上的傳送，消除網路阻塞現象；例如：要查詢某條記錄，若該記錄在表中的順序號是10000，不採用存儲過程，伺服器將從1至於10000條記錄數據逐條送至客戶端，採用存儲過程後，由於過程是經過編譯的並且是在本地，不需要通過網路，因此能很快查出所需記錄並將結果送到客戶端，大大減少了網上數據傳輸量。存儲過程另一好處是可供不同的開發工具調用，如PB、VB、ASP、Delphi等開發工具均可調用。在流通模塊和WEB查詢模塊上均有圖書檢索功能，實際上調用同一存儲過程完成的。本系統建立了60多個存儲過程，實現諸如借還書處理、新書入庫統計、編目入館藏、讀者統計、生成索書號等功能。
3.7 資料庫調用
採用ODBC介面實現資料庫的調用，採用ADO介面調用。
4 條形碼的使用
條形碼具有唯一性和一次輸入後就可反復使用的優點，利用條形碼技術作為信息快速輸入的手段可迅速且不易發生錯誤地處理圖書管理業務。本系統使用條形碼作為圖書和讀者的標識，實現標識的唯一性。
使用條碼後，能夠使圖書管理工作更加簡單、快捷、不易出錯。例如，當一本書具有唯一條形碼標識，每位讀者也具有唯一條形碼標識時，圖書的借閱、查詢就十分便捷了。應用條形碼取代了以往填寫書袋卡、借書證，核對借閱時間等繁瑣的手工勞動。讀者在借書時只要將借書證給工作人員，工作人員只需登錄借書系統，用條形碼閱讀器掃描讀者借書證上的條形碼，屏幕就會顯示出該讀者的信息，包括讀者姓名、單位、可借幾本書、已借幾本書、是否過期、有無罰款等。如可以借書，工作人員只需用條形碼閱讀器掃描該讀者所需借的書上的條形碼符號後，該書的書名和條形碼等信息都從資料庫中調出顯示在屏幕上，自動記錄在該讀者的借閱檔案中，借書工作即告完成。一般借一本書僅需 1至 2秒鍾。操作完後，計算機自動地將該借閱者和借閱的圖書號碼輸入對應資料庫中，並自動提示借閱期限。
參考文獻
[1] 王珊著、資料庫系統原理教程，清華大學出版社，2002.1
[2] 齊治昌等著、軟體工程，高等教育出版社，2002.1
[3] 網路資源
Ⅳ 資料庫編寫書店系統
我有書店系統的課程設計
Ⅵ 在軟體開發中，需求規格說明書和系統設計說明書有什麼區別
1、內容有區別
需求規格說明書主要是描述軟體系統應該完成的功能，包含硬體、功能、性能、輸入輸出、介面需求、警示信息、保密安全、數據與資料庫、文檔和法規的要求等等。
設計說明書是說明如何實現這些功能、性能的。設計書中會對功能進行重新的分解，並需要描述這些功能如何實現，甚至包括如何用代碼實現。
2、目的不同
需求規格說明書的作用在於便於用戶、開發人員進行理解和交流，反映出用戶問題的結構，可以作為軟體開發工作的基礎和依據，並作為確認測試和驗收的依據。
系統設計說明書編制的目的是說明對程序系統的設計考慮，包括程序系統的基本處理流程、程序系統的組織結構、模塊劃分、功能分配、介面設計、運行設計、安全設計、數據結構設計和出錯處理設計等，為程序的詳細設計提供基礎。
3、閱讀對象不同
需求規格說明書主要從用戶角度（需求或市場人員根據用戶要求編寫）描述軟體需要實現的功能。
系統設計說明書主要從軟體開發（程序員）角度描述軟體需要實現功能。
Ⅶ 急！高分求做SQL Server資料庫設計【達人請進】
下述十四個技巧，是許多人在大量的資料庫分析與設計實踐中，逐步總結出來的。對於這些經驗的運用，讀者不能生幫硬套，死記硬背，而要消化理解，實事求是，靈活掌握。並逐步做到：在應用中發展，在發展中應用。
1. 原始單據與實體之間的關系
可以是一對一、一對多、多對多的關系。在一般情況下，它們是一對一的關系：即一張原始單據對應且只對應一個實體。在特殊情況下，它們可能是一對多或多對一的關系，即一張原始單證對應多個實體，或多張原始單證對應一個實體。這里的實體可以理解為基本表。明確這種對應關系後，對我們設計錄入界面大有好處。
〖例1〗：一份員工履歷資料，在人力資源信息系統中，就對應三個基本表：員工基本情況表、社會關系表、工作簡歷表。這就是「一張原始單證對應多個實體」的典型例子。
2. 主鍵與外鍵
一般而言，一個實體不能既無主鍵又無外鍵。在E?R 圖中, 處於葉子部位的實體, 可以定義主鍵，也可以不定義主鍵(因為它無子孫), 但必須要有外鍵(因為它有父親)。
主鍵與外鍵的設計，在全局資料庫的設計中，佔有重要地位。當全局資料庫的設計完成以後，有個美國資料庫設計專家說：「鍵，到處都是鍵，除了鍵之外，什麼也沒有」，這就是他的資料庫設計經驗之談，也反映了他對信息系統核心(數據模型)的高度抽象思想。因為：主鍵是實體的高度抽象，主鍵與外鍵的配對，表示實體之間的連接。
3. 基本表的性質
基本表與中間表、臨時表不同，因為它具有如下四個特性：
(1) 原子性。基本表中的欄位是不可再分解的。
(2) 原始性。基本表中的記錄是原始數據(基礎數據)的記錄。
(3) 演繹性。由基本表與代碼表中的數據，可以派生出所有的輸出數據。
(4) 穩定性。基本表的結構是相對穩定的，表中的記錄是要長期保存的。
理解基本表的性質後，在設計資料庫時，就能將基本表與中間表、臨時表區分開來。
4. 範式標准
基本表及其欄位之間的關系, 應盡量滿足第三範式。但是，滿足第三範式的資料庫設計，往往不是最好的設計。為了提高資料庫的運行效率，常常需要降低範式標准：適當增加冗餘，達到以空間換時間的目的。
〖例2〗：有一張存放商品的基本表，如表1所示。「金額」這個欄位的存在，表明該表的設計不滿足第三範式，因為「金額」可以由「單價」乘以「數量」得到，說明「金額」是冗餘欄位。但是，增加「金額」這個冗餘欄位，可以提高查詢統計的速度，這就是以空間換時間的作法。
在Rose 2002中，規定列有兩種類型：數據列和計算列。「金額」這樣的列被稱為「計算列」，而「單價」和「數量」這樣的列被稱為「數據列」。
表1 商品表的表結構
商品名稱 商品型號 單價 數量 金額
電視機 29? 2,500 40 100,000
5. 通俗地理解三個範式
通俗地理解三個範式，對於資料庫設計大有好處。在資料庫設計中，為了更好地應用三個範式，就必須通俗地理解三個範式(通俗地理解是夠用的理解，並不是最科學最准確的理解)：
第一範式：1NF是對屬性的原子性約束，要求屬性具有原子性，不可再分解;
第二範式：2NF是對記錄的惟一性約束，要求記錄有惟一標識，即實體的惟一性;
第三範式：3NF是對欄位冗餘性的約束，即任何欄位不能由其他欄位派生出來，它要求欄位沒有冗餘.
沒有冗餘的資料庫設計可以做到。但是，沒有冗餘的資料庫未必是最好的資料庫，有時為了提高運行效率，就必須降低範式標准，適當保留冗餘數據。具體做法是：在概念數據模型設計時遵守第三範式，降低範式標準的工作放到物理數據模型設計時考慮。降低範式就是增加欄位，允許冗餘。
6. 要善於識別與正確處理多對多的關系
若兩個實體之間存在多對多的關系，則應消除這種關系。消除的辦法是，在兩者之間增加第三個實體。這樣，原來一個多對多的關系，現在變為兩個一對多的關系。要將原來兩個實體的屬性合理地分配到三個實體中去。這里的第三個實體，實質上是一個較復雜的關系，它對應一張基本表。一般來講，資料庫設計工具不能識別多對多的關系，但能處理多對多的關系。
〖例3〗：在「圖書館信息系統」中，「圖書」是一個實體，「讀者」也是一個實體。這兩個實體之間的關系，是一個典型的多對多關系：一本圖書在不同時間可以被多個讀者借閱，一個讀者又可以借多本圖書。為此，要在二者之間增加第三個實體，該實體取名為「借還書」，它的屬性為：借還時間、借還標志(0 表示借書，1表示還書)，另外，它還應該有兩個外鍵(「圖書」的主鍵，「讀者」的主鍵)，使它能與「圖書」和「讀者」連接。
7. 主鍵PK的取值方法
PK是供程序員使用的表間連接工具，可以是一無物理意義的數字串, 由程序自動加1來實現。也可以是有物理意義的欄位名或欄位名的組合。不過前者比後者好。當PK是欄位名的組合時，建議欄位的個數不要太多，多了不但索引佔用空間大，而且速度也慢。
8. 正確認識數據冗餘
主鍵與外鍵在多表中的重復出現, 不屬於數據冗餘，這個概念必須清楚，事實上有許多人還不清楚。非鍵欄位的重復出現, 才是數據冗餘!而且是一種低級冗餘，即重復性的冗餘。高級冗餘不是欄位的重復出現，而是欄位的派生出現。
〖例4〗：商品中的「單價、數量、金額」三個欄位，「金額」就是由「單價」乘以「數量」派生出來的，它就是冗餘，而且是一種高級冗餘。冗餘的目的是為了提高處理速度。只有低級冗餘才會增加數據的不一致性，因為同一數據，可能從不同時間、地點、角色上多次錄入。因此，我們提倡高級冗餘(派生性冗餘)，反對低級冗餘(重復性冗餘)。
9. E--R圖沒有標准答案
信息系統的E--R圖沒有標准答案，因為它的設計與畫法不是惟一的，只要它覆蓋了系統需求的業務范圍和功能內容，就是可行的。反之要修改E-- R圖。盡管它沒有惟一的標准答案，並不意味著可以隨意設計。好的E?R圖的標準是：結構清晰、關聯簡潔、實體個數適中、屬性分配合理、沒有低級冗餘。
10. 視圖技術在資料庫設計中很有用
與基本表、代碼表、中間表不同，視圖是一種虛表，它依賴數據源的實表而存在。視圖是供程序員使用資料庫的一個窗口，是基表數據綜合的一種形式, 是數據處理的一種方法，是用戶數據保密的一種手段。為了進行復雜處理、提高運算速度和節省存儲空間, 視圖的定義深度一般不得超過三層。若三層視圖仍不夠用, 則應在視圖上定義臨時表, 在臨時表上再定義視圖。這樣反復交迭定義, 視圖的深度就不受限制了。
對於某些與國家政治、經濟、技術、軍事和安全利益有關的信息系統，視圖的作用更加重要。這些系統的基本表完成物理設計之後，立即在基本表上建立第一層視圖，這層視圖的個數和結構，與基本表的個數和結構是完全相同。並且規定，所有的程序員，一律只准在視圖上操作。只有資料庫管理員，帶著多個人員共同掌握的「安全鑰匙」，才能直接在基本表上操作。請讀者想想：這是為什麼?
11. 中間表、報表和臨時表
中間表是存放統計數據的表，它是為數據倉庫、輸出報表或查詢結果而設計的，有時它沒有主鍵與外鍵(數據倉庫除外)。臨時表是程序員個人設計的，存放臨時記錄，為個人所用。基表和中間表由DBA維護，臨時表由程序員自己用程序自動維護。
12. 完整性約束表現在三個方面
域的完整性：用Check來實現約束，在資料庫設計工具中，對欄位的取值范圍進行定義時，有一個Check按鈕，通過它定義欄位的值城。參照完整性：用PK、FK、表級觸發器來實現。用戶定義完整性：它是一些業務規則，用存儲過程和觸發器來實現。
13. 防止資料庫設計打補丁的方法是「三少原則」
(1) 一個資料庫中表的個數越少越好。只有表的個數少了，才能說明系統的E--R圖少而精，去掉了重復的多餘的實體，形成了對客觀世界的高度抽象，進行了系統的數據集成，防止了打補丁式的設計;
(2) 一個表中組合主鍵的欄位個數越少越好。因為主鍵的作用，一是建主鍵索引，二是做為子表的外鍵，所以組合主鍵的欄位個數少了，不僅節省了運行時間，而且節省了索引存儲空間;
(3) 一個表中的欄位個數越少越好。只有欄位的個數少了，才能說明在系統中不存在數據重復，且很少有數據冗餘，更重要的是督促讀者學會「列變行」，這樣就防止了將子表中的欄位拉入到主表中去，在主表中留下許多空餘的欄位。所謂「列變行」，就是將主表中的一部分內容拉出去，另外單獨建一個子表。這個方法很簡單，有的人就是不習慣、不採納、不執行。
資料庫設計的實用原則是：在數據冗餘和處理速度之間找到合適的平衡點。「三少」是一個整體概念，綜合觀點，不能孤立某一個原則。該原則是相對的，不是絕對的。「三多」原則肯定是錯誤的。試想：若覆蓋系統同樣的功能，一百個實體(共一千個屬性) 的E--R圖，肯定比二百個實體(共二千個屬性) 的E--R圖，要好得多。
提倡「三少」原則，是叫讀者學會利用資料庫設計技術進行系統的數據集成。數據集成的步驟是將文件系統集成為應用資料庫，將應用資料庫集成為主題資料庫，將主題資料庫集成為全局綜合資料庫。集成的程度越高，數據共享性就越強，信息孤島現象就越少，整個企業信息系統的全局E?R圖中實體的個數、主鍵的個數、屬性的個數就會越少。
提倡「三少」原則的目的，是防止讀者利用打補丁技術，不斷地對資料庫進行增刪改，使企業資料庫變成了隨意設計資料庫表的「垃圾堆」，或資料庫表的「大雜院」，最後造成資料庫中的基本表、代碼表、中間表、臨時表雜亂無章，不計其數，導致企事業單位的信息系統無法維護而癱瘓。
「三多」原則任何人都可以做到，該原則是「打補丁方法」設計資料庫的歪理學說。「三少」原則是少而精的原則，它要求有較高的資料庫設計技巧與藝術，不是任何人都能做到的，因為該原則是杜絕用「打補丁方法」設計資料庫的理論依據。
14. 提高資料庫運行效率的辦法
在給定的系統硬體和系統軟體條件下，提高資料庫系統的運行效率的辦法是：
(1) 在資料庫物理設計時，降低範式，增加冗餘, 少用觸發器, 多用存儲過程。
(2) 當計算非常復雜、而且記錄條數非常巨大時(例如一千萬條)，復雜計算要先在資料庫外面，以文件系統方式用C++語言計算處理完成之後，最後才入庫追加到表中去。這是電信計費系統設計的經驗。
(3) 發現某個表的記錄太多，例如超過一千萬條，則要對該表進行水平分割。水平分割的做法是，以該表主鍵PK的某個值為界線，將該表的記錄水平分割為兩個表。若發現某個表的欄位太多，例如超過八十個，則垂直分割該表，將原來的一個表分解為兩個表。
(4) 對資料庫管理系統DBMS進行系統優化，即優化各種系統參數，如緩沖區個數。
(5) 在使用面向數據的SQL語言進行程序設計時，盡量採取優化演算法。
總之，要提高資料庫的運行效率，必須從資料庫系統級優化、資料庫設計級優化、程序實現級優化，這三個層次上同時下功夫。
Ⅷ 軟體需求說明怎麼寫
如何寫需求分析報告（軟體需求說明書GB856T-88）
近來學校的一些科研項目又在申報了，一些學弟開始Q我一些軟體工程上書面的問題。大概的總結了下，寫到這里。本文涉及到的是需求分析部分的書寫，主要是根據國家標准文檔中的要求來的。
在互聯網公司或者一些敏捷開發的公司里，其實大家都是秉承著重開發，重討論，而輕文檔的態度。這個輕文檔並不是指沒有文檔或者幾乎不做文檔，而是在嚴格的文檔流程中解脫出來，只把最最實際的部分寫出來。這個特徵是有互聯網本身迭代周期短，版本發布快等特點決定的。而在實際的兼職項目的時候，同學們就要注意了，最重要的應該就是在簽合同的時候一定要附上最清楚的一份需求分析，雖然這份需求說明可能不是按照某些標准文檔而來的，描述清楚每個功能達到的效果，而這個效果一定要讓客戶點頭確認，而不能出現「應該是」、「可能是」、「也許是」這樣的模糊回答。否則在項目後期就會比較難過了。在學校申請的項目和大型公司項目開發中，是重視文檔流程的，一部一部來。所以還是看情況來對待文檔的深度和標准。
一、目錄：目錄要用word的「引用」—>」目錄」，自動生成目錄，一般都是要三級目錄。通常這部分基本都不需要改結構，直接更新頁碼即可。
二、內容部分。國家標准軟體需求說明書G856T-88下載
1引言
1.1編寫目的
說明編寫這份軟體需求說明書的目的，指出預期的讀者。
（這部分說明需求分析報告的概況，例如：本X需求分析報告是為S系統而編寫的。+S系統的兩句話概述。+本X報告旨在使U1（需求者）明確S系統的要求和細節，給U2(開發人員)了解需求實現的難度和困難，最終提供給U3（審核人、管理者）討論和審核，達到溝通效果）
1.2背景
說明：
a．待開發的軟體系統的名稱；
b．本項目的任務提出者、開發者、用戶及實現該軟體的計算中心或計算機網路；
c．該軟體系統同其他系統或其他機構的基本的相互來往關系。
（這部分可以將a,b,c分為2部分，例子如下：
1.2.1項目概況
本需求分析報告所預期開發的軟體系統是:S。S是（不是則無）SS系統的某一個功能子模塊，S和S1、S2等系統之間的聯系，以及概述其他系統的狀態等等。
1.2.2任務分配
a.任務提出者：xxx
b.軟體開發者：xx
c.產品使用者：xx
d.文檔編寫者：xx
e.預期產品使用者：xx
）
1.3定義
列出本文件中用到的專門術語的定義和外文首字母組詞的原片語。
（這部分很簡單，就是描述專業詞彙，比如
1. XML(Extensible Markup Language)即可擴展標記語言,它與HTML一樣,都是SGML(Standard Generalized Markup Language,標准通用標記語言)。
2. Word2,解釋。。。
）
1.4參考資料
列出用得著的參考資料，如：
a．本項目的經核準的計劃任務書或合同、上級機關的批文；
b．屬於本項目的其他已發表的文件；
c．本文件中各處引用的文件、資料、包括所要用到的軟體開發標准。列出這些文件資料的標題、文件編號、發表日期和出版單位，說明能夠得到這些文件資料的來源。
2任務概述
2.1目標
敘述該項軟體開發的意圖、應用目標、作用范圍以及其他應向讀者說明的有關該軟體開發的背景材料。解釋被開發軟體與其他有關軟體之間的關系。如果本軟體產品是一項獨立的軟體，而且全部內容自含，則說明這一點。如果所定義的產品是一個更大的系統的一個組成部分，則應說明本產品與該系統中其他各組成部分之間的關系，為此可使用一張方框圖來說明該系統的組成和本產品同其他各部分的聯系和介面。|
（
本模塊開發主要是為SS的整體服務，完成SS工作中的XX部分以及相關的工作。其涉及的范圍就是，從下達A、B命令後，到給出C結果的過程。具體描述：B1，來完成B11功能；B2，來完成B22功能；等等。本部分是（否）耦合在分詞工具包其他部分中的，主要為嵌入方式和先後方式相互交互。
圖
圖1.該系統的組成同其他各部分的聯系和介面
）
2.2用戶的特點
列出本軟體的最終用戶的特點，充分說明操作人員、維護人員的教育水平和技術專長，以及本軟體的預期使甩頻度。這些是軟體設計工作的重要約束
（例如：二次開發和系統調用人員：具有很高的專業知識水平，理解XX的運行機制。可以對開放代碼進行閱讀和分析，以完成其系統獨特的需求，提供給這部分用戶開放API手冊和Debug版本的源代碼即可；預期這部分用戶會占本系統總用戶量的多大部分。
xx使用者：具有一定的計算機操作能力和知識，了解xx領域的相關概念和用途。提供給這部分用戶操作手冊即可。預期這部分使用者主要是來簡單的xx操作。
維護人員：具有較高的計算機專業水平，可以對常見的系統Bug進行追蹤和分析，具有一定的測試能力。這部分用戶主要是採用了本系統之後的後期工作維護者。
等等
）
2.3假定和約束
列出進行本軟體開發工作的假定和約束，例如經費限制、開發期限等。
（這部分重要是對你有的技術力量、資金狀況、人力資源等情況的假設，以使得你可以在什麼樣的情況和時間范圍內完成工作。工期約束，經費約束，人員約束，地理約束，設備約束等幾個方面列舉說明。）
3需求規定
3.1對功能的規定
用列表的方式（例如IPO表即輸入、處理、輸出表的形式），逐項定量和定性地敘述對軟體所提出的功能要求，說明輸入什麼量、經怎樣的處理、得到什麼輸出，說明軟體應支持的終端數和應支持的並行操作的用戶數。
（例如：
INPUT輸入
PROCESS處理
OUTPUT輸出
LOAD負載量
A
預處理,做怎樣的動作，
AA
CC
B
BBBB
Bb
v
C
CCCC
cc
v
表一、xx模塊IPO表
對IPO表的簡單文字描述。
）
3.2對性能的規定
3.2.1精度
說明對該軟體的輸入、輸出數據精度的要求，可能包括傳輸過程中的精度。
（例如：
Xx目標處理：1Byt–10M，包括左右邊界值。
yy精度范圍：….
ZZ的精度：由於xx的特殊性，本系統均採用xx型來進行字元統計運算，概率部分以及其他比率部分精度精確到0.0x%。
）
3.2.2時間特性要求
說明對於該軟體的時間特性要求，如對：
a．響應時間；
b．更新處理時間；
c．數據的轉換和傳送時間；
d．解題時間；等的要求。
(這部分只要一一列舉就可以：
由於xxx過程中，需要大量xxxx操作或怎樣，故xx解題時間占總時間的最大部分。其次就是xx轉換和存儲的開銷。其具體時間特性要求，如下：
a．xx響應時間：xxms左右；
b．yy更新處理時間：yy；
c．zz數據的轉換和傳送時間：zz；
d．vv解題時間：vv。
等等
)
3.2.3靈活性
說明對該軟體的靈活性的要求，即當需求發生某些變化時，該軟體對這些變化的適應能力，如：
a．操作方式上的變化；
b．運行環境的變化；
c．同其他軟體的介面的變化；
d．精度和有效時限的變化；
e．計劃的變化或改進。
對於為了提供這些靈活性而進行的專門設計的部分應該加以標明。
（這部分按列舉來即可，由於本模塊第一目的是用於xxx，其次則是xxxx。故本模塊的靈活性在於實際應用者的不同。當需求發生某些變化時，該軟體對這些變化的適應能力。具體情況如下：
f．操作方式上的變化：採用集成運行制和獨立運行制兩種模式，集成運行制是把本模塊嵌入到分詞工具包的主框架中，提供給用戶具有一定UI的可操作軟體；獨立運行制是可以獨立運行於後台，並提供給各種程序調用的模式的工作方式，以增強其生命力。
g．運行環境的變化：主採用Windows平台的編譯版本運行和調試，在時間允許的情況下，同步開發支持SUSE Linux的伺服器版本。；
h．同其他軟體的介面的變化：在盡量保證介面不出現變動的情況下，允許介面的重載和再定義。但介面的命名規則是統一的；
i．精度和有效時限的變化：精度在必須調整的條件下，可以上下浮動10個百分點；有效時限則依據現實的測試情況允許稍大范圍的變化。
j．計劃的變化或改進：工作時間安排會存在必然的浮動，這部分要協同分詞工具包課題設計組其他成員一同來進行商定，前期的計劃可以稍微有些變動，後期的安排盡量按照計劃執行。
等等
）
3.3輸人輸出要求
解釋各輸入輸出數據類型，並逐項說明其媒體、格式、數值范圍、精度等。對軟體的數據輸出及必須標明的控制輸出量進行解釋並舉例，包括對硬拷貝報告（正常結果輸出、狀態輸出及異常輸出）以及圖形或顯示報告的描述。
（這部分可以把輸入輸出分為3.3.1輸入要求和3.3.2輸出要求，如下給出一個單元的例子。
XXX輸出
數據名稱：XXX輸出數據
實際含義：用於XX,表示XXXX
數據類型：Character(字元串)
數據格式：XX
數據約束：由於xxx,，大小在xx以內
）
3.4數據管理能力要求
說明需要管理的文卷和記錄的個數、表和文卷的大小規模，要按可預見的增長對數據及其分量的存儲要求作出估算。
（
根據實際系統要求列舉即可
Name名稱
Number數量
Size大小
Increase增長
詞典xx
xx
xxxx
並行執行，其大小依據實際xx大文本而增長
）
3.5故障處理要求
列出可能的軟體、硬體故障以及對各項性能而言所產生的後果和對故障處理的要求。
（包括軟體壓力，內存不足，硬體損壞等，這部分可以根據網路到其常見故障。）
3.6其他專門要求
如用戶單位對安全保密的要求，對使用方便的要求，對可維護性、可補充性、易讀性、可靠性、運行環境可轉換性的特殊要求等。
（例如安全保密性：密鑰更換等；預期擴展：擴展兼容等；OS更換：Slackware轉SUSE等
）
4運行環境規定
4.1設備
列出運行該軟體所需要的硬設備。說明其中的新型設備及其專門功能，包括：
a．處理器型號及內存容量；
b．外存容量、聯機或離線、媒體及其存儲格式，設備的型號及數量；
c．輸入及輸出設備的型號和數量，聯機或離線；
d．數據通信設備的型號和數量；
e．功能鍵及其他專用硬體
（列舉說明即可）
4.2支持軟體
列出支持軟體,包括要用到的操作系統、編譯（或匯編）程序、測試支持軟體等。
（操作系統和版本：xxxx
支撐環境和版本：xxxx
備用IDE環境和版本：xxxx
與該軟體有關的軟體組件：xxxx
後續可能擴展環境：xxxx
）
4.3介面
說明該軟體同其他軟體之間的介面、數據通信協議等。
(例如：
a．用戶和主程序調用介面(圖中介面1)。這個介面採用封裝API形式和函數調用形式，分別以外部調用和內部調用的方式為不同用戶提供使用本機械分詞工具的入口。例如以xxxx方式調用DLL文件，以xxxx方式調用函數。如下圖2所示。
圖2.軟體介面調用圖
b.xx介面(圖中介面2)。這里是一個xxx的介面調用過程。xxxx
)
4.4控制
說明控制該軟體的運行的方法和控制信號，並說明這些控制信號的來源。
(例如：
下面通過圖表的形式，將本模塊以及涉及到本模塊的軟體模塊的運行方法、控制信號，以及這些控制信號的來源，其中箭頭所指方向對應的模塊的控制信號來自箭頭另一方向的模塊，具體情況如下：
圖3 .控制流程圖
圖3的具體說明情況如下表所示：
Name模塊名稱
Method運行方式
Signal控制信號
Forward控制去向
主程序模塊
運行框架
用戶調用或運行
1.調用xx模塊
2.調用xx方法
3.調用標准輸出模塊
xxx模塊
xxx
xxx調用
Xxx模塊
)
附錄：軟體設計文檔國家標准(GB8567–88)軟體設計文檔國家標准(GB8567–88)GB8567——88
操作手冊（GB8567——88）.doc 資料庫設計說明書（GB8567——88）.doc
測試分析報告（GB8567——88）.doc 數據要求說明書（GB856T——88）.doc
測試計劃（GB8567——88）.doc 圖1.doc
概要設計說明書（GB8567——88）.doc 文件給制實施規定的實例（GB8567-88）.doc
開發進度月報（GB8567——88）.doc 詳細設計說明書（GB8567——88）.doc
可行性研究報告（GB8567——88）.doc 項目開發計劃（GB856T——88）.doc
模塊開發卷宗（GB8567——88）.doc 項目開發總結報告（GB8567——88）.doc
軟體需求說明書（GB856T——88）.doc 用戶手冊（GB8567——88）.doc
Ⅸ 簡述資料庫應用系統的設計步驟
資料庫設計的基本步驟：
1、系統需求分析與設計。
2、概念結構分析與設計。
3、邏輯結構分析與設計。
4、物理結構分析與設計。
5、系統實施。
6、系統維護。
(9)資料庫系統需求說明書擴展閱讀：
資料庫設計技巧：
1、原始文件與實體的關系
它可以是一對一，一對多，多對多的關系。一般來說，它們是一對一的關系：一個原始文檔只對應於一個實體。在特殊情況下，它們可以是一對多或多對一關系，即一個原始文檔對應於多個實體，或者多個原始文檔對應於一個實體。
這里的實體可以理解為基本表。在對應關系明確後，對輸入介面的設計非常有利。
2、主鍵和外鍵
一般來說，實體不能既沒有主鍵也沒有外鍵。在E－R圖中，葉中的實體可以定義主鍵或不定義主鍵（因為它沒有子代），但它必須有外鍵（因為它有父項）。
主鍵和外鍵的設計在全局資料庫的設計中起著重要的作用。當全球資料庫的設計完成後，一位美國資料庫設計專家說：「鑰匙無處不在，只有鑰匙。」。這是他資料庫設計的經驗，也體現了他對信息系統核心（數據模型）高度抽象的理念。
因為：主鍵是一個高度抽象的實體。主鍵和外鍵的配對表示實體之間的連接。
3、基本表的屬性
基本表不同於中間表和臨時表，因為它具有以下四個特點：
原子性。基本表中的欄位不可分解。
原始主義。基本表中的記錄是原始數據（基本數據）的記錄。
演繹的。所有輸出數據都可以從基本表和代碼表中的數據導出。
穩定。基本表的結構比較穩定，表中的記錄要長期保存。
在了解基本表的性質之後，在設計資料庫時，可以將基本表與中間表和臨時表區分開來。
Ⅹ 什麼是資料庫系統的一份重要文件是系統開發的標准和依據
資料庫應用系統的開發是一項軟體工程。一般可分為以下幾個階段：
1.規劃 2.需求分析 3.概念模型設計 4. 邏輯設計5.物理設計 6.程序編制及調試 7.運行及維護。 這些階段的劃分目前尚無統一的標准，各階段間相互聯接，而且常常需要回溯修正。 在資料庫應用系統的開發過程中，每個階段的工作成果就是寫出相應的文檔。每個階段都是在上一階段工作成果的基礎上繼續進行，整個開發工程是有依據、有組織、有計劃、有條不紊地展開工作。
1.規劃規劃的主要任務就是作必要性及可行性分析。 在收集整理有關資料的基礎上，要確定將建立的資料庫應用系統與周邊的關系，要對應用系統定位，其規模的大小、所處的地位、應起的作用均須作全面的分析和論證。 明確應用系統的基本功能，劃分資料庫支持的范圍。分析數據來源、數據採集的方式和范圍，研究數據結構的特點，估算數據量的大小，確立數據處理的基本要求和業務的規范標准。 規劃人力資源調配。對參與研製和以後維護系統運作的管理人員、技術人員的技術業務水平提出要求，對最終用戶、操作員的素質作出評估。 擬定設備配置方案。論證計算機、網路和其他設備在時間、空間兩方面的處理能力，要有足夠的內外存容量，系統的響應速度、網路傳輸和輸入輸出能力應滿足應用需求並留有餘量。要選擇合適的os,dbms和其它軟體。設備配置方案要在使用要求、系統性能、購置成本和維護代價各方面綜合權衡。 對系統的開發、運行、維護的成本作出估算。預測系統效益的期望值。 擬定開發進度計劃，還要對現行工作模式如何向新系統過渡作出具體安排。 規劃階段的工作成果是寫出詳盡的可行性分析報告和資料庫應用系統規劃書。內容應包括：系統的定位及其功能、數據資源及數據處理能力、人力資源調配、設備配置方案、開發成本估算、開發進度計劃等。 可行性分析報告和資料庫應用系統規劃書經審定立項後，成為後續開發工作的總綱。 2.需求分析需求分析大致可分成三步來完成。 (1) 需求信息的收集, 需求信息的收集一般以機構設置和業務活動為主幹線，從高層中層到低層逐步展開 (2) 需求信息的分析整理, 對收集到的信息要做分析整理工作。數據流圖(dfd, data flow diagram)是業務流程及業務中數據聯系的形式描述。圖4.1是一個簡單的dfd 示例。 數據字典(dd, data dictionary)詳細描述系統中的全部數據。 數據字典包含以下幾個部分。 數據項：是數據的原子單位。 數據組項：由若干數據項組成。 數據流：表示某一數據加工過程的輸入/輸出數據。 數據存儲：是處理過程中要存取的數據。 數據加工過程 數據加工過程的描述包括：數據加工過程名、說明、輸入、輸出、加工處理工作摘要、加工處理頻度、加工處理的數據量、響應時間要求等。 數據流圖既是需求分析的工具，也是需求分析的成果之一。數據字典是進行數據收集和數據分析的主要成果。 (3) 需求信息的評審. 開發過程中的每一個階段都要經過評審，確認任務是否全部完成，避免或糾正工作中出現的錯誤和疏漏。聘請項目外的專家參與評審，可保證評審的質量和客觀性。 評審可能導致開發過程回溯，甚至會反復多次。但是，一定要使全部的預期目標都達到才能讓需求分析階段的工作暫告一個段落. 需求分析階段的工作成果是寫出一份既切合實際又具有預見的需求說明書，並且附以一整套詳盡的數據流圖和數據字典。 3.概念模型設計概念模型不依賴於具體的計算機系統，他是純粹反映信息需求的概念結構。 建模是在需求分析結果的基礎上展開，常常要對數據進行抽象處理。常用的數據抽象方法是『聚集』和『概括』。 er方法是設計概念模型時常用的方法。用設計好的er圖再附以相應的說明書可作為階段成果 概念模型設計可分三步完成。 (1) 設計局部概念模型 ① 確定局部概念模型的范圍 ② 定義實體 ③ 定義聯系 ④ 確定屬性 ⑤ 逐一畫出所有的局部er圖，並附以相應的說明文件 (2) 設計全局概念模型 建立全局er圖的步驟如下： ① 確定公共實體類型 ② 合並局部er圖 ③ 消除不一致因素 ④ 優化全局er圖 ⑤ 畫出全局er圖，並附以相應的說明文件。 (3) 概念模型的評審 概念模型的評審分兩部分進行 第一部分是用戶評審。 第二部分是開發人員評審。 4.邏輯設計邏輯設計階段的主要目標是把概念模型轉換為具體計算機上dbms所支持的結構數據模型。 邏輯設計的輸入要素包括：概念模式、用戶需求、約束條件、選用的dbms的特性。 邏輯設計的輸出信息包括：dbms可處理的模式和子模式、應用程序設計指南、物理設計指南。 (1) 設計模式與子模式 關系資料庫的模式設計可分四步完成。 ① 建立初始關系模式 ② 規范化處理 ③ 模式評價 ④ 修正模式 經過多次的模式評價和模式修正，確定最終的模式和子模式。 寫出邏輯資料庫結構說明書。 (2) 編寫應用程序設計指南 根據設計好的模式和應用需求，規劃應用程序的架構，設計應用程序的草圖，指定每個應用程序的數據存取功能和數據處理功能梗概，提供程序上的邏輯介面。 編寫出應用程序設計指南。 (3) 編寫物理設計指南。 根據設計好的模式和應用需求，整理出物理設計階段所需的一些重要數據和文檔。例如，資料庫的數據容量、各個關系(文件)的數據容量、應用處理頻率、操作順序、響應速度、各個應用的lra和tv、程序訪問路徑建議，等等。這些數據和要求將直接用於物理資料庫的設計。 編寫出物理設計指南。 5.物理設計物理設計是對給定的邏輯數據模型配置一個最適合應用環境的物理結構。 物理設計的輸入要素包括：模式和子模式、物理設計指南、硬體特性、os和dbms的約束、運行要求等。 物理設計的輸出信息主要是物理資料庫結構說明書。其內容包括物理資料庫結構、存儲記錄格式、存儲記錄位置分配及訪問方法等。 物理設計的步驟如下： (1) 存儲記錄結構 設計綜合分析數據存儲要求和應用需求，設計存儲記錄格式。 (2) 存儲空間分配 存儲空間分配有兩個原則： ①存取頻度高的數據盡量安排在快速、隨機設備上，存取頻度低的數據則安排在速度較慢的設備上。 ②相互依賴性強的數據盡量存儲在同一台設備上，且盡量安排在鄰近的存儲空間上。 從提高系統性能方面考慮，應將設計好的存儲記錄作為一個整體合理地分配物理存儲區域。盡可能充分利用物理順序特點，把不同類型的存儲記錄指派到不同的物理群中。 (3) 訪問方法的設計 一個訪問方法包括存儲結構和檢索機構兩部分。存儲結構限定了訪問存儲記錄時可以使用的訪問路徑；檢索機構定義了每個應用實際使用的訪問路徑。 (4) 物理設計的性能評價 ① 查詢響應時間 從查詢開始到有結果顯示之間所經歷的時間稱為查詢響應時間。查詢響應時間可進一步細分為服務時間、等待時間和延遲時間。 在物理設計過程中，要對系統的性能進行評價。性能評價包括時間、空間、效率、開銷等各個方面。 ⊙ cpu服務時間和i/o服務時間的長短取決於應用程序設計。 ⊙ cpu隊列等待時間和i/o隊列等待時間的長短受計算機系統作業的影響。 ⊙ 設計者可以有限度地控制分布式資料庫系統的通信延遲時間。 ② 存儲空間 存儲空間存放程序和數據。程序包括運行的應用程序、dbms子程序、os子程序等。數據包括用戶工作區、dbms工作區、os工作區、索引緩沖區、數據緩沖區等。 存儲空間分為主存空間和輔存空間。設計者只能有限度地控制主存空間，例如可指定緩沖區的分配等。但設計者能夠有效地控制輔存空間。 ③ 開銷與效率 設計中還要考慮以下各種開銷，開銷增大，系統效率將下降。 ⊙ 事務開銷指從事務開始到事務結束所耗用的時間。更新事務要修改索引、重寫物理塊、進行寫校驗等操作，增加了額外的開銷。更新頻度應列為設計的考慮因素。 ⊙ 報告生成開銷指從數據輸入到有結果輸出這段時間。報告生成佔用cpu及i/o的服務時間較長。設計中要進行篩選，除去不必要的報告生成。 ⊙ 對資料庫的重組也是一項大的開銷。設計中應考慮數據量和處理頻度這兩個因數，做到避免或盡量減少重組資料庫。 在物理設計階段，設計、評價、修改這個過程可能要反復多次，最終得到較為完善的物理資料庫結構說明書。 建立資料庫時，dba依據物理資料庫結構說明書，使用dbms提供的工具可以進行資料庫配置。 在資料庫運行時，dba監察資料庫的各項性能，根據依據物理資料庫結構說明書的准則，及時進行修正和優化操作，保證資料庫系統能夠保持高效率地運行。 6.程序編制及調試在邏輯資料庫結構確定以後，應用程序設計的編制就可以和物理設計並行地展開 程序模塊代碼通常先在模擬的環境下通過初步調試，然後再進行聯合調試。聯合調試的工作主要有以下幾點： (1) 建立資料庫結構 根據邏輯設計和物理設計的結果，用dbms提供的數據語言(ddl)編寫出資料庫的源模式，經編譯得到目標模式，執行目標模式即可建立實際的資料庫結構。 (2) 調試運行 資料庫結構建立後，裝入試驗數據，使資料庫進入調試運行階段。運行應用程序，測試 (3) 裝入實際的初始數據 在資料庫正式投入運行之前，還要做好以下幾項工作： (1) 制定資料庫重新組織的可行方案。 (2) 制定故障恢復規范 (3) 制定系統的安全規范 7.運行和維護資料庫正式投入運行後，運行維護階段的主要工作是： (1) 維護資料庫的安全性與完整性。 按照制定的安全規范和故障恢復規范，在系統的安全出現問題時，及時調整授權和更改密碼。及時發現系統運行時出現的錯誤，迅速修改，確保系統正常運行。把資料庫的備份和轉儲作為日常的工作，一旦發生故障，立即使用資料庫的最新備份予以恢復。 (2) 監察系統的性能。 運用dbms提供的性能監察與分析工具，不斷地監控著系統的運行情況。當資料庫的存儲空間或響應時間等性能下降時，立即進行分析研究找出原因，並及時採取措施改進。例如，可通修改某些參數、整理碎片、調整存儲結構或重新組織資料庫等方法，使資料庫系統保持高效率地正常運作。 (3) 擴充系統的功能 在維持原有系統功能和性能的基礎上，適應環境和需求的變化，採納用戶的合理意見，對原有系統進行擴充，增加新的功能。