『壹』 軟體詳細設計說明書
面向對象軟體設計說明書模板
1 概述
1.1 系統簡述
對系統要完成什麼，所面向的用戶以及系統運行的環境的簡短描述，這部分主要來源於需求說明書的開始部分。
1.2 軟體設計目標
這部分論述整個系統的設計目標，明確地說明哪些功能是系統決定實現而哪些時不準備實現的。同時，對於非功能性的需求例如性能、可用性等，亦需提及。需求規格說明書對於這部分的內容來說是很重要的參考，看看其中明確了的功能性以及非功能性的需求。
這部分必須說清楚設計的全貌如何，務必使讀者看後知道將實現的系統有什麼特點和功能。在隨後的文檔部分，將解釋設計是怎麼來實現這些的。
1.3 參考資料
列出本文檔中所引用的參考資料。（至少要引用需求規格說明書）
1.4 修訂版本記錄
列出本文檔修改的歷史紀錄。必須指明修改的內容、日期以及修改人。
2 術語表
對本文檔中所使用的各種術語進行說明。如果一些術語在需求規格說明書中已經說明過了，此處不用再重復，可以指引讀者參考需求說明。
3 用例
此處要求系統用用例圖表述（UML），對每個用例（正常處理的情況）要有中文敘述。
4 設計概述
4.1 簡述
這部分要求突出整個設計所採用的方法（是面向對象設計還是結構化設計）、系統的體系結構（例如客戶/伺服器結構）以及使用到的相應技術和工具（例如OMT、Rose）
4.2 系統結構設計
這部分要求提供高層系統結構的描述，使用方框圖來顯示主要的組件及組件間的交互。最好是把邏輯結構同物理結構分離，對前者進行描述。別忘了說明圖中用到的俗語和符號。
4.2.1 頂層系統結構
4.2.2 子系統1結構
4.2.3 子系統2結構
4.3 系統界面
各種提供給用戶的界面以及外部系統在此處要予以說明。如果在需求規格說明書中已經對用戶界面有了敘述，此處不用再重復，可以指引讀者參考需求說明。如果系統提供了對其它系統的介面，比如說從其它軟體系統導入/導出數據，必須在此說明。
4.4 約束和假定
描述系統設計中最主要的約束，這些是由客戶強制要求並在需求說明書寫明的。說明系統是如何來適應這些約束的。
另外如果本系統跟其它外部系統交互或者依賴其它外部系統提供一些功能輔助，那麼系統可能還受到其它的約束。這種情況下，要求清楚地描述與本系統有交互的軟體類型（比如某某某資料庫軟體，某某某EMail軟體）以及這樣導致的約束（比如只允許純文本的Email）。
實現的語言和平台也會對系統有約束，同樣在此予以說明。
對於因選擇具體的設計實現而導致對系統的約束，簡要地描述你的想法思路，經過怎麼樣的權衡，為什麼要採取這樣的設計等等。
5 對象模型
5.1 系統對象模型
提供整個系統的對象模型，如果模型過大，按照可行的標准把它劃分成小塊，例如可以把客戶端和伺服器端的對象模型分開成兩個圖表述。
對象圖應該包含什麼呢？
在其中應該包含所有的系統對象。這些對象都是從理解需求後得到的。要明確哪些應該、哪些不應該被放進圖中。
所有對象之間的關聯必須被確定並且必須指明聯系的基數（一對一、一對多還是多對多，0..1，*，1..*）。聚合和繼承關系必須清楚地確定下來。每個圖必須附有簡單的說明。
可能經過多次反復之後才能得到系統的正確的對象模型。
6 對象描述
在這個部分敘述每個對象的細節，它的屬性、它的方法。在這之前必須從邏輯上對對象進行組織。你可能需要用結構圖把對象按子系統劃分好。
為每個對象做一個條目。在系統對象模型中簡要的描述它的用途、約束（如只能有一個實例），列出它的屬性和方法。如果對象是存儲在持久的數據容器中，標明它是持久對象，否則說明它是個臨時對象（transient object）。
對每個對象的每個屬性詳細說明：名字、類型，如果屬性不是很直觀或者有約束（例如，每個對象的該屬性必須有一個唯一的值或者值域是有限正整數等）。
對每個對象的每個方法詳細說明：方法名，返回類型，返回值，參數，用途以及使用的演算法的簡要說明（如果不是特別簡單的話）。如果對變數或者返回值由什麼假定的話，Pre-conditions和Post-conditions必須在此說明。列出它或者被它調用的方法需要訪問或者修改的屬性。最後，提供可以驗證實現方法的測試案例。
6.1 子系統1中的對象
6.1.1 對象：對象1
用途：
約束：
持久性：
6.1.1.1 屬性描述：
1. 屬性：屬性1
類型：
描述：
約束：
2. 屬性：屬性2
6.1.1.2 方法描述：
1. 方法：方法1
返回類型：
參數：
返回值：
Pre-Condition：
Post-Condition：
讀取/修改的屬性：
調用的方法：
處理邏輯：
測試例：用什麼參數調用該方法，期望的輸出是什麼……
7 動態模型
這部分的作用是描述系統如何響應各種事件。例如，可以建立系統的行為模型。一般使用順序圖和狀態圖。
確定不同的場景（Scenario）是第一步，不需要確定所有可能的場景，但是必須至少要覆蓋典型的系統用例。不要自己去想當然地創造場景，通常的策略是描述那些客戶可以感受得到的場景。
7.1 場景（Scenarios）
對每個場景做一則條目，包括以下內容：
場景名：給它一個可以望文生義的名字
場景描述：簡要敘述場景是干什麼的以及發生的動作的順序。
順序圖：描述各種事件及事件發生的相對時間順序。
7.1.1 場景：場景1
描述：
動作1
動作2
7.2 狀態圖
這部分的內容包括系統動態模型重要的部分的狀態圖。可能你想為每個對象畫一個狀態圖，但事實上會導致太多不期望的細節信息，只需要確定系統中一些重要的對象並為之提供狀態圖即可。
7.2.1 狀態圖1：
8 非功能性需求
在這個部分，必須說明如何處理需求文檔中指定的非功能性需求。盡可能客觀地評估系統應付每一個非功能性的需求的能力程度。如果某些非功能性需求沒有完全在設計的系統中實現，請務必在此說明。另外，你也需要對系統將來的進化作一個估計並描述本設計如何使系統能夠適應這些可預見的變化。
9 輔助文檔
提供能幫助理解設計的相應文檔。
10 詞彙索引
文章錄入
『貳』 程序員不同級別的定位
初級程序員
能熟練掌握一種計算機的操作和使用常用軟體的技術人員
具有初級技術職務（技術員）的實際工作能力和業務知識
考試范圍
一.常用軟體的使用能力和初步的程序編制能力
能使用至少二種以上的下列常用軟體
字處理軟體
表處理軟體
資料庫管理系統軟體
能使用下列語言中的一種編制簡單程序
QBASIC（DOS6.0以上）
C（美國標准）
FoxBASE
二.軟體基礎知識
基本數據結構
數組、記錄、列表（ListStack）的定義、存儲和操作
語言和程序的基礎知識
分支、循環、子程序、函數、和過程
流程圖的標准形式
基本演算法
語言所提供的數據結構和控制結構
匯編、編譯、解釋系統的使用知識
文件系統使用的基本知識
文件組織的類型和特點
文件命令和文件語句的使用
操作系統的類型、功能和使用基礎知識（DOS/Windows）
資料庫系統的基礎知識
通訊和網路的基本概念
計算機信息安全基礎知識
計算機信息安全基本概念
常見計算機病毒的識別
三.硬體基礎知識
數制及其轉換
二進制、十進制、十六進制等常用數制及其相互轉換
機內代碼
原碼、補碼、反碼
定點數與浮點數的機內表示
ASCⅡ碼及漢字編碼等常用的編碼
奇偶校驗碼
算術運算和邏輯運算
二進制數和十進制數的計算機運算方式
邏輯代數的基本運算和邏輯式的化簡
計算機的主要部件
中央處理器CPU（運算器、控制器、寄存器組）
存儲器（主存與輔存）
輸入/ 輸出設備
指令系統
常用的定址方式
指令的格式、分類及功能
網路硬體配置與連接
四.其它基礎知識
英語
高中畢業英語程度
理解操作中常見的英語術語
初等數學
文字處理、排版基礎知識
高級程序員
能按照軟體需求規格說明書進行軟體設計並擔負指導程序員工作的技術人員
具有中級技術職務（工程師）的實際工作能力和業務知識
考試范圍
一.軟體設計能力
簡單計算機應用系統的需求分析
流行的需求分析方法論初步
數據流圖的設計及改進
軟體界面設計
輸入輸出數據文件的設計
用戶界面的設計
軟體間的界面設計
概要設計
模塊劃分方法
模塊調用關系的描述
模塊功能描述
模塊界面描述
常用的設計方法
詳細設計
滿足指定功能的各種處理過程的演算法設計、評價和改進
PDL語言
資料庫/數據結構的設計
根據不同的要求進行資料庫/數據結構的設計、
軟體測試
測試方法
測試用例的設計
測試的靜態和動態分析
測試的計劃與實施
測試報告
測試結果的評價
測試工具
排錯技術
文檔編制
概要設計規格說明書
詳細設計規格說明書
資料庫/數據結構規格說明書
集成測試計劃和集成測試報告
文檔編制標准
文檔編制工具
軟體維護方法和工具
軟體可靠性和安全性設計
設計評審的組織與實施
軟體質量管理和進度管理
二.程序編制能力
程序語言
能使用CASL匯編語言（文本將附在試卷上）（可調閱往年試卷）
能熟練使用下列程序語言中的一種
C（美國標准）/ C＋＋
FORTRAN（國家標准GB3057-82）
根據軟體設計規格說明書，畫出流程圖（國家標准GB1526-89）和編製程序
理解給定的程序和流程圖的功能和實現思想
程序和流程圖的排錯
能對程序和流程圖的正確性進行測試並對發現的錯誤或不足加以糾正或改進
具有良好的程序編制風格
基本演算法的設計和分析
程序編制方法
三.軟體知識
數據結構
數組、記錄、列表（List）、棧（Stack）、堆（Heap）、隊列、樹、圖的定義、存儲和操作
序列、集合等的定義、存儲和操作
程序語言
語言的類別和特點
語言所提供的數據結構、控制結構和模塊結構
典型語言的知識
語言處理程序
匯編系統的基本原理
編譯系統的基本原理
解釋系統的基本原理
文件系統
文件系統結構
文件組織的類型和功能
文件的使用和保護
操作系統
操作系統的歷史和類型
操作系統的層次結構和進程概念
作業管理和處理機管理
存儲管理
設備管理
典型操作系統的知識
資料庫系統
資料庫模型
數據的獨立性、完整性和安全性
數據定義語言和數據操作語言
SQL
典型資料庫管理系統的知識
網路工程
網路OS基本知識
網路的管理與維護
軟體工程
軟體生存周期
軟體設計方法
模塊程序設計和結構化程序設計
軟體測試
軟體維護
軟體質量與評價
原型化方法
常用軟體開發工具、平台和環境
軟體系統的新發展
四.硬體知識
計算機組成
機內代碼及運算
主要部件的功能及其相互關系
控制器的實現原理
指令系統
中斷系統
匯流排結構
存儲器系統
各類存儲器的功能、特性和使用
高速緩沖存儲器和多級存儲器
虛擬存儲器
輸入/輸出設備及其控制
數據通訊和計算機網路選型和組網知識
安全性、可靠性與系統性能評價初步
數據安全與保密
診斷與容錯
模型與分析
系統可靠性評價和系統性能評價方法
計算機體系結構的其它基礎知識
流水線操作
並行處理
多處理機系統
精簡指令系統計算機
多媒體開發平台及其應用
五.其它基礎知識
專業英語
具有大學畢業程度的詞彙量
能正確閱讀和理解計算機領域的科技文獻
數學
微積分
線性代數：行列式、矩陣和線性方程組
概率統計：事件和概率、隨機變數和分布函數、數字特徵、參數估計和假設檢驗
離散數學：數理邏輯、集合論、圖論、組合分析
數值計算：計算誤差，數值微分與積分，函數插值和逼近，方程的數值解
演算法復雜性
『叄』 醫院信息系統中資料庫的設計有哪些原則與注意事項
1、准備項目計劃書。項目計劃書是醫院信息系統實施過程中第一個最重要的文件。它勾畫了醫院要建設的醫院信息系統總輪廓。通常是委託一家咨詢公司完成一份項目計劃書的標書，該標書的內容為醫院准備建設醫院信息系統的動機和全面、具體、細致的需求。
然後將標書發給參加競標的廠商，在收到各廠商的計劃書後，進行認真的評價，決定最終執行方案。
2、選擇軟硬體的集成商、供應商和合作夥伴，通常委託有資質的咨詢公司或特別的專家小組進行方案評估。
3、需求分析。首先通過對目標醫院使用者的訪問、調查，詳細了解用戶的流程與需求，最後形成文檔：《項目結構》文檔、《目標范圍說明書》文檔、《用戶需求說明書》文檔、初步的《用戶界面說明書》文檔、《測試戰略》文檔、《測試規范與通過標准》文檔。
4、系統設計與軟體客戶化。設計階段要做的工作：把用戶的需求變成技術上可實現的步驟；完善用戶界面演示程序，讓用戶完全接受系統的界面形式；制訂《客戶溝通計劃》，收集和控制用戶需求；完成《功能規格說明書》的簽署並凍結。
初步完成《測試規格》文檔；風險評估。要完成的文檔：《用戶界面說明書》、《概念設計》、《邏輯設計》、《物理設計》、《功能規格說明書》、《測試計劃和時間表》、《測試規格》文檔和大部分的《測試用例》文檔、《項目時間表》。
5、數據准備與裝入。數據准備是指將醫院的基礎數據按照系統的要求統一、規范、格式化的表達出來，並錄人系統基礎資料庫。這些是系統賴以正常運作的基礎。
6、系統測試。在系統測試階段要做的工作：代碼錯誤修改；進行ALPHA測試、BETA測試和RELEASE測試；繼續保持與客戶/用戶的緊密聯系，控制用戶的期望值；編寫聯機幫助和用戶使用手冊；進行用戶培訓和項目驗收；風險評估。
要完成的文檔：《用戶操作手冊》、《實施維護手冊》、《測試報告》、《驗收報告》、《聯機幫助》。階段到達標准後進行審核。
7、用戶培訓。供應商應該有事先安排好的計劃，專門的教師與教材，要准備設備完善的培訓教室和環境。對用戶的培訓可以為對醫院計算機技術人員的培訓和對最終用戶的培訓。
『肆』 葯品的說明書怎樣查詢，
對於個人而言葯品說明書主要是查詢，葯品的使用規則是什麼，對於葯品怎麼使用有個詳細的了解，如果對於研發人員可以在葯品說明書中查詢，工藝技術，或者制劑然後通過文獻查詢分析了解，如果是對於立項人員會在說明書調研適應症、制劑規格等，最好同時對比原研多個國家的說明書主要是對比（中、美、日、歐）的說明書，理清適應症和規格劑型有什麼不同。
可以在資料庫中的上市資料庫系統中查詢調研各個國家的葯品說明書，包含40多個主流國家，如果是想要了解FDA批准葯品的說明書，可以在美國FDA批准葯品資料庫中查詢，可以通過葯品名稱、活性成分、申報企業、申請號、劑型、給葯途徑進行關鍵詞的搜索，還能通過條件篩選選擇想要了解的數據。
在搜索結果中最右邊有說明書的選項，點擊查看，能查詢葯品的說明書，也支持下載葯品說明書文檔。
國內外葯品說明書
一般葯品說明書是葯品的重要來源之一，是醫生、護士士、病人在適用葯物時的科學依據，對於葯物立項、研發人員來說調研查詢葯品說明書是為了了解工藝技術、適應症、制劑、葯理毒理數據等等，為葯物研發提供數據支持，也是在做葯物立項調研中必不可少的一個步驟。
『伍』 資料庫設計說明書有沒有範文
正文
1 引言
1．1編寫目的
說明編寫這份資料庫設計說明書的目的，指出預期的讀者。
1．2背景
說明：
a．說明待開發的資料庫的名稱和使用此資料庫的軟體系統的名稱；
b．列出該軟體系統開發項目的任務提出者、用戶以及將安裝該軟體和這個資料庫的計算站（中心）。
1．3定義
列出本文件中用到的專門術語的定義、外文首字母組詞的原片語。
1．4參考資料
列出有關的參考資料：
a．本項目的經核準的計劃任務書或合同、上級機關批文；
b．屬於本項目的其他已發表的文件；
c．本文件中各處引用到的文件資料，包括所要用到的軟體開發標准。
列出這些文件的標題、文件編號、發表日期和出版單位，說明能夠取得這些文件的來源。
2 外部設計
2．1標識符和狀態
聯系用途，詳細說明用於唯一地標識該資料庫的代碼、名稱或標識符，附加的描述性信息亦要給出。如果該資料庫屬於尚在實驗中、尚在測試中或是暫時使用的，則要說明這一特點及其有效時間范圍。
2．2使用它的程序
列出將要使用或訪問此資料庫的所有應用程序，對於這些應用程序的每一個，給出它的名稱和版本號。
2．3約定
陳述一個程序員或一個系統分析員為了能使用此資料庫而需要了解的建立標號、標識的約定，例如 用於標識資料庫的不同版本的約定和用於標識庫內各個文卷、、記錄、數據項的命名約定等。
2．4專門指導
向准備從事此資料庫的生成、從事此資料庫的測試、維護人員提供專門的指導，例如將被送入數據 庫的數據的格式和標准、送入資料庫的操作規程和步驟，用於產生、修改、更新或使用這些數據文卷的操 作指導。 如果這些指導的內容篇幅很長，列出可參閱的文件資料的名稱和章條。
2．5支持軟體
簡單介紹同此資料庫直接有關的支持軟體，如資料庫管理系統、存儲定位程序和用於裝入、生成、修 改、更新資料庫的程序等。說明這些軟體的名稱、版本號和主要功能特性，如所用數據模型的類型、允許 的數據容量等。列出這些支持軟體的技術文件的標題、編號及來源。
3 結構設計
3．1概念結構設計
說明本資料庫將反映的現實世界中的實體、屬性和它們之間的關系等的原始數據形式，包括各數據項、記錄、系、文卷的標識符、定義、類型、度量單位和值域，建立本資料庫的每一幅用戶視圖。
3．2邏輯結構設計
說明把上述原始數據進行分解、合並後重新組織起來的資料庫全局邏輯結構，包括所確定的關鍵字和屬性、重新確定的記錄結構和文卷結構、所建立的各個文卷之間的相互關系，形成本資料庫的資料庫管理員視圖。
3．3物理結構設計
建立系統程序員視圖，包括：
a．數據在內存中的安排，包括對索引區、緩沖區的設計；
b．所使用的外存設備及外存空間的組織，包括索引區、數據塊的組織與劃分；
c．訪問數據的方式方法。
4 運用設計
4．1數據字典設計
對資料庫設計中涉及到的各種項目，如數據項、記錄、系、文卷、模式、子模式等一般要建立起數據字典，以說明它們的標識符、同義名及有關信息。在本節中要說明對此數據字典設計的基本考慮。
4．2安全保密設計
說明在資料庫的設計中，將如何通過區分不同的訪問者、不同的訪問類型和不同的數據對象，進行分別對待而獲得的資料庫安全保密的設計考慮。
『陸』 在軟體開發中，需求規格說明書和系統設計說明書有什麼區別
1、內容有區別
需求規格說明書主要是描述軟體系統應該完成的功能，包含硬體、功能、性能、輸入輸出、介面需求、警示信息、保密安全、數據與資料庫、文檔和法規的要求等等。
設計說明書是說明如何實現這些功能、性能的。設計書中會對功能進行重新的分解，並需要描述這些功能如何實現，甚至包括如何用代碼實現。
2、目的不同
需求規格說明書的作用在於便於用戶、開發人員進行理解和交流，反映出用戶問題的結構，可以作為軟體開發工作的基礎和依據，並作為確認測試和驗收的依據。
系統設計說明書編制的目的是說明對程序系統的設計考慮，包括程序系統的基本處理流程、程序系統的組織結構、模塊劃分、功能分配、介面設計、運行設計、安全設計、數據結構設計和出錯處理設計等，為程序的詳細設計提供基礎。
3、閱讀對象不同
需求規格說明書主要從用戶角度（需求或市場人員根據用戶要求編寫）描述軟體需要實現的功能。
系統設計說明書主要從軟體開發（程序員）角度描述軟體需要實現功能。
『柒』 資料庫設計說明書，由誰編寫，寫給誰看
開發團隊
如果你們對於資料庫和應用程序的開發有分工的話,那麼所有關於資料庫方面的都有資料庫那邊的人寫,如果沒有分工,就你們自己寫
存檔的目的一個是便於團隊之間的溝通,再一個就是方便事後對程序或者資料庫進行修正\升級等, 會有一定記錄來告訴你資料庫中各個表\欄位等都是什麼含義,以及他們之間的關系, 尤其對一些年久失修的應用程序來說,就不用全部看代碼了
『捌』 資料庫應用系統設計的四個層次分別包含的內容是什麼它們屬於哪個設計階段求詳細解答，跪謝～～
表示層
負責直接跟用戶進行交互，一般也就是指系統的界面，用於數據錄入，數據顯示等。意味著只做與外觀顯示相關的工作，不屬於他的工作不用做。
（概念設計）
業務邏輯層
用於做一些有效性驗證的工作，以更好地保證程序運行的健壯性。不允許指定的文本框中輸入空字元串，數據格式是否正確及數據類型驗證；用戶的許可權的合法性判斷等等
（邏輯設計）
數據訪問層
就是用於專門跟資料庫進行交互。執行數據的添加、刪除、修改和顯示等。所有的數據對象只在這一層被引用。
（邏輯設計）
數據持久層
數據的組織存儲等方面的設計
（物理設計階段）
來自川理-jax-朱哥哥的回答。
『玖』 請問:在用計算機語言編寫電影院訂售票軟體的時候主要涉及到那幾個模塊
我是做基於J2EE項目開發的。可以給你幾點建議：
需求分析-->需詳細需求-->概要設計-->詳細設計-->編碼-->測試--->迭代，詳細如下：
中小型軟體項目開發一般流程建議
一：編寫目的
本文檔的編寫旨在探尋規范的軟體開發流程、加快軟體開發速度、提高軟體開發質量、降低項目綜合成本 。
IT界有一句格言："You can do it right; you can do it fast; you can do it cheap. Pick two." 而我們要做的就是：提供優質服務、項目周期短、成本低廉
二：總體說明
項目從用戶需求說明書的提出，到系統的第一個完整版本的交付使用經歷了若干或復雜或簡單的過程，但不管項目大小如何一般需要經歷以下幾個步驟：
1． 需求分析。
2． 撰寫需求規格說明書
3． 總體設計
4． 詳細設計
5． 編碼實現
6． 測試、試運行、上線
7． 驗收
8． 日常維護
9． （下一個版本的循環開發）
在以上各步驟中尤其重要的是系統分析和撰寫需求規格說明書。當定義好《需求規格說明書》後需要用戶簽字確認，以此作為項目驗收的依據，在中大型項目中尤其重要。
失敗的項目原因很多但以下幾點比較普遍：
（1）商務運作中為了拉住「單子」對客戶的眾多紛繁復雜的要求一味的妥協讓步滿口答應。項目開發計劃、時間表等完全依照客 戶意見，不以具體項目的客觀事實為依據，不做認真細致嚴格的項目復雜度、項目工作量的評估。
（2） 不做細致的用戶需求分析導致項目後期的需求變更較大不能按期完成項目。
三：項目開發經歷的各階段
在項目開發的各階段時間比例方面，中小項目一般控制在
1： 40% 設計
2： 40% 編碼
3： 20% 總體設計/試運行
3．1 需求分析階段
研究客戶需求，從中找出需求中模糊不清的地方，反復討論確認。在不斷的確認中，包括需求的總體認知、需求邊界定義、目前技術條件下的可實現需求、用 戶界面等。通過項目組內討論、與客戶（直接客戶、間接客戶）討論等方式不斷清晰客戶真正的需求，從而撰寫〈〈需求規格說明書〉〉，在取的客戶認可後簽字，以此做為項目開發 的第一個里程碑。在項目驗收時以此作為驗收的主要依據
在系統分析階段與客戶的溝通方式可以通過（1）項目靜態圖、項目靜態界面DEMO（2） 系統用例圖（例如：rose軟體的用例圖） 等方式與客戶溝通。
本階段要完成的工作有：
1．撰寫項目需求分析報告
本報告主要目的是項目分析人員提出需求的疑難不清問題，為與客戶有效、准確溝通准備必要的材料。
2．畫用例圖
描述系統各個不同用戶類型與本系統及其他系統等的交互過程。
3．建立項目靜態界面DEMO
使得用戶在項目初期就可以看到項目上線實施後的使用界面和使用方法等
4． 做必要的技術預研等。
3．2撰寫需求規格說明書
需求規格說明書的撰寫主要目的是把客戶天馬行空、紛繁復雜、憑想像等的理想需求中變成在一定時間段、一定技術條件下可實現的需求。不然項目會很難滿足客戶的理想需求，永 遠被客戶的理想需求所限制，陷入一種非常被動的狀態。
3．3總體設計
在完成項目需求規格說明書後，就進入項目總體設計的階段。
在總體設計階段需要完成的文檔有：
1． 《項目總體設計---概要設計說明書》、
2． 《資料庫設計報告》
3． 《項目總體開發時間表》
在此階段應該建立項目的正式開發環境、項目測試環境、建立項目基本開發框架且導入項目管理配置工具中（例如：CVS、VSS等）等
在項目的以上階段完成後，建議進行項目總體設計和總體開發准備情況的評審工作。在公司、集團專家組評審通過後本階段結束，這算做項目的第二個里程碑。
在進行下一 階段前，目前項目組可以對SCCB（軟體變更控制委員會）提交的資料有：
1：《需求規格說明書》
2：《項目總體設計概要說明書》
3：《項目界面設 計說明書》（及界面DEMO）
4：《項目資料庫設計說明書》等
5：《項目總體開發時間表》
3．4詳細設計
在項目完成總體設計和搭建完畢開發環境後，就可以進行項目的詳細設計。
在項目中建議詳細設計由項目編寫「後台」程序的資深人員編寫。主要完成每個負責的業務模塊 從界面到業務實現到資料庫連接操作的主要步驟和資料庫的實現SQL。最好在條件允許的情況下編寫模塊單元測試程序，在整個模塊編碼階段完成後進行程序單元測試工作。（「測 試驅動」的開發理念）
詳細設計目的是在不編寫代碼和少量代碼的情況下，完成項目模塊的模擬編程實現。
在詳細設計階段可以對項目某模塊做准確的工作量統計，依此為依據整個項目比較准確的工作量就可以被統計出來。
3．5編碼實現
（略）
3．6測試、試運行、上線
（略）
『拾』 基於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] 網路資源