第一篇：車輛管理需求分析
公車管理系統(tǒng)需求分析
1、背景
今年要進行公車管理，以后全市公務人員派車需要進行申請和審核，為提升整個公車的管理水平、公車流轉速率、時效性，需要建設一個統(tǒng)一的信息化平臺來對所有公車進行管理。
2、項目對象和內容
130輛公務用車，全部安裝GPS，后臺建設一個綜合管理平臺，能夠調度車輛、管理車輛、實時監(jiān)控車輛，同時管理駕駛員績效和出勤以及油卡。
3、業(yè)務流程及功能需求（1）用車業(yè)務：
用車人發(fā)起用車申請（直接電話給調度中心）?調度中心錄入用車人信息（姓名、單位、電話、用車事宜、用車時間、到達地點、接人地點等）?查調空車和對應司機，并配備油卡（也可能不配備油卡）?系統(tǒng)生成派車任務（短信通知申請人，車牌，司機號碼，將于什么時候到哪接人，同時告知他用車完畢后可以回復短信對本次用車打分）?人工通知司機接人?調度員全程可實時監(jiān)督車輛運行情況（有熱鍵可查看該次行車中的實時信息）?申請人回復滿意度，系統(tǒng)記錄納入司機績效考核（不回復則默認滿意）?司機回單位還車?調度員系統(tǒng)結束任務，回收油卡，填寫加油金額。（2）司機管理：
司機管理模塊，記錄司機的信息（姓名、年齡、電話、駕駛證號、工號等），司機的相關信息可以修改、刪除、新增。
每天調度人員對上班司機進行排班管理（也可以通過導入排班表格的形式設置一周/一個月的初始排班），同時該信息在用車業(yè)務派單時可以顯示該司機的狀態(tài)（在班空閑、在班出車、不在班、請假、休假），派車時優(yōu)先選擇在班人員，但不在班、請假、休假也可以派任務，在班出車狀態(tài)不可再被派發(fā)任務。
在用車業(yè)務功能中生成了用車任務后，司機日常管理中自動生成相關記錄（什么時間出了什么任務，對應車輛是什么），在用車任務結束后自動插入信息（什么時候結束任務的，耗時多少，評價是什么），有熱鍵可查看該次行車中的實時信息。
司機調班或請假，在系統(tǒng)中生成記錄（什么時候，因為什么請假，請假時長，代班人員是誰），同時初始排班表自動更改，派車任務時司機顯示狀態(tài)也發(fā)生改變。休假的也一樣（只是原因就變成了休假）。該請假的方式考慮兩種情況，一種是司機手機上裝個APP實現請假填報，調度員審核通過系統(tǒng)自動改（這里要包含請假和休假兩個流程），一種是司機給調度員人工聯系，調度員自己進系統(tǒng)改，先考慮后一種模式，但第一種的接口也要預留。最終可以可以導出績效管理表格。（3）車輛管理
車輛有基礎數據庫，一車一檔（牌照、行駛證、品牌、車型、空間大小、購車年限、保養(yǎng)信息、年審、保險），可以新增、修改、刪除；
當用車業(yè)務發(fā)起派車后，該車輛自動生成出車記錄（什么時間出了什么任務，對應駕駛員是誰），該車狀態(tài)改為出車（狀態(tài)為空車、出車、檢修、維修四），只有在空車期間才能被指派任務，任務結束后自動生成記錄（什么時候結束任務的，耗時多少）該車狀態(tài)改為（空車），有熱鍵可查看該次行車中的實時信息。
車輛維護和檢修，會指定維護廠，給維護長輸入的APP終端軟件，修理廠先選擇車輛是日常檢修還是事故維修，然后可以直接將車輛的問題、進修理廠時間、送達人員姓名、電話、維修現已經維修到哪一步、什么時候可以出廠、出廠接車人姓名、電話、出廠接車時間、維修金額進行實時更新，調度員可以實時了解車輛的狀態(tài)，在檢修和維修階段，車輛狀態(tài)自動為檢修和維修，不可被派發(fā)任務。
車輛管理中有每輛車有對應的加油記錄查詢熱鍵，可以看到該車所有的加油明細，該部分數據來源于加油管理。（4）加油管理：
本次業(yè)主的加油全部為中石化的加油卡，業(yè)務流程是卡給出車的駕駛員，每次駕駛員用卡加油，然后回來上交。因此，首先要有油卡基礎信息庫（油卡卡號、充值金額、當前余額），可以修改、新增、刪除，當出車配備油卡時，油卡狀態(tài)改為出庫（油卡有出庫、在庫兩種狀態(tài)），出庫油卡不能再配發(fā)，油卡出庫后自動關聯任務生成記錄（對應時間、駕駛員、車輛、任務），加油入庫后，調度員后臺輸入加油金額，加油地點【可以不填】，自動生成余額。
加油卡也可以不通過出車業(yè)務分配，調度員可以直接將油卡分給司機，填入出庫記錄（什么時間出庫、給誰了、電話號碼、分派人是誰），入庫時候填寫入庫記錄（什么時間入庫、誰接收的、用了多少錢、加油地點【可以不填】），自動生成余額。
充值后調度員后臺平臺找到對應卡，輸入充值金額，自動生成余額?？梢詫С霰砀?，包括油卡的交易明細表。
在該部分后期將會和中石化對接，加油的信息將會自動傳輸到后臺，即出卡流程一樣，但加油的時候如果是在加的油，中石化會將金額和卡號直接傳送過來，本系統(tǒng)自動記錄并處理，外加的油，還是按照上述流程處理。該功能為本項目的一部分，只是在中石化沒做好之前，可以本功能不使用，什么時候中石化做好，什么時候對接。（5）調度員
調度員每個人有自己的賬號，賬號關聯調度員姓名、手機、密碼等，可以新增、刪除調度員，可以修改密碼，可以查詢自己的調度記錄。以上派車、油卡、維護等功能每個任務的生成、結束、接受，系統(tǒng)都自動記錄操作的調度員信息，以備后查。
4、其他需求
前端加裝GPS定位設備，要高大上一點，業(yè)主明確不能給電動車的那個裝備，設備要隱蔽安裝，安裝由提供廠家負責；
后臺有實時監(jiān)控地圖界面，中心先采用電腦加一臺液晶電視的方式顯示，大屏暫不考慮；
5、文檔要求
文檔組成一定要有如下因素：
背景（為什么干這個事情，要干成什么樣子）； 總體設計（一定要有軟件總體架構圖和網絡架構圖）；
功能設計（要清楚的列出每個功能點和模塊，并做相應說明，硬件參數也最好說明）； 報價（報價一定按照功能點做一個報價表，詳細到每個功能模塊多少錢，再就是網絡運營費用及硬件費用）.
第二篇：合同管理-需求分析文檔（模版）
合同管理需求分析 需求描述：
合同與招標管理主要實現對合同項目的立項審批、招標、合同以及竣工驗收的全過程管理。該系統(tǒng)主要由合同項目管理、招標管理、合同管理、客戶管理和灰名單管理等幾個模塊組成。
流程圖：
合同管理流程圖合同管理外包工程合同項目申請招標否自動創(chuàng)建項目合同項目審批招標書擬定標書簽收登記評標報告申請評標報告審批合同申請招標記錄填報談判紀要錄入資質與安全協(xié)議審查合同擬定付款申請合同記錄人員管理合同終止現場管理合同變更竣工/質保驗收申請竣工/質保驗收審批結束 3 項目管理
3.1 項目申請：
合同項目管理是指所有需要簽訂合同的項目都要在此進行申請。由各個部門的專工或主任提出申請。
合同項目申請又分為未運行、進行中和已完工。后兩者是屬于后補項目，后補項目必須增加先履行原因。
合同項目的屬性包括：項目編號、申請日期、后補類型（生產搶修、超過50萬已書面報分公司同意、后補或不招標超過10萬已書面報總經理同意）、項目狀況（未進行、進行中、已竣工）、申請方式（招標、不招標）、項目名稱、項目性質（新簽、續(xù)簽、變更、終止、補充）、資金來源、項目預算、費用管理部門、項目類型（技術服務、土建、維修、軟件等）計劃開工時間、計劃竣工時間、申請理由、申請人、申請部門、申請部門主管、不招標理由（有多條理由顯示，直接讓用戶勾選）、項目內容、工程量及物料人力資源情況。
合同項目申請時需要填寫承包商推薦會簽表，需要招標的項目至少選擇5家，不需要招標的項目至少選擇3家；如果選擇的承包商單位不足則需要在【備注】中填寫理由。合同申請的界面原型如下：
3.2 項目審批：
項目申請?zhí)峤缓?，由各級進行審批，其中系統(tǒng)約定72小時，如果超過72小時，則系統(tǒng)自動推進，無需他在簽字審批。但是要在系統(tǒng)中列明原因：“該記錄已超過72小時，系統(tǒng)自動推進！”。如果是部門專工提出申請，則還需要部門主任審批，審批后由項目主管部門審批報公司分管領導審批，對于超過多少金額的還需要報總經理審批。對不同類型的項目，主管部門可能不一樣，例如生產項目的主管部門是設備部，非生產項目的主管部門是經營計劃部。項目審批的界面原型如下：
項目驗收
項目驗收分為: 竣工驗收單、質保驗收單和階段驗收單。
驗收單包括：驗收日期、驗收單類別（竣工、質保、階段）、項目名稱、資金來源、項目預算、履行地點、開工日期、竣工日期、質保金截至日期、甲方名稱、乙方名稱、項目摘要內容、評價等級、合格/不合格、客戶評價（符合合同要求、不符合合同要求、達到預期目標、未達到預期目標、可以投入使用、不可以投入使用、質保期質量無問題、質保期有問題）、填寫人、填寫時間、填寫部門、附件。
? 竣工驗收單申請：
由項目負責部門提出竣工驗收申請。
? 竣工驗收單審批：
竣工單申請后，經過各級審核通過后，就將該系統(tǒng)置為已竣工。當超過72小時候沒有審批就自動推進。
? 質保驗收單申請：
由項目負責部門提出竣工驗收申請。
? 質保驗收單審批：
質保單申請后，經過各級審核通過后，就將該系統(tǒng)置為已竣工。當超過72小時候沒有審批就自動推進。
? 階段驗收單登記：
由項目負責部門登記所有階段驗收的記錄。
如果項目是來自于外包工程，所有的驗收記錄和質保記錄同步保存到外包工程的記錄中。項目驗收的界面原型如下：
招標管理
對于需要招標的項目，應該進行招標。招標管理主要是做好三個方面的工作：分別是招標擬定，標書簽收登記以及項目評標報告。這三個節(jié)點只有在評標報告審批時必須要做的。
4.1 標書簽收登記：
標書簽收登記就是登記簽收標書的投標方單位。由項目負責單位登記所有投標方單位，并記錄投標單位名稱，投標時間，投標金額，聯系人及聯系電話。界面原型如下：
4.2 招標書擬定：
招標書擬定就是下載招標書模板后，根據模板要求填寫各項數據上傳到系統(tǒng)中。
4.3 工程評估報告申請：
由項目負責部門提出工程評估報告申請。
工程評標報告屬性：項目名稱、資金來源、項目預算、參與投標單位（序號、公司名稱、投標報價、資質）、評標意見、綜合排序（將投標單位排序）、擬中標單位、中標金額、參與人員、備注、申請人、申請時間、申請部門、各種附件。工程評估報告申請的界面原型如下：
4.4 工程評估報告審批
項目評估報告提出申請要經過審批，經過審批后才發(fā)布。由各級領導進行審批，各個上傳的附件應直接在屏幕上顯示出來。對于超過72小時未審批的要自動推進。
工程評估報告審批的界面原型如下：
合同管理
合同管理包括：合同申請審批、合同擬定、合同談判紀要、其他付款、付款申請審批、合同變更、合同終止等管理。
5.1 合同申請：
合同申請審批是由合同起草人或項目負責部門提出申請。合同申請的屬性有：合同名稱，合同編號，合同性質，合同類型，資金來源，合同金額，項目預算，所屬項目，簽約單位（我方）（承包部門，部門負責人，承辦人），簽約單位（對方）（承辦人，承辦人聯系電話）,簽約時間，簽約地點，備注，附件，申請部門，申請人，申請時間。
合同申請的界面原型如下：
5.2 合同審核：
合同申請由項目負責部門提出后，經過部門主任審批、主管部門領導審批、公司領導審批后通過（具體流程可以靈活設置）后生效。合同審核的界面原型如下：
合同擬定
通過下載【合同模板】后，填寫合同內容上傳擬定好的合同文本到系統(tǒng)中。合同擬定的界面原型如下：
5.4 合同談判紀要
合同的談判紀要是在系統(tǒng)中錄入合同談判的紀要內容。合同談判紀要的界面原型如下：
5.5 付款申請
由項目提出部門提出付款通知單，并經過相關部門和公司領導審批。一個項目可以多次付款。超過總金額后就不能再付款了。系統(tǒng)應該要有剩余質保金的到期提示。付款申請的界面原型如下：
5.6 付款審核
合同付款審核的界面原型如下：
5.7 其他付款
其他付款是申請付款通知單的一種，是多那些沒有按正規(guī)流程辦理的項目的付款。其他付款的界面原型如下：
5.8 合同變更
由項目負責人根據合同的實際情況可以對合同進行變更，需要填寫變更原因，記錄好變更的時間。合同變更的界面原型如下：
合同終止申請
當合同有效時間到達時，合同自動終止，或者因為其他原因可以由項目負責部門提前終止合同。合同終止申請的界面原型如下：
5.10 合同終止審核
項目負責部門提出合同終止申請后，需要通過各級部門審核通過后才能終止合同。合同終止的審核的流程需要通過工作流來進行配置。
合同終止審核的界面原型如下：
客戶管理
合同管理中的承包單位統(tǒng)一在【承包商】模塊中進行管理，創(chuàng)建合同項目時自動將對應的承包商信息保存到【承包商】模塊中。
第三篇：車輛管理系統(tǒng)需求規(guī)格說明書
車輛管理系統(tǒng)
軟件需求規(guī)格說明書
班 級 08軟工A1 擬制人 舒驥
2011年05月10日
目錄
1引言.............................................................................................................................1
1.1編寫目的.........................................................................................................1 1.2 背景................................................................................................................1 1.3 預期讀者........................................................................................................1 1.4參考資料.........................................................................................................1 2綜合描述.....................................................................................................................2
2.1產品目標.........................................................................................................2 2.2產品功能.........................................................................................................2 2.3用戶范疇和特征.............................................................................................2 2.4運行環(huán)境.........................................................................................................3 2.5設計和實現限制.............................................................................................3 2.6 假定和約束....................................................................................................3
2.6.1人力資源約束.....................................................................................3 2.6.2技術約束.............................................................................................3 2.6.3環(huán)境約束.............................................................................................3
3外部接口需求.............................................................................................................4
3.1用戶界面.........................................................................................................4 3.2硬件接口.........................................................................................................4 3.3軟件接口.........................................................................................................4 3.4通信接口.........................................................................................................4 4功能性需求.................................................................................................................4
4.1功能分析.........................................................................................................4 4.2用例圖.............................................................................................................5 4.3用例分析.........................................................................................................9 4.4功能活動圖...................................................................................................19 4.5狀態(tài)圖...........................................................................................................21 5非功能需求...............................................................................................................22
5.1性能需求.......................................................................................................22
5.1.1時間、界面、響應要求...................................................................22 5.1.2靈活性...............................................................................................22 5.2數據管理需求...............................................................................................22
5.2.1系統(tǒng)數據流圖...................................................................................22 5.2.2數據整理與保存...............................................................................24 5.2.3數據安全性.......................................................................................24 5.3故障處理需求...............................................................................................24
1引言
1.1編寫目的
需求說明的編寫是為了研究車輛管理軟件的開發(fā)途徑和應用方法。同時它也是進行項目策劃、概要設計和詳細設計的基礎，是維護人員進行內部維護，信息更新，驗收和測試的依據。本文檔將對車輛管理系統(tǒng)軟件開發(fā)需求進行描述。
1.2 背景
物流系統(tǒng)是現代經濟系統(tǒng)的主動脈，物流的最簡單理解就是貨物運輸，所以運輸在物流運作中的地位十分重要，而車輛是運輸企業(yè)的命脈，有機的管理好車輛十分關鍵。傳統(tǒng)的運輸業(yè)已不能滿足市場需求。運輸企業(yè)的信息化管理具有重要意義。
開發(fā)軟件名稱：車輛管理系統(tǒng) 項目開發(fā)者：08軟工A1 舒驥 用戶：運輸集團公司
1.3 預期讀者
本需求的預期讀者是開發(fā)組成人員，軟件測試人員，支持本項目的老師，軟件維護人員。
1.4參考資料
[1].《軟件需求工程》 毋國慶 梁正平袁夢霆 李勇華 編著[2].《UML基礎與Rose建模教程》 蔡敏 徐惠惠 黃炳強 編著
[3].《C#數據庫系統(tǒng)開發(fā)完全手冊》 明日科技 張躍延 許文武 王小科 編著
[4].《軟件工程實驗與實踐教程》 陳佳 曹妍 編著 [5].《實用軟件文檔寫作》 肖剛 古輝 程振波 張元鳴 著 2綜合描述
2.1產品目標
車輛管理系統(tǒng)將為企業(yè)提供各種車輛管理和快速查詢的功能，以提高公司的運作效率，降低運作成本。
2.2產品功能
* 車輛基本信息管理 * 車輛購置管理 * 車輛調撥管理 * 車輛報廢管理 * 車輛信息管理查詢
2.3用戶范疇和特征
本軟件最終用戶為汽車運輸集團公司。該公司主要設有技術服務部、客貨運輸部、企業(yè)管理部等職能部門，下屬運輸公司有零擔運輸公司、客運公司、整車運輸公司、旅游公司等，其組織結構如下圖1：
圖1：運輸集團公司組織結構圖
2.4運行環(huán)境
運行該軟件所適用的具體設備必須是奔騰
4、內存512MB以上的計算機。操作系統(tǒng)在Windows xp及以上。
數據庫為SQL Server2000版本
2.5設計和實現限制
僅設計為本地版本，無需聯網，沒有服務器端。
2.6 假定和約束
2.6.1人力資源約束
1、開發(fā)工作量約需1個人2月工作量。開發(fā)完成后，可減少為1名作為維護人員；
2、輔導老師1人，開發(fā)人員2人。
2.6.2技術約束
本項目的設計是在ASPAsp.Net程序設計語言的條件下進行的，技術設計采用軟硬一體化的設計方法。
2.6.3環(huán)境約束
運行該軟件所適用的具體設備必須是奔騰
4、內存512MB以上的計算機。操作系統(tǒng)在Windows xp及以上。
3外部接口需求
3.1用戶界面
見《系統(tǒng)設計說明書》
3.2硬件接口
考慮到大量數據的備份等要求，需要保持與磁帶機、光盤刻錄機及USB的接口，這較易實現。
3.3軟件接口
這里，主要考慮軟件與操作系統(tǒng)、數據庫管理系統(tǒng)的接口。由于不存在從其他文件導入的功能，所以無需擔心格式轉換的問題。該軟件更趨向于單一封閉的單機版軟件。
3.4通信接口
無需與網絡連接，只需考慮與外部移動設備的通信。
4功能性需求
4.1功能分析
1、車輛基本信息管理模塊
(1)用戶的登錄管理：不同級別的用戶通過特定的用戶名和密碼登錄系統(tǒng)，對相應的信息進行管理。
(2)查詢車輛基本信息：通過輸入車輛的基本信息對車輛的整體信息進行查詢。(3)刪除車輛基本信息：有相關權限的用戶可對某些不再需要的車輛信息進行刪除。
(4)修改車輛基本信息：有相關權限的用戶如有必要，可對車輛的基本信息進 行修改。
(5)添加車輛基本信息：有相關權限的用戶可添加車輛的基本信息。
2、車輛購置管理模塊
用戶可添加、修改、刪除、查詢車輛購置管理申請單，然后交由總工程師申請審批，如通過再有總經理申請審批，實現二級公司要提交車輛的購置申請，集團公司職能部門根據車輛的產權歸屬，由總工程師或總工程師及總經理對申請進行審批，生效后產生調撥單下發(fā)所屬公司及各有關部門。
3、車輛調撥管理模塊
與車輛購置管理類似，用戶可添加、修改、刪除、查詢車輛調撥管理申請單，然后交由總工程師申請審批，如通過再有總經理申請審批，實現二級公司要提交車輛的購置申請，集團公司職能部門根據車輛的產權歸屬，由總工程師或總工程師及總經理對申請進行審批，生效后產生調撥單下發(fā)所屬公司及各有關部門。
4、車輛報廢管理模塊
與車輛購置管理類似，用戶可添加、修改、刪除、查詢車輛報廢管理申請單，然后交由總工程師申請審批，如通過再有總經理申請審批，實現二級公司要提交車輛的購置申請，集團公司職能部門根據車輛的產權歸屬，由總工程師或總工程師及總經理對申請進行審批，生效后產生調撥單下發(fā)所屬公司及各有關部門。
5、車輛信息查詢管理模塊
實現對多種信息的快速模糊查詢，可根據車輛所屬的二級公司，車牌號，車輛的廠牌，規(guī)格，型號等信息進行不同的組合來查詢車輛，還可根據申請購置，調撥，報廢車輛的二級公司，申請時間等查詢車輛的購置，調撥，報廢的申請及審批情況等。
4.2用例圖
1、車輛管理信息系統(tǒng)用例圖
2、車輛購置管理用例圖
3、車輛調撥管理用例圖
4、車輛報廢管理用例圖
5、車輛基本信息管理用例圖
4.3用例分析
一、車輛購置管理
用例1 用例名稱：添加車輛購置申請 用例識別號：1.1.1 參與者：二級公司用戶
簡要說明：二級公司用戶添加一個車輛購置申請單。前置條件：二級公司用戶已經登錄車輛管理信息系統(tǒng)?；臼录鳎?/p>
1)二級公司用戶單擊“插入”按鈕。2)系統(tǒng)出現編輯窗口。
3)二級公司用戶可以在相應的文本框上添加或修改申請單，也可以完全刪除，重新填寫。
4)二級公司用戶編輯完相應的文本框，單擊“存盤”按鈕，一條新的車輛購置申請記錄就被插入到數據庫中。5)用例終止 其它事件流：
在單擊“存盤”按鈕之前，二級公司用戶隨時可以單擊“取消”按鈕，窗口內的任何內容都不會被保存。異常事件流：
1）提示錯誤信息，二級公司用戶確認。2）返回到管理系統(tǒng)主界面。
后置條件：一條新的車輛購置記錄被插入到數據庫中并顯示出來。注釋：無。
其它事件流：
在單擊“是”按鈕之前，二級公司用戶可以單擊“否”按鈕，車輛購置申請記錄不會被刪除。
異常件流：
1）提示錯誤信息，二級公司用戶確認。2）返回到管理系統(tǒng)主界面。
后置條件：選中的默認的車輛購置申請記錄從數據庫中被刪除，同時顯示界面被更新。
注釋：刪除之前，要先使用查詢功能，以便選擇要刪除的內容。
用例3 用例名稱：總工程師購置申請審批 用例識別號：1.2.1 參與者：總工程師
簡要說明：總工程師對二級公司用戶提交的車輛購置申請單進行審批。前置條件：總工程師已經登錄車輛管理信息系統(tǒng)、存在未審批的車輛購置申請。
基本事件流：
1)總工程師單擊選中要審批的車輛購置申請記錄。2)總工程師單擊“審批”按鈕。3)系統(tǒng)出現編輯窗口。
4)總工程師可以在審批意見文本框上添加或修改審批意見，也可以完全刪除，重新填寫。
5)總工程師選擇“同意”或“不同意”單選按鈕審批結果。
6)總工程師編輯完相應的文本框及選擇完審批結果后，單擊“存盤”按鈕，該車輛購置申請記錄就被審批，并在數據庫中修改該記錄的審批標志，審批結果和審批意見。7)用例終止。其它事件流：
在單擊“存盤”按鈕之前，總工程師隨時可以單擊“取消”按鈕，審批內容及審批結果都不會被保存。異常事件流：
1）提示錯誤信息，總工程師確認。2）返回到管理系統(tǒng)主界面。
后置條件：選中的車輛購置申請記錄被審批，并在數據庫中修改該記錄的審批標志、審批結果和審批意見。
注釋：審批之前，要先使用查詢功能，查出未審批的車輛購置申請記錄。
用例4 用例名稱：總經理購置申請批復 用例識別號：1.3.1 參與者：總經理
簡要說明：總經理對二級公司用戶提交的公司所屬車輛購置申請進行批復。前置條件：總經理已經登錄車輛管理信息系統(tǒng)、存在滿足如下條件的車輛購置申請記錄，即：總工程師已審批、總經理未批復的公司所屬車輛購置申請記錄?；臼录鳎?/p>
1)總經理單擊選中要審批的車輛購置申請記錄。
2)總經理編輯完相應的文本框及選擇完批復結果后，單擊“存盤”按鈕，該車輛購置申請記錄就被批復，并在數據庫中修改該記錄的批復標志，批復結果和批復意見。3)用例終止。其它事件流：
在單擊“存盤”按鈕之前，總工程師隨時可以單擊“取消”按鈕，審批內容及審批結果都不會被保存。異常事件流：
1）提示錯誤信息，總經理確認。2）返回到管理系統(tǒng)主界面。
后置條件：選中的車輛購置申請記錄被批復，并在數據庫中修改該記錄的批復標志、批復結果和批復意見。
注釋：審批之前，要先使用查詢功能，查處總工程師已審批，總經理未批復的公司所屬車輛購置申請記錄。
二、車輛調撥管理
用例5 用例名稱：添加車輛調撥申請 用例識別號：2.1.1 參與者：二級公司用戶
簡要說明：二級公司用戶添加一個車輛調撥申請單。前置條件：二級公司用戶已經登錄車輛管理信息系統(tǒng)?；臼录鳎?/p>
1)二級公司用戶單擊“插入”按鈕。2)系統(tǒng)出現編輯窗。
3)二級公司用戶可以在相應的文本框上添加或修改申請單，也可以完全刪除，重新填寫。
4)二級公司用戶編輯完相應的文本框，單擊“存盤”按鈕，一條新的車輛調撥申請記錄就被插入到數據庫中。5)用例終止。其它事件流：
在單擊“存盤”按鈕之前，二級公司用戶隨時可以單擊“取消”按鈕，窗口內的任何內容都不會被保存。異常事件流：
1)提示錯誤信息，二級公司用戶確認。2)返回到管理系統(tǒng)主界面。
后置條件：一條新的車輛調撥記錄被插入到數據庫中并顯示出來。注釋：無。
用例6 用例名稱：刪除車輛調撥申請 用例識別號：2.1.2 參與者：二級公司用戶
簡要說明：二級公司用戶刪除一個車輛調撥申請記錄。
前置條件：二級公司用戶已經登錄車輛管理信息系統(tǒng)、將要被刪除的車輛調撥申請沒有被審批?；臼录鳎?/p>
1)二級公司用戶單擊選中要刪除的車輛調撥申請記錄。2)二級公司用戶單擊“刪除”按鈕。3)系統(tǒng)出現“提示是否刪除”窗口。
4)二級公司用戶單擊“是”按鈕，該車輛調撥申請記錄就被從數據庫中刪除。5)用例終止。其它事件流：
在單擊“是”按鈕之前，二級公司用戶可以單擊“否”按鈕，車輛調撥申請記錄不會被刪除。異常件流：
1）提示錯誤信息，二級公司用戶確認。2）返回到管理系統(tǒng)主界面。
后置條件：選中的默認的車輛調撥申請記錄從數據庫中被刪除，同時顯示界面被更新。
注釋：刪除之前，要先使用查詢功能，以便選擇要刪除的內容。
用例7 用例名稱：總工程師調撥申請審批 用例識別號：2.2.1 參與者：總工程師
簡要說明：總工程師對二級公司用戶提交的車輛調撥申請單進行審批。前置條件：總工程師已經登錄車輛管理信息系統(tǒng)、存在未審批的車輛調撥申請。
基本事件流：
1)總工程師單擊選中要審批的車輛調撥申請記錄。2)總工程師單擊“審批”按鈕。3)系統(tǒng)出現編輯窗口。
4)總工程師可以在審批意見文本框上添加或修改審批意見，也可以完全刪除，重新填寫。
5)總工程師選擇“同意”或“不同意”單選按鈕審批結果。
6)總工程師編輯完相應的文本框及選擇完審批結果后，單擊“存盤”按鈕，該車輛調撥申請記錄就被審批，并在數據庫中修改該記錄的審批標志，審批結果和審批意見。7)用例終止。其它事件流：
在單擊“存盤”按鈕之前，總工程師隨時可以單擊“取消”按鈕，審批內容及審批結果都不會被保存。異常事件流：
1）提示錯誤信息，總工程師確認。2）返回到管理系統(tǒng)主界面。
3）后置條件：選中的車輛調撥申請記錄被審批，并在數據庫中修改該記錄的審批標志、審批結果和審批意見。
注釋：審批之前，要先使用查詢功能，查出未審批的車輛調撥申請記錄。
用例8 用例名稱：總經理調撥申請批復 用例識別號：2.3.1 參與者：總經理
簡要說明：總經理對二級公司用戶提交的公司所屬車輛調撥申請進行批復。前置條件：總經理已經登錄車輛管理信息系統(tǒng)、存在滿足如下條件的車輛調撥申請記錄，即：總工程師已審批、總經理未批復的公司所屬車輛調撥申請記錄。基本事件流：
1)總經理單擊選中要審批的車輛調撥申請記錄。2)總經理單擊“審批”按鈕。3)系統(tǒng)出現編輯窗口。
4)總經理可以在審批意見文本框上添加或修改批復意見，也可以完全刪除，重新填寫。
5)總經理選擇“同意”或“不同意”單選按鈕批復結果。
6)總經理編輯完相應的文本框及選擇完批復結果后，單擊“存盤”按鈕，該車輛調撥申請記錄就被批復，并在數據庫中修改該記錄的批復標志，批復結果和批復意見。7)用例終止。其它事件流：
在單擊“存盤”按鈕之前，總工程師隨時可以單擊“取消”按鈕，審批內容及審批結果都不會被保存。異常事件流：
1）提示錯誤信息，總經理確認 2）返回到管理系統(tǒng)主界面
后置條件：選中的車輛調撥申請記錄被批復，并在數據庫中修改該記錄的批復標志、批復結果和批復意見。
注釋：審批之前，要先使用查詢功能，查處總工程師已審批，總經理未批復的公司所屬車輛調撥申請記錄。
三、車輛報廢管理
用例9 用例名稱：添加車輛報廢申請 用例識別號：3.1.1 參與者：二級公司用戶
簡要說明：二級公司用戶添加一個車輛報廢申請單。前置條件：二級公司用戶已經登錄車輛管理信息系統(tǒng)。基本事件流：
1)二級公司用戶單擊“插入”按鈕。2)系統(tǒng)出現編輯窗口。
3)二級公司用戶可以在相應的文本框上添加或修改申請單，也可以完全刪除，重新填寫。
4)二級公司用戶編輯完相應的文本框，單擊“存盤”按鈕，一條新的車輛報廢申請記錄就被插入到數據庫中。5)用例終止。其它事件流：
在單擊“存盤”按鈕之前，二級公司用戶隨時可以單擊“取消”按鈕，窗口內的任何內容都不會被保存。異常事件流：
1）提示錯誤信息，二級公司用戶確認。2）返回到管理系統(tǒng)主界面。
后置條件：一條新的車輛報廢記錄被插入到數據庫中并顯示出來。注釋：無。
用例10 用例名稱：刪除車輛報廢申請 用例識別號：3.1.2 參與者：二級公司用戶
簡要說明：二級公司用戶刪除一個車輛報廢申請記錄。
前置條件：二級公司用戶已經登錄車輛管理信息系統(tǒng)、將要被刪除的車輛報廢申請沒有被審批。基本事件流：
1)二級公司用戶單擊選中要刪除的車輛報廢申請記錄。2)二級公司用戶單擊“刪除”按鈕。3)系統(tǒng)出現“提示是否刪除”窗口。
4)二級公司用戶單擊“是”按鈕，該車輛報廢申請記錄就被從數據庫中刪除。5)用例終止。
其它事件流：
在單擊“是”按鈕之前，二級公司用戶可以單擊“否”按鈕，車輛報廢申請記錄不會被刪除。異常件流：
1）提示錯誤信息，二級公司用戶確認。2）返回到管理系統(tǒng)主界面。
后置條件：選中的默認的車輛報廢申請記錄從數據庫中被刪除，同時顯示界面被更新。
注釋：刪除之前，要先使用查詢功能，以便選擇要刪除的內容。
用例11 用例名稱：總工程師報廢申請審批 用例識別號：3.2.1 參與者：總工程師
簡要說明：總工程師對二級公司用戶提交的車輛報廢申請單進行審批。前置條件：總工程師已經登錄車輛管理信息系統(tǒng)、存在未審批的車輛報廢申請。
基本事件流：
1）總工程師單擊選中要審批的車輛報廢申請記錄。2）總工程師單擊“審批”按鈕。3）系統(tǒng)出現編輯窗口。
4）總工程師可以在審批意見文本框上添加或修改審批意見，也可以完全刪除，重新填寫。
5）總工程師選擇“同意”或“不同意”單選按鈕審批結果。
6）總工程師編輯完相應的文本框及選擇完審批結果后，單擊“存盤”按鈕，該車輛報廢申請記錄就被審批，并在數據庫中修改該記錄的審批標志，審批結果和審批意見。7）用例終止。其它事件流：
在單擊“存盤”按鈕之前，總工程師隨時可以單擊“取消”按鈕，審批內容及審批結果都不會被保存。異常事件流：
1）提示錯誤信息，總工程師確認。2）返回到管理系統(tǒng)主界面。
3）后置條件：選中的車輛報廢申請記錄被審批，并在數據庫中修改該記錄的審批標志、審批結果和審批意見。
注釋：審批之前，要先使用查詢功能，查出未審批的車輛報廢申請記錄。
用例12 用例名稱：總經理報廢申請批復 用例識別號：3.3.1 參與者：總經理
簡要說明：總經理對二級公司用戶提交的公司所屬車輛報廢申請進行批復。前置條件：總經理已經登錄車輛管理信息系統(tǒng)、存在滿足如下條件的車輛報廢申請記錄，即：總工程師已審批、總經理未批復的公司所屬車輛報廢申請記錄?；臼录鳎?/p>
1)總經理單擊選中要審批的車輛報廢申請記錄。2)總經理單擊“審批”按鈕。3)系統(tǒng)出現編輯窗口。
4)總經理可以在審批意見文本框上添加或修改批復意見，也可以完全刪除，重新填寫。
5)總經理選擇“同意”或“不同意”單選按鈕批復結果。
6)總經理編輯完相應的文本框及選擇完批復結果后，單擊“存盤”按鈕，該車輛報廢申請記錄就被批復，并在數據庫中修改該記錄的批復標志，批復結果和批復意見。7)用例終止。其它事件流：
在單擊“存盤”按鈕之前，總工程師隨時可以單擊“取消”按鈕，審批內容及審批結果都不會被保存。異常事件流：
1）提示錯誤信息，總經理確認。2）返回到管理系統(tǒng)主界面。
后置條件：選中的車輛報廢申請記錄被批復，并在數據庫中修改該記錄的批復標志、批復結果和批復意見。
注釋：審批之前，要先使用查詢功能，查處總工程師已審批，總經理未批復的公司所屬車輛報廢申請記錄。
4.4功能活動圖
1、用戶登錄活動圖
2、車輛基本信息管理活動圖
3、車輛購置管理活動圖 4.5狀態(tài)圖
1、車輛購置申請單狀態(tài)圖
2、車輛基本信息狀態(tài)圖
5非功能需求
5.1性能需求
5.1.1時間、界面、響應要求
由于此系統(tǒng)主要用于信息的保管查詢，即對數據的安全性要求極高。為防止對信息資料和管理程序的惡意破壞，及惡意的竊取私人信息，要求有較為可靠的安全性能。另外也需要高速的響應，要求穩(wěn)定、安全、便捷，易于管理和操作。另外使用者大多為非計算機人員，所以要求界面友善，交互性強。查詢速度：不超過5秒；
其它所有交互功能反應速度：不超過3秒； 可靠性：平均故障間隔時間不低于300小時。信息容量：不低于10G時可能出現系統(tǒng)崩潰。
5.1.2靈活性
當用戶需求，如操作方式，運行環(huán)境，結果精度，數據結構與其他軟件接口等發(fā)生變化時，設計的軟件要做適當調整,靈活性非常大。
5.2數據管理需求
5.2.1系統(tǒng)數據流圖
車輛購置業(yè)務流程圖
車輛調撥業(yè)務流程圖 車輛報廢業(yè)務流程圖
5.2.2數據整理與保存
應滿足隨時整理的需求，用戶可隨時更改數據，保存數據。對于數據唯一性的識別應放在多個關鍵字之上。
5.2.3數據安全性
數據應具有極高的安全性，為了保護用戶的隱私，仍需設置登陸及密碼保護，以防用戶的信息被人竊取。
5.3故障處理需求
1、內部故障處理: 在開發(fā)階段可以隨即修改數據庫里的相應內容。
2、外部故障處理: 24 對編輯的程序進行重裝載時，第一次裝載認為錯，修改。第二次運行，在需求調用時出錯，有錯誤提示，重試。
3、本軟件可能產生的錯誤為數據庫的錯誤信息，應由數據庫管理員對數據庫進行維護。為了確保系統(tǒng)恢復的能力，數據庫管理員要定期對數據庫進行備份。但產品投入使用后，則由維護人員跟進。
第四篇：車輛管理系統(tǒng)需求規(guī)格說明書[模版]
車輛管理系統(tǒng)
軟件需求規(guī)格說明書
班 級 08軟工A2 組 號
擬制人 陸美娟
2011年3月14日
第五篇：圖書管理系統(tǒng)需求分析
云南工商學院09信息管理1班
圖書管理系統(tǒng)需求分析
班級：09信息管理1班
組員： 唐學悅，段敏，楊文燕，胡勇毅，余科輯，林春宇，李波
任務分配情況：
云南工商學院09信息管理1班
目錄 系統(tǒng)需求概述...............................................................................................................................3 1.1 圖書管理系統(tǒng)功能概述....................................................................................................3 1.2 系統(tǒng)主要業(yè)務流程分析....................................................................................................3 1.3 系統(tǒng)功能模塊分析............................................................................................................3 1.4 建立用例模型....................................................................................................................4 1.4.1 讀者用例圖.............................................................................................................4 1.4.2 圖書管理員用例圖.................................................................................................4 1.4.3 系統(tǒng)管理員用例圖.................................................................................................5 1.5 詳述用例............................................................................................................................5 2 系統(tǒng)分析.......................................................................................................................................6 2.1 類圖....................................................................................................................................6 3 系統(tǒng)設計.......................................................................................................................................8 3.1 用例動態(tài)模型設計............................................................................................................8 3.1.1 實現“讀者查詢個人借閱信息”用例的動態(tài)模型.................................................8 3.1.2 實現“查詢圖書信息”用例的動態(tài)模型.................................................................9 3.1.3 實現“借閱圖書”用例的動態(tài)模型.........................................................................9 3.2 類圖設計..........................................................................................................................11 3.3 物理架構設計..................................................................................................................12 3.3.1 組件圖...................................................................................................................12 3.3.2 配置圖...................................................................................................................13 2
云南工商學院09信息管理1班
1.系統(tǒng)需求概述
1.1 圖書管理系統(tǒng)功能概述
圖書管理主要是借書、還書以及其他一些附帶操作（例如，超期罰款、催還圖書等）的處理。一個簡單的圖書管理系統(tǒng)應提供如下功能：
·借書處理：完成讀者借書的流程處理?！み€書處理：完成讀者還書的流程處理。
·信息查詢：包括圖書信息查詢和讀者借閱情況查詢?！D書管理：包括輸入新書記錄和刪除舊書記錄。
1.2 系統(tǒng)主要業(yè)務流程分析
與系統(tǒng)功能相對應，系統(tǒng)主要有4個流程：結束流程、還書流程、圖書查詢、圖書資源管理。各流程的主要過程描述如下：
·借書流程：讀者借閱所需的圖書，借出后圖書記錄中的借閱標志被置為false(不能再借)，借書文件中增加一個借書記錄。
·還書流程：讀者歸還所借的圖書，還書后圖書記錄中的借閱標志被置為true(可被外借)，在借書文件中刪除一個借書記錄。
·圖書查詢：讀者和工作人員可以進行圖書信息查詢，輸入圖書的編號或書名，可從圖書對象列表中查找相應的記錄。
·圖書管理：首先由工作人員在“錄入新書資料”和“刪除舊書資料”兩個選項中選擇。若是“錄入新書資料”，則由工作人員輸入新書資料，將新書添加為對象列表的新紀錄。若是“刪除舊書資料”，則查找需要刪除的圖書，將其從圖書對象列表中刪除。
1.3 系統(tǒng)功能模塊分析
滿足上述需求的系統(tǒng)主要包括以下幾個系統(tǒng)模塊：
·基本業(yè)務處理模塊：主要用于實現圖書管理員對讀者借閱圖書和歸還圖書的處理。
·信息查詢模塊：重要用于實現讀者對圖書信息和自身借閱信息的查詢。
云南工商學院09信息管理1班
·系統(tǒng)維護模塊：主要用于實現系統(tǒng)管理員對讀者信息、圖書管理員信息、圖書信息、和數據庫的管理。
1.4 建立用例模型
根據功能需求構造用例模型，主要任務是識別系統(tǒng)中的所有參與者，并對每個參與者找出其用例，建立用例模型。
系統(tǒng)主要的參與者為“讀者”、“圖書管理員”、和“系統(tǒng)管理員”。各個參與者的用例圖如下：
1.4.1 讀者用例圖
<
圖1-1 讀者用例圖
1.4.2 圖書管理員用例圖
<
圖1-2 圖書管理員用例圖
云南工商學院09信息管理1班
1.4.3 系統(tǒng)管理員用例圖
添加書目添加讀者刪除書目刪除讀者系統(tǒng)管理員查詢圖書查詢讀者
圖1-3 系統(tǒng)管理員用例圖
1.5 詳述用例
在識別了參與者和主要用例并創(chuàng)建了用例圖之后，如果有必要，還可以按順序詳述每個用例，包括用例如何開始、結束以及如何與參與者進行交互。
表1-1 讀者查找個人借閱信息用例
用例：讀者查找個人借閱信息(用例名稱)(唯一標識符)(涉及用例的參與者)(用例開始時，系統(tǒng)必須滿足的條件)ID：1參與者：
1、讀者前提條件： 讀者已登錄到系統(tǒng)事件流：
1、讀者選擇查找個人借閱信息界面
2、讀者輸入圖書證編號
3、系統(tǒng)按圖書證編號查找讀者借閱信息結果：系統(tǒng)向讀者顯示讀者借閱信息，該用例結束(用例中的實際步驟)(用例結束時，系統(tǒng)的狀態(tài))
云南工商學院09信息管理1班
表1-2 讀者查找圖書信息用例
用例：讀者查找圖書信息(用例名稱)(唯一標識符)(涉及用例的參與者)ID：2參與者：
1、讀者(用例開始時，系統(tǒng)必須滿足的條件)前提條件： 讀者已經啟動圖書管理系統(tǒng)，并已知書名或書號事件流：
1、讀者選擇查找圖書信息界面
2、讀者輸入書名或書號
3、系統(tǒng)按書名或書號查找圖書信息結果：系統(tǒng)向讀者顯示圖書信息，該用例結束(用例中的實際步驟)(用例結束時，系統(tǒng)的狀態(tài))系統(tǒng)分析
2.1 類圖
在定義系統(tǒng)需求后，下一步就是確定系統(tǒng)中存在的對象類。系統(tǒng)中對象類的識別可以使用名詞/動詞分析法來進行，即文本中的名詞和名詞短語暗示類或類的屬性，動詞和動詞短語暗示職責或者類的操作。
通過用例圖的分析可知，在圖書管理系統(tǒng)中可以確定的主要對象類包括 “讀者”，“圖書”、“圖書管理人員”和“系統(tǒng)管理員”。其中“讀者”和“圖書”通過借閱關系可以構成一個新類“借閱記錄”。
另外，分析用例圖可知，用例“身份驗證”和“圖書資料查詢”是對象類“讀者”和“工作人員”共同擁有的，并且用例“身份驗證”是除用例“圖書資料查詢”之外其余用例執(zhí)行的前提，因此可以將“身份驗證”與“圖書資料查詢”定義為接口類中的操作(接口類是不含屬性且操作函數沒有具體實現的抽象類，接口類通過一個實現聯系獲得其它對象類的支持，這些對象類實現接口類中定義的全部操作)。其余用例則抽象為與該用例交互的參與者所屬對象類的操作。因此，最后可獲得的對象類圖為：
云南工商學院09信息管理1班
系統(tǒng)管理員-name-password1*讀者-name-number-password+借書()+還書()+借閱情況查詢()***<
圖1-4 系統(tǒng)對象類圖
除了定義上述用于系統(tǒng)數據信息存儲管理和業(yè)務邏輯控制的類之外，在用圖形用戶界面開發(fā)系統(tǒng)時，我們還可以定義一些相應的用戶界面類：
(1)MainWindow類—MainWindow是圖書管理員與系統(tǒng)交互的主界面，系統(tǒng)的主 界面具有菜單，當用戶選擇不同的菜單項時，MainWindow對象調用相應的方法完成功能操作。
(2)BorrowDialog類—BorrowDialog是進行借書操作時需要的對話框。(3)ReturnDialog類—ReturnDialog是進行還書操作時需要的對話框。(4)QueryDialog類—QueryDialog是查詢某借閱者的借閱信息或圖書庫存信息的對話框。
(5)MaintenanceWindow類—MaintenanceWindow是系統(tǒng)管理員對系統(tǒng)進行維護的主界面，它也提供菜單項。
ReturnDialogBorrowDialogMainWindowQueryDialogMaintenanceDialog 圖1-5圖書管理系統(tǒng)的用戶界面類
云南工商學院09信息管理1班 系統(tǒng)設計
系統(tǒng)設計的主要工作是用例實現—設計。即對每個用例進行動態(tài)建模，包括建立序列圖、協(xié)作圖等，描述如何通過類對象的協(xié)作來實現用例中的功能。隨著動態(tài)建模的深入，會發(fā)現原來建立的類存在缺陷或不夠完整，需要對分析中得到的類圖進行不斷的修正和調整。所以，還應該通過動態(tài)建模來修正和完善類圖。
3.1 用例動態(tài)模型設計
3.1.1 實現“讀者查詢個人借閱信息”用例的動態(tài)模型
:MainWindow:QueryDialog:BorrowBookBorrower1:queryLoan2:createDialog3：queryLoanInfo4:getBook5:消息查詢6：返回借閱信息7：顯示借閱信息
圖1-6 讀者查詢個人借閱信息序列圖
1:queryLoan():MainWindowerBorrower6:顯示借yLoanInfo()閱信息5:返回借閱信息:Borrower-Book4:getBook():QueryDialog2:createDialog()3:qu
圖1-7 讀者查詢個人借閱信息協(xié)作圖
云南工商學院09信息管理1班
3.1.2 實現“查詢圖書信息”用例的動態(tài)模型
:MainWindow:QueryDialog:BorrowBookBorrower1:queryLoan2:createDialog3：queryLoanInfo4:findBook5:圖書信息查詢6：返回圖書信息7：顯示圖書信息 圖1-8 讀者查詢圖書序列圖
1:queryLoan():MainWindowerBorrower6:顯示圖yLoanInfo()書信息5:返回圖書信息:Borrower-Book4:findBook():QueryDialog2:createDialog()3:qu
圖1-9 讀者查詢圖書協(xié)作圖
3.1.3 實現“借閱圖書”用例的動態(tài)模型
云南工商學院09信息管理1班
:MainWindow:BorrowDialog:QueryDialogBorrower1:queryLoan2:createDialog4:查詢圖書庫存5:返回圖書是否可借6:修改讀者的借閱信息及庫存信息7:修改成功8:顯示借書成功
圖1-10 讀者借閱圖書序列圖
2:createDialog()oan():MainWindow:BorrowDialogry1:queL息6:顯示借書成功存庫信書借存圖可庫詢否及查是息功:4書信成圖閱改修Borrower回借:7返者:讀5改修:6:QueryDialog
圖1-11 讀者借閱圖書協(xié)作圖
云南工商學院09信息管理1班
3.1.4 實現“歸還圖書”用例的動態(tài)模型
:MainWindow:ReturnDialog:QueryDialogBorrower1:queryLoan2:createDialog3:修改讀者的借閱信息及庫存信息4:修改成功5:顯示還書成功
圖1-12 讀者歸還圖書序列圖
1:queryLoan():MainWindowBorrower6:顯示還書成功4:修改成功:QueryDialog3:修改讀者的借閱信息及庫存信息:ReturnDialog2:createDialog()
圖1-13 讀者歸還圖書協(xié)作圖
3.2 類圖設計
進一步擴充和細化分析階段定義的類，包括定義新的類來處理用戶的需求。隨著動態(tài)建模的深入，也會發(fā)現原來建立的類存在缺陷或不夠完整，需要對分析中得到的類圖進行不斷的修正和調整。所以，還應該通過動態(tài)建模來修正和完善類圖。
云南工商學院09信息管理1班
系統(tǒng)管理員-name:string-password:string+AddBook()+QueryBook()+AddBorrower()+QueryBorrower()借書記錄-borrower:string-book:string-date:Date+newLoan()+getBorrower()+getBook()11*讀者-name:string-number:string-password:string+Borrow()+Return()+QueryLoan()***<
圖1-14 設計類圖
3.3 物理架構設計
物理架構設計就是用UML圖形描述系統(tǒng)軟件和硬件的大致結構，包括畫出組件圖和配置圖。
3.3.1 組件圖
組件圖：表示構成軟件系統(tǒng)的各物理組件及其相互之間的聯系。它能明確表示軟件系統(tǒng)各部分的功能職責。圖書管理系統(tǒng)的組件圖如下所示，其中包含“借/還書處理”、“信息查詢”、“圖書資源管理”和“身份驗證”等組件。
云南工商學院09信息管理1班
圖書管理系統(tǒng)借/還處理信息查詢圖書資源管理身份驗證圖書信息借閱信息
圖1-15 系統(tǒng)組件圖
3.3.2 配置圖
圖書管理系統(tǒng)是一個基于網絡和數據庫的應用系統(tǒng),可以采用B/S結構,系統(tǒng)配置圖下圖所示：
數據庫服務器圖書信息借閱信息讀者客戶端借/還書處理工作人員客戶端公共客戶端身份驗證圖書資源管理借閱信息圖書資料查詢 圖1-16 系統(tǒng)配置圖
點擊咨詢 