第一篇：學籍管理系統2.軟件需求說明書
軟件需求說明書引言
1.1 編寫目的本軟件需求說明書是系統設計的依據，是系統分析與設計人員的必讀的參考用書。
1.2 背景
a.學籍管理系統
b.本項目的任務是由相關學籍管理的需求，由財經學院信息學院07計算機2班承擔，**等課題組成員進行研制、開發，待使用的是某高校教務處，本項目主要解決對學生學籍及學生成績方面的各種輸入，修改，匯總，查詢等基本操作。
1.3 定義
軟件需求說明書。
1.4 參考資料
a.本項目的開題報告；
b.本項目的可行性分析報告；
c.計算機軟件工程規范國家標準匯編2000。
2.任務概述
2.1 目標
在學校中應用學籍管理信息系統，不僅可以簡化學校傳統的管理模式，使學校管理人員能夠方便地利用計算機對學生檔案、學生成績等信息進行全面管理，更重要的是利用學籍管理技術可以使學生管理規范化、制度化、數字化，使學校以高效率運轉，解決原有的手工作業耗時費力，又不能保證數據的正確性等問題。
2.2用戶的特點
本軟件的最終用戶為某高校教務處管理人員、各年級各學科教師、各位學生等，其中教務處管理人員、各年級各學科教師比較熟悉本職業務，具有大專或大專以上文化程度，通過短期培訓就可以勝任此項工作，而學生在本系統上進行的操作十分簡單，可以馬上使用，本軟件啟用后，對于學生的學籍管理會有很大的改善，效率提升，節省資源，可以做到及時更新。
2.3假定和約束
本項目的硬件、軟件費用到位，則可立即開工，并按計劃完成。需求規定
3.1對功能的規定
該項目主要功能為：學生基本信息處理（有輸入、取消、確認、查詢等功能）；學生成績信息處理（有輸入、取消、確認、修改、查詢、打印等功能）；學生獎勵處分信息處理（有輸入、修改、刪除、查詢等功能）及教師基本信息處理（有輸入、修改、刪除、查詢等功能組成）。
3.2對性能的規定
3.2.1精度
該軟件的輸入、輸出數據精度的要求整數部分3位，小數部分1位，精確到0.5分。
3.2.2時間特性要求
a.查詢響應時間在一秒鐘內；
b.更新處理時間在一秒鐘內；
c.數據的轉換和傳送時間在半分鐘內。
3.2.3靈活性
a.操作方式上提供鍵盤操作和鼠標操作兩種；
b.當運行環境的變化，通過簡單的重編譯或重連接或作適當的改正能適應新環境的要求。
3.3輸入輸出要求
對于輸入盡量減輕用戶的輸入量，輸出提供預先屏幕預覽，然后，打印輸出，屏幕上看到的應同打印輸出的一模一樣。
3.4數據管理能力要求
數據的管理包括源程序的管理與數據庫的管理兩部分組成，能對源程序與數
據庫進行數據備份與數據恢復的能力。
3.5故障處理要求
對硬件故障待排除后，軟件可重進行故障斷點處繼續工作，對軟件上使用不當產生的錯誤，由軟件以對話框的方式，警告用戶。運行環境規定
4.1設備
研制該軟件需要一臺計算機及一臺普通打印機。
a.應該是CPU為酷睿2或更高檔次的計算機，內存在2G或更大的； b.打印機應具有較高密度，以保證打印的文字清晰；
c.先在單機上實施，獲得成功后，再在C/S結構上推廣應用。
4.2支持軟件
操作系統為：Windows XP,前臺開發工具為：Delphi, 后臺數據庫為：SQL Server 2000。
4.3接口
該軟件前臺開發工具與后臺數據庫通過ADO連接。
4.4控制
該軟件的運行的方式采用菜單驅動，鼠標與鍵盤并用方式進行。
第二篇：圖書館管理系統(軟件需求說明書)
1引言...............................................................................................................................................2 1.1編寫目的.................................................................................................................................2 1.2背景說明.................................................................................................................................2 2任務概述.......................................................................................................................................3 2.1目標.......................................................................................................錯誤！未定義書簽。2.1.1開發意圖............................................................................................錯誤！未定義書簽。2.1.2應用目標............................................................................................錯誤！未定義書簽。2.1.3作用及范圍........................................................................................錯誤！未定義書簽。2.2用戶特點...............................................................................................錯誤！未定義書簽。2.3假定與約束...........................................................................................錯誤！未定義書簽。3需求規定.....................................................................................................錯誤！未定義書簽。3.1對功能的規定.......................................................................................錯誤！未定義書簽。3.2對性能規定.............................................................................................................................8 3.2.1精度....................................................................................................錯誤！未定義書簽。3.2.2時間特性要求....................................................................................錯誤！未定義書簽。3.2.3靈活性...................................................................................................................................9 3.3輸入輸出要求.......................................................................................錯誤！未定義書簽。3.4數據管理能力要求...............................................................................................................11 3.5故障處理要求.......................................................................................................................12 3.6其他專門要求.......................................................................................................................12 4運行環境設定.............................................................................................................................13 4.1設備.......................................................................................................................................13 4.2支持軟件...............................................................................................錯誤！未定義書簽。4.3接口.......................................................................................................錯誤！未定義書簽。4.3.1用戶接口............................................................................................錯誤！未定義書簽。4.3.2軟件接口............................................................................................錯誤！未定義書簽。4.4控制.......................................................................................................錯誤！未定義書簽。4.5出錯處理和恢復...................................................................................錯誤！未定義書簽。
1.引言
1.1.編寫目的
需求的編寫是為了研究圖書管理系統軟件的開發途徑和應用方法。同時它也是進行項目策劃、概要設計和詳細設計的基礎，是維護人員進行內部維護，信息更新，驗收和測試的依據。本需求的預期讀者是與圖書管理系統軟件開發有聯系的決策人，開發組成人員，扶助開發者，支持本項目的領導和公司人員，軟件驗證者。
1.2.背景說明
人工管理圖書的手續繁索、效率低下給具有強烈時間觀念的管理人員帶來了諸多不便，學校圖書館缺少一套完善的圖書管理軟件，為了對圖書的管理方便，因此必須開發圖書管理系統。
隨著計算機技術的不斷應用和提高，計算機已經深入到社會生活的各個角落。而采用手工管理圖書的方法，不僅效率低、易出錯、手續繁瑣，而且耗費大量的人力。為了滿足圖書館管理人員對圖書館書籍，讀者資料，借還書等進行高效的管理，在工作人員具備一定的計算機操作能力的前提下，特編此圖書管理系統軟件以提高圖書館的管理效率。2.任務概述
2.1.目標
建立的圖書管理系統，要把圖書館的圖書管理、讀者管理、圖書借閱管理等日常管理工作實行計算機統一管理，以提高工作效率和管理水平。
2.1.1 開發意圖
a.為了圖書管理系統更完善；
b.為了學校圖書館對圖書的管理更方便；
c.為了減輕圖書管理人員的工作負擔。
2.1.2 應用目標
通過本系統軟件，能幫助圖書館管理人員利用計算機，快速方便地對圖書館書籍，讀者資料，借還書等進行高效的管理。
2.1.3 作用及范圍
本軟件適用于教育界，它是比較完善的系統管理軟件，對圖書館的書籍，讀者資料，借還書等可以進行方便的管理。
System圖書管理系統查詢信息辦理借書還書業務讀者借閱，歸還圖書反饋系統管理維護信息管理，維護系統系統管理員圖書管理員圖書管理系統概況圖
圖1.圖書管理系統用例概況圖
2.2.用戶的特點
本軟件的使用對象有學校圖書館的系統管理員（更新維護系統），圖書管理人員（辦理借閱，歸還圖書）和讀者（查詢圖書）。
備注：會漢語、懂計算機的基本操作就可以利用該軟件進行所需操作。
圖2.系統管理員信息
圖3.圖書管理員信息
圖 4.讀者信息
2.3.假定與約束
人力資源約束：
a.估計開發該系統需購買硬件、外部設備（P4微機一臺、打印機一臺），花費1.2萬元左右，開發工作量約需3個人月工作量，每人月工資為2000元，開發完成后維護費用每年600元，開發完成后，原有的3名管理人員可以減少2名，每人月工資600元。
b.輔導老師1人，開發人員3人； 技術約束：
本項目的設計是在JavaC++.NET程序設計語言的條件下進行的，技術設計采用軟硬一體化的設計方法。
環境約束：
運行該軟件所適用的具體設備必須是奔騰
4、內存256兆以上的計算機;3.需求規定
1、理解需求
理解需求是在問題及其最終解決方案之間架設橋梁的第一步。開發者只有和用戶充分理解了需求之后才能開始設計系統，否則，對需求定義的任何改進，設計上都必須大量的返工。
下面是對系統的終端用戶和客戶調研后得到的需求規格說明書。
(1)在啟動系統后，首先是登陸界面，根據用戶輸入判斷用戶身份是否合法。合法用戶分為普通用戶和系統管理員，其中，系統管理員擁有所有權限，而普通用戶沒有用戶管理權限。
(2)進入讀者信息維護界面，可以對讀者信息進行添加、刪除、修改和查詢操作，并且可以遍歷記錄。
(3)進入圖書信息維護界面，可以對圖書信息進行添加、刪除、修改和查詢操作，并且可以遍歷記錄。
(4)進入讀者借還書界面，可以實現讀者借書、還書和查閱讀者借閱記錄的功能，并在讀者借還書時，對相應數據庫數據進行修改。
(5)系統客戶端運行在Windows平臺下，服務器可以運行在Windows或Unix平臺下。系統還應該有一個較好的圖形用戶界面。(6)系統應該有很好的可擴展性。
2、需求分析
需求分析是從客戶的需求中提取出軟件系統能夠幫助用戶解決的業務問題，通過對用戶業務問題的分析，確定系統的功能需求。這個步驟是對理解需求的升華，直接關系到該系統的質量。分析的根本目的是在開發者和提出需求的人之間建立一種理解和溝通機制，因此，系統的需求分析也應該是開發人員和用戶或客戶一起完成的。
<1>系統功能模塊劃分
根據開發者和客戶的需求分析后，可以把系統功能分為兩個大的個功能模塊：(1)讀者管理模塊
包括：讀者登記，查詢，借書，還書，刪除等功能(2)圖書管理模塊
包括：圖書添加，查詢等功能
3.1.對功能的規定
System歸還圖書（管理員）辦理還書符合條件<
圖5.圖書管理員處理借書、還書用例圖
System查詢圖書信息<
圖6.借閱者請求服務用例圖
System增加系統功能增加圖書增加讀者查詢圖書信息查詢讀者信息系統管理員移除,更新讀者移除，更新圖書移除，更新系統功能系統管理員管理維護系統的用例圖
圖 7.系統管理員管理維護系統用例圖
3.2.對性能的規定 3.2.1.精度
在精度需求上，根據使用需要，在各項數據的輸入，輸出及傳輸過程中，可以滿足各種精度的需求。如：根據關鍵字精度的不同，查找可分為精確查找和泛型查找，精確查找可精確匹配讀者已知道的書目，泛型查找，只要滿足與輸入的關鍵字相匹配的書目即輸出，可供讀者查找。
3.2.2.時間特性要求
在軟件方面，響應時間，更新處理時間都比較快且迅速，完全滿足用戶要求。
3.2.3.靈活性
當用戶需求，如操作方式，運行環境，結果精度，數據結構于其他軟件接口等發生變化時，設計的軟件要做適當調整,靈活性非常大。
3.3.輸入輸出要求
查詢書目：輸入關鍵字為書名，作者，索引號，按照精確匹配為主，再索引關聯字。輸出時列出索引到的所有書目信息，具體信息包括內容摘要、目錄號、作者信息、書名、價格、流水號、購買日期等。方便讀者查找。
圖8.查詢圖書信息流程圖
圖9.圖書相關屬性
借閱圖書：通過設備識別圖書和讀者（借閱證）的流水號（條形碼），向數據庫傳送信息，然后在數據庫索引圖書信息和讀者信息是否符合要求，符合要求待圖書管理員確認后再更新相關數據，并將這些數據存入借書文件，最后輸出顯示存儲成功；否則報錯。
查看讀者的借閱信息：進入讀者借書信息管理系統，只需要輸入讀者個人信息即可，然后系統根據輸入的信息，送圖書館管理系統索引查找相關信息，最后將讀者借書的信息輸出顯示。
圖 4.讀者信息
圖10.讀者借閱圖書流程圖
3.4.數據管理能力要求
圖 11.定時整理數據：系統管理員根據市場圖書行情定時整理系統數據庫，對圖書的借閱情況、讀者的管理情況、書庫的增減等均可有計算機執行，并將運行結果歸檔。
查詢庫存量：能隨時查詢書庫中圖書的庫存量，以便準確、及時、方便地為讀者提供借閱信息，但不能修改數據,無信息處理權，即可以打印清單、瀏覽數據等，管理權限由系統管理員掌握和分配。
3.5.故障處理要求
a.內部故障處理
在開發階段可以隨即修改數據庫里的相應內容。
b.外部故障處理
對編輯的程序進行重裝載時，第一次裝載認為錯，修改。第二次運行，在需求調用時出錯，有錯誤提示，重試。
c.本軟件可能產生的錯誤為數據庫的錯誤信息，應由數據庫管理員對數據庫進行維護。為了確保系統恢復的能力，數據庫管理員要定期對數據庫進行備份。
3.6.其它專門要求
數據的安全性、完整性要求：圖書館各項數據信息必須保證安全性和完整性。網絡系統設有通信、程序、網絡三級權限和口令管理，確保系統安全。
4.運行環境設定
4.1.設備
硬件、外部設備（P4微機一臺、打印機一臺）
運行本軟件所要求的硬設備的最小配置： a.奔騰4代、內存256M；
b.I／O設備：顯示器、鼠標、鍵盤；
4.2.支持軟件
說明為運行本軟件所需要的支持軟件，如： a.操作系統：Windows98及以上版本 b.支撐框架：.NET Framework1.1 c.數據庫：Access2000。
4.3.接口
4.3.1 用戶接口
本產品的用戶一般需要通過終端進行操作，進入主界面后點擊相應的窗口，分別進入相對應的界面(如：輸入界面、輸出界面)。用戶對程序的維護，最好要有備份。
4.3.2 軟件接口
WIN9X/NT操作系統。
4.4.控制
本軟件是以中文版Windows 98及其以上版本的操作系統來控制軟件運行。
第三篇：學生公寓管理系統需求分析說明書
學生公寓管理系統需求概況
在學校面向現代化、面向世界、面向未來、面向互聯網的21世紀，現今社會是一個講究效率的社會，人們有很強的時間觀念，如果仍使用手工操作或使用相當繁瑣的軟件，既浪費了人力，又浪費了物力，效率無法提高，尤其是在學校里。為此開發學生公寓管理系統軟件，能夠適應現今社會并提高生產效率。該系統軟件非常容易被接受，它具有簡單易學性，雙重操作管理體系，便于管理等功能。它是對學校學生管理的一種工具。為使校園網得到高效、合理的利用，以教育信息化帶動教育的現代化，加強學校信息管理，將建設成信息化、現代化的新校園，為新世紀的交院增添新氣息、樹立新形象，學校于2008年全面啟動信息化建設工程。
一、主要功能
1、系統管理
（1）用戶設置與權限分配（2）公共數據管理
2、公寓房源管理（1）定義房源信息（2）定義房間設施信息
3、公寓住宿管理（1）學生住宿登記（2）調退房登記（3）設施損毀登記
4、公寓分配管理（1）學生分配住房（2）學生調退房處理
5、公寓財務管理（1）預交費用（2）費用結算
6、報表管理（1）財務報告
（2）學生住宿情況統計報告
7、數據檢索（1）房源檢索（2）學生住宿檢索（3）費用檢索
二、用戶類別
1、系統用戶（系統管理員）
2、房源定義用戶（公寓管理中心）
3、住房分配用戶（系部）
4、住宿登記用戶（公寓管理員）
5、財務用戶（后勤財務）
三、業務流程
1、初始化處理（1）系統用戶定義各類用戶及其權限（2）公寓管理中心定義房源
（3）公寓管理中心定義住宿費用已經房源設施及價格（4）公寓管理中心給各系部分配房源（5）對已分配房源但未住宿登記的房源初始化
2、學生住宿處理流程（1）學生到系部分配房間（2）學生到后勤財務交預付款（3）學生到公寓管理員登記住宿
3、學生調房處理流程（1）學生到系部申請調房（2）學生到財務處理住宿費用（3）學生到公寓管理員登記調房
4、學生調房處理流程（1）學生到系部申請退房
（2）學生到公寓管理員登記退房（注意設施損毀登記）(3)學生到財務結算費用（根據預交費用與實際住宿費用結算）
四、相關報表及憑據（1）學生收費收據（2）班級住宿名冊
（4）年費用結算報表（按）
（5）房源報表（空置房、房源分配情況、房源登記情況）（6）設施損毀報告（按、按設施類型）（7）房間住宿人員臺賬（按指定區間）（8）學生住宿情況臺賬(按指定區間)
第四篇：車輛管理系統需求規格說明書
車輛管理系統
軟件需求規格說明書
班 級 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運行環境.........................................................................................................3 2.5設計和實現限制.............................................................................................3 2.6 假定和約束....................................................................................................3
2.6.1人力資源約束.....................................................................................3 2.6.2技術約束.............................................................................................3 2.6.3環境約束.............................................................................................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狀態圖...........................................................................................................21 5非功能需求...............................................................................................................22
5.1性能需求.......................................................................................................22
5.1.1時間、界面、響應要求...................................................................22 5.1.2靈活性...............................................................................................22 5.2數據管理需求...............................................................................................22
5.2.1系統數據流圖...................................................................................22 5.2.2數據整理與保存...............................................................................24 5.2.3數據安全性.......................................................................................24 5.3故障處理需求...............................................................................................24
1引言
1.1編寫目的
需求說明的編寫是為了研究車輛管理軟件的開發途徑和應用方法。同時它也是進行項目策劃、概要設計和詳細設計的基礎，是維護人員進行內部維護，信息更新，驗收和測試的依據。本文檔將對車輛管理系統軟件開發需求進行描述。
1.2 背景
物流系統是現代經濟系統的主動脈，物流的最簡單理解就是貨物運輸，所以運輸在物流運作中的地位十分重要，而車輛是運輸企業的命脈，有機的管理好車輛十分關鍵。傳統的運輸業已不能滿足市場需求。運輸企業的信息化管理具有重要意義。
開發軟件名稱：車輛管理系統 項目開發者：08軟工A1 舒驥 用戶：運輸集團公司
1.3 預期讀者
本需求的預期讀者是開發組成人員，軟件測試人員，支持本項目的老師，軟件維護人員。
1.4參考資料
[1].《軟件需求工程》 毋國慶 梁正平袁夢霆 李勇華 編著[2].《UML基礎與Rose建模教程》 蔡敏 徐惠惠 黃炳強 編著
[3].《C#數據庫系統開發完全手冊》 明日科技 張躍延 許文武 王小科 編著
[4].《軟件工程實驗與實踐教程》 陳佳 曹妍 編著 [5].《實用軟件文檔寫作》 肖剛 古輝 程振波 張元鳴 著 2綜合描述
2.1產品目標
車輛管理系統將為企業提供各種車輛管理和快速查詢的功能，以提高公司的運作效率，降低運作成本。
2.2產品功能
* 車輛基本信息管理 * 車輛購置管理 * 車輛調撥管理 * 車輛報廢管理 * 車輛信息管理查詢
2.3用戶范疇和特征
本軟件最終用戶為汽車運輸集團公司。該公司主要設有技術服務部、客貨運輸部、企業管理部等職能部門，下屬運輸公司有零擔運輸公司、客運公司、整車運輸公司、旅游公司等，其組織結構如下圖1：
圖1：運輸集團公司組織結構圖
2.4運行環境
運行該軟件所適用的具體設備必須是奔騰
4、內存512MB以上的計算機。操作系統在Windows xp及以上。
數據庫為SQL Server2000版本
2.5設計和實現限制
僅設計為本地版本，無需聯網，沒有服務器端。
2.6 假定和約束
2.6.1人力資源約束
1、開發工作量約需1個人2月工作量。開發完成后，可減少為1名作為維護人員；
2、輔導老師1人，開發人員2人。
2.6.2技術約束
本項目的設計是在ASPAsp.Net程序設計語言的條件下進行的，技術設計采用軟硬一體化的設計方法。
2.6.3環境約束
運行該軟件所適用的具體設備必須是奔騰
4、內存512MB以上的計算機。操作系統在Windows xp及以上。
3外部接口需求
3.1用戶界面
見《系統設計說明書》
3.2硬件接口
考慮到大量數據的備份等要求，需要保持與磁帶機、光盤刻錄機及USB的接口，這較易實現。
3.3軟件接口
這里，主要考慮軟件與操作系統、數據庫管理系統的接口。由于不存在從其他文件導入的功能，所以無需擔心格式轉換的問題。該軟件更趨向于單一封閉的單機版軟件。
3.4通信接口
無需與網絡連接，只需考慮與外部移動設備的通信。
4功能性需求
4.1功能分析
1、車輛基本信息管理模塊
(1)用戶的登錄管理：不同級別的用戶通過特定的用戶名和密碼登錄系統，對相應的信息進行管理。
(2)查詢車輛基本信息：通過輸入車輛的基本信息對車輛的整體信息進行查詢。(3)刪除車輛基本信息：有相關權限的用戶可對某些不再需要的車輛信息進行刪除。
(4)修改車輛基本信息：有相關權限的用戶如有必要，可對車輛的基本信息進 行修改。
(5)添加車輛基本信息：有相關權限的用戶可添加車輛的基本信息。
2、車輛購置管理模塊
用戶可添加、修改、刪除、查詢車輛購置管理申請單，然后交由總工程師申請審批，如通過再有總經理申請審批，實現二級公司要提交車輛的購置申請，集團公司職能部門根據車輛的產權歸屬，由總工程師或總工程師及總經理對申請進行審批，生效后產生調撥單下發所屬公司及各有關部門。
3、車輛調撥管理模塊
與車輛購置管理類似，用戶可添加、修改、刪除、查詢車輛調撥管理申請單，然后交由總工程師申請審批，如通過再有總經理申請審批，實現二級公司要提交車輛的購置申請，集團公司職能部門根據車輛的產權歸屬，由總工程師或總工程師及總經理對申請進行審批，生效后產生調撥單下發所屬公司及各有關部門。
4、車輛報廢管理模塊
與車輛購置管理類似，用戶可添加、修改、刪除、查詢車輛報廢管理申請單，然后交由總工程師申請審批，如通過再有總經理申請審批，實現二級公司要提交車輛的購置申請，集團公司職能部門根據車輛的產權歸屬，由總工程師或總工程師及總經理對申請進行審批，生效后產生調撥單下發所屬公司及各有關部門。
5、車輛信息查詢管理模塊
實現對多種信息的快速模糊查詢，可根據車輛所屬的二級公司，車牌號，車輛的廠牌，規格，型號等信息進行不同的組合來查詢車輛，還可根據申請購置，調撥，報廢車輛的二級公司，申請時間等查詢車輛的購置，調撥，報廢的申請及審批情況等。
4.2用例圖
1、車輛管理信息系統用例圖
2、車輛購置管理用例圖
3、車輛調撥管理用例圖
4、車輛報廢管理用例圖
5、車輛基本信息管理用例圖
4.3用例分析
一、車輛購置管理
用例1 用例名稱：添加車輛購置申請 用例識別號：1.1.1 參與者：二級公司用戶
簡要說明：二級公司用戶添加一個車輛購置申請單。前置條件：二級公司用戶已經登錄車輛管理信息系統。基本事件流：
1)二級公司用戶單擊“插入”按鈕。2)系統出現編輯窗口。
3)二級公司用戶可以在相應的文本框上添加或修改申請單，也可以完全刪除，重新填寫。
4)二級公司用戶編輯完相應的文本框，單擊“存盤”按鈕，一條新的車輛購置申請記錄就被插入到數據庫中。5)用例終止 其它事件流：
在單擊“存盤”按鈕之前，二級公司用戶隨時可以單擊“取消”按鈕，窗口內的任何內容都不會被保存。異常事件流：
1）提示錯誤信息，二級公司用戶確認。2）返回到管理系統主界面。
后置條件：一條新的車輛購置記錄被插入到數據庫中并顯示出來。注釋：無。
其它事件流：
在單擊“是”按鈕之前，二級公司用戶可以單擊“否”按鈕，車輛購置申請記錄不會被刪除。
異常件流：
1）提示錯誤信息，二級公司用戶確認。2）返回到管理系統主界面。
后置條件：選中的默認的車輛購置申請記錄從數據庫中被刪除，同時顯示界面被更新。
注釋：刪除之前，要先使用查詢功能，以便選擇要刪除的內容。
用例3 用例名稱：總工程師購置申請審批 用例識別號：1.2.1 參與者：總工程師
簡要說明：總工程師對二級公司用戶提交的車輛購置申請單進行審批。前置條件：總工程師已經登錄車輛管理信息系統、存在未審批的車輛購置申請。
基本事件流：
1)總工程師單擊選中要審批的車輛購置申請記錄。2)總工程師單擊“審批”按鈕。3)系統出現編輯窗口。
4)總工程師可以在審批意見文本框上添加或修改審批意見，也可以完全刪除，重新填寫。
5)總工程師選擇“同意”或“不同意”單選按鈕審批結果。
6)總工程師編輯完相應的文本框及選擇完審批結果后，單擊“存盤”按鈕，該車輛購置申請記錄就被審批，并在數據庫中修改該記錄的審批標志，審批結果和審批意見。7)用例終止。其它事件流：
在單擊“存盤”按鈕之前，總工程師隨時可以單擊“取消”按鈕，審批內容及審批結果都不會被保存。異常事件流：
1）提示錯誤信息，總工程師確認。2）返回到管理系統主界面。
后置條件：選中的車輛購置申請記錄被審批，并在數據庫中修改該記錄的審批標志、審批結果和審批意見。
注釋：審批之前，要先使用查詢功能，查出未審批的車輛購置申請記錄。
用例4 用例名稱：總經理購置申請批復 用例識別號：1.3.1 參與者：總經理
簡要說明：總經理對二級公司用戶提交的公司所屬車輛購置申請進行批復。前置條件：總經理已經登錄車輛管理信息系統、存在滿足如下條件的車輛購置申請記錄，即：總工程師已審批、總經理未批復的公司所屬車輛購置申請記錄。基本事件流：
1)總經理單擊選中要審批的車輛購置申請記錄。
2)總經理編輯完相應的文本框及選擇完批復結果后，單擊“存盤”按鈕，該車輛購置申請記錄就被批復，并在數據庫中修改該記錄的批復標志，批復結果和批復意見。3)用例終止。其它事件流：
在單擊“存盤”按鈕之前，總工程師隨時可以單擊“取消”按鈕，審批內容及審批結果都不會被保存。異常事件流：
1）提示錯誤信息，總經理確認。2）返回到管理系統主界面。
后置條件：選中的車輛購置申請記錄被批復，并在數據庫中修改該記錄的批復標志、批復結果和批復意見。
注釋：審批之前，要先使用查詢功能，查處總工程師已審批，總經理未批復的公司所屬車輛購置申請記錄。
二、車輛調撥管理
用例5 用例名稱：添加車輛調撥申請 用例識別號：2.1.1 參與者：二級公司用戶
簡要說明：二級公司用戶添加一個車輛調撥申請單。前置條件：二級公司用戶已經登錄車輛管理信息系統。基本事件流：
1)二級公司用戶單擊“插入”按鈕。2)系統出現編輯窗。
3)二級公司用戶可以在相應的文本框上添加或修改申請單，也可以完全刪除，重新填寫。
4)二級公司用戶編輯完相應的文本框，單擊“存盤”按鈕，一條新的車輛調撥申請記錄就被插入到數據庫中。5)用例終止。其它事件流：
在單擊“存盤”按鈕之前，二級公司用戶隨時可以單擊“取消”按鈕，窗口內的任何內容都不會被保存。異常事件流：
1)提示錯誤信息，二級公司用戶確認。2)返回到管理系統主界面。
后置條件：一條新的車輛調撥記錄被插入到數據庫中并顯示出來。注釋：無。
用例6 用例名稱：刪除車輛調撥申請 用例識別號：2.1.2 參與者：二級公司用戶
簡要說明：二級公司用戶刪除一個車輛調撥申請記錄。
前置條件：二級公司用戶已經登錄車輛管理信息系統、將要被刪除的車輛調撥申請沒有被審批。基本事件流：
1)二級公司用戶單擊選中要刪除的車輛調撥申請記錄。2)二級公司用戶單擊“刪除”按鈕。3)系統出現“提示是否刪除”窗口。
4)二級公司用戶單擊“是”按鈕，該車輛調撥申請記錄就被從數據庫中刪除。5)用例終止。其它事件流：
在單擊“是”按鈕之前，二級公司用戶可以單擊“否”按鈕，車輛調撥申請記錄不會被刪除。異常件流：
1）提示錯誤信息，二級公司用戶確認。2）返回到管理系統主界面。
后置條件：選中的默認的車輛調撥申請記錄從數據庫中被刪除，同時顯示界面被更新。
注釋：刪除之前，要先使用查詢功能，以便選擇要刪除的內容。
用例7 用例名稱：總工程師調撥申請審批 用例識別號：2.2.1 參與者：總工程師
簡要說明：總工程師對二級公司用戶提交的車輛調撥申請單進行審批。前置條件：總工程師已經登錄車輛管理信息系統、存在未審批的車輛調撥申請。
基本事件流：
1)總工程師單擊選中要審批的車輛調撥申請記錄。2)總工程師單擊“審批”按鈕。3)系統出現編輯窗口。
4)總工程師可以在審批意見文本框上添加或修改審批意見，也可以完全刪除，重新填寫。
5)總工程師選擇“同意”或“不同意”單選按鈕審批結果。
6)總工程師編輯完相應的文本框及選擇完審批結果后，單擊“存盤”按鈕，該車輛調撥申請記錄就被審批，并在數據庫中修改該記錄的審批標志，審批結果和審批意見。7)用例終止。其它事件流：
在單擊“存盤”按鈕之前，總工程師隨時可以單擊“取消”按鈕，審批內容及審批結果都不會被保存。異常事件流：
1）提示錯誤信息，總工程師確認。2）返回到管理系統主界面。
3）后置條件：選中的車輛調撥申請記錄被審批，并在數據庫中修改該記錄的審批標志、審批結果和審批意見。
注釋：審批之前，要先使用查詢功能，查出未審批的車輛調撥申請記錄。
用例8 用例名稱：總經理調撥申請批復 用例識別號：2.3.1 參與者：總經理
簡要說明：總經理對二級公司用戶提交的公司所屬車輛調撥申請進行批復。前置條件：總經理已經登錄車輛管理信息系統、存在滿足如下條件的車輛調撥申請記錄，即：總工程師已審批、總經理未批復的公司所屬車輛調撥申請記錄。基本事件流：
1)總經理單擊選中要審批的車輛調撥申請記錄。2)總經理單擊“審批”按鈕。3)系統出現編輯窗口。
4)總經理可以在審批意見文本框上添加或修改批復意見，也可以完全刪除，重新填寫。
5)總經理選擇“同意”或“不同意”單選按鈕批復結果。
6)總經理編輯完相應的文本框及選擇完批復結果后，單擊“存盤”按鈕，該車輛調撥申請記錄就被批復，并在數據庫中修改該記錄的批復標志，批復結果和批復意見。7)用例終止。其它事件流：
在單擊“存盤”按鈕之前，總工程師隨時可以單擊“取消”按鈕，審批內容及審批結果都不會被保存。異常事件流：
1）提示錯誤信息，總經理確認 2）返回到管理系統主界面
后置條件：選中的車輛調撥申請記錄被批復，并在數據庫中修改該記錄的批復標志、批復結果和批復意見。
注釋：審批之前，要先使用查詢功能，查處總工程師已審批，總經理未批復的公司所屬車輛調撥申請記錄。
三、車輛報廢管理
用例9 用例名稱：添加車輛報廢申請 用例識別號：3.1.1 參與者：二級公司用戶
簡要說明：二級公司用戶添加一個車輛報廢申請單。前置條件：二級公司用戶已經登錄車輛管理信息系統。基本事件流：
1)二級公司用戶單擊“插入”按鈕。2)系統出現編輯窗口。
3)二級公司用戶可以在相應的文本框上添加或修改申請單，也可以完全刪除，重新填寫。
4)二級公司用戶編輯完相應的文本框，單擊“存盤”按鈕，一條新的車輛報廢申請記錄就被插入到數據庫中。5)用例終止。其它事件流：
在單擊“存盤”按鈕之前，二級公司用戶隨時可以單擊“取消”按鈕，窗口內的任何內容都不會被保存。異常事件流：
1）提示錯誤信息，二級公司用戶確認。2）返回到管理系統主界面。
后置條件：一條新的車輛報廢記錄被插入到數據庫中并顯示出來。注釋：無。
用例10 用例名稱：刪除車輛報廢申請 用例識別號：3.1.2 參與者：二級公司用戶
簡要說明：二級公司用戶刪除一個車輛報廢申請記錄。
前置條件：二級公司用戶已經登錄車輛管理信息系統、將要被刪除的車輛報廢申請沒有被審批。基本事件流：
1)二級公司用戶單擊選中要刪除的車輛報廢申請記錄。2)二級公司用戶單擊“刪除”按鈕。3)系統出現“提示是否刪除”窗口。
4)二級公司用戶單擊“是”按鈕，該車輛報廢申請記錄就被從數據庫中刪除。5)用例終止。
其它事件流：
在單擊“是”按鈕之前，二級公司用戶可以單擊“否”按鈕，車輛報廢申請記錄不會被刪除。異常件流：
1）提示錯誤信息，二級公司用戶確認。2）返回到管理系統主界面。
后置條件：選中的默認的車輛報廢申請記錄從數據庫中被刪除，同時顯示界面被更新。
注釋：刪除之前，要先使用查詢功能，以便選擇要刪除的內容。
用例11 用例名稱：總工程師報廢申請審批 用例識別號：3.2.1 參與者：總工程師
簡要說明：總工程師對二級公司用戶提交的車輛報廢申請單進行審批。前置條件：總工程師已經登錄車輛管理信息系統、存在未審批的車輛報廢申請。
基本事件流：
1）總工程師單擊選中要審批的車輛報廢申請記錄。2）總工程師單擊“審批”按鈕。3）系統出現編輯窗口。
4）總工程師可以在審批意見文本框上添加或修改審批意見，也可以完全刪除，重新填寫。
5）總工程師選擇“同意”或“不同意”單選按鈕審批結果。
6）總工程師編輯完相應的文本框及選擇完審批結果后，單擊“存盤”按鈕，該車輛報廢申請記錄就被審批，并在數據庫中修改該記錄的審批標志，審批結果和審批意見。7）用例終止。其它事件流：
在單擊“存盤”按鈕之前，總工程師隨時可以單擊“取消”按鈕，審批內容及審批結果都不會被保存。異常事件流：
1）提示錯誤信息，總工程師確認。2）返回到管理系統主界面。
3）后置條件：選中的車輛報廢申請記錄被審批，并在數據庫中修改該記錄的審批標志、審批結果和審批意見。
注釋：審批之前，要先使用查詢功能，查出未審批的車輛報廢申請記錄。
用例12 用例名稱：總經理報廢申請批復 用例識別號：3.3.1 參與者：總經理
簡要說明：總經理對二級公司用戶提交的公司所屬車輛報廢申請進行批復。前置條件：總經理已經登錄車輛管理信息系統、存在滿足如下條件的車輛報廢申請記錄，即：總工程師已審批、總經理未批復的公司所屬車輛報廢申請記錄。基本事件流：
1)總經理單擊選中要審批的車輛報廢申請記錄。2)總經理單擊“審批”按鈕。3)系統出現編輯窗口。
4)總經理可以在審批意見文本框上添加或修改批復意見，也可以完全刪除，重新填寫。
5)總經理選擇“同意”或“不同意”單選按鈕批復結果。
6)總經理編輯完相應的文本框及選擇完批復結果后，單擊“存盤”按鈕，該車輛報廢申請記錄就被批復，并在數據庫中修改該記錄的批復標志，批復結果和批復意見。7)用例終止。其它事件流：
在單擊“存盤”按鈕之前，總工程師隨時可以單擊“取消”按鈕，審批內容及審批結果都不會被保存。異常事件流：
1）提示錯誤信息，總經理確認。2）返回到管理系統主界面。
后置條件：選中的車輛報廢申請記錄被批復，并在數據庫中修改該記錄的批復標志、批復結果和批復意見。
注釋：審批之前，要先使用查詢功能，查處總工程師已審批，總經理未批復的公司所屬車輛報廢申請記錄。
4.4功能活動圖
1、用戶登錄活動圖
2、車輛基本信息管理活動圖
3、車輛購置管理活動圖 4.5狀態圖
1、車輛購置申請單狀態圖
2、車輛基本信息狀態圖
5非功能需求
5.1性能需求
5.1.1時間、界面、響應要求
由于此系統主要用于信息的保管查詢，即對數據的安全性要求極高。為防止對信息資料和管理程序的惡意破壞，及惡意的竊取私人信息，要求有較為可靠的安全性能。另外也需要高速的響應，要求穩定、安全、便捷，易于管理和操作。另外使用者大多為非計算機人員，所以要求界面友善，交互性強。查詢速度：不超過5秒；
其它所有交互功能反應速度：不超過3秒； 可靠性：平均故障間隔時間不低于300小時。信息容量：不低于10G時可能出現系統崩潰。
5.1.2靈活性
當用戶需求，如操作方式，運行環境，結果精度，數據結構與其他軟件接口等發生變化時，設計的軟件要做適當調整,靈活性非常大。
5.2數據管理需求
5.2.1系統數據流圖
車輛購置業務流程圖
車輛調撥業務流程圖 車輛報廢業務流程圖
5.2.2數據整理與保存
應滿足隨時整理的需求，用戶可隨時更改數據，保存數據。對于數據唯一性的識別應放在多個關鍵字之上。
5.2.3數據安全性
數據應具有極高的安全性，為了保護用戶的隱私，仍需設置登陸及密碼保護，以防用戶的信息被人竊取。
5.3故障處理需求
1、內部故障處理: 在開發階段可以隨即修改數據庫里的相應內容。
2、外部故障處理: 24 對編輯的程序進行重裝載時，第一次裝載認為錯，修改。第二次運行，在需求調用時出錯，有錯誤提示，重試。
3、本軟件可能產生的錯誤為數據庫的錯誤信息，應由數據庫管理員對數據庫進行維護。為了確保系統恢復的能力，數據庫管理員要定期對數據庫進行備份。但產品投入使用后，則由維護人員跟進。
第五篇：物流管理系統—需求規格說明書
物流管理系統
需求規格說明書
修訂歷史記錄
日期
版本
說明
作者
2009-X-X
1.0
1引言
1.1編寫目的3
1.2背景
1.2.1背景說明
1.2.2系統名稱定義與目標對象：
1.2.3系統面向的用戶群體
1.3術語定義
1.4參考資料
2業務概述
2.1業務場景和約束
2.1.1概述
2.1.2業務流程
3具體需求
3.1功能性需求
3.1.1功能性需求分類
3.1.2用戶管理
3.1.3車輛管理
3.1.4駕駛員管理
3.1.5運力查詢
3.1.6承運任務管理
3.1.7運輸成本核算
3.2非功能性需求
3.2.1可用性
3.2.2可靠性
3.2.3性能
3.2.4可支持性
3.2.5設計約束
3.2.6安全性
3.2.7用戶界面
3.2.8授權需求
1引言
1.1編寫目的編寫該文檔目的在于明確系統范圍，明確物流管理系統的業務流程，并規范化的記錄該系統的功能需求和非功能性需求。
本文檔主要供以下人員閱讀和使用：
l
為軟件開發團隊，包括項目開發人員和測試人員項目開發參考用
l
其它相關用戶,了解系統的需求范圍和實現目標，目的在于更好的使用系統
1.2背景
1.2.1背景說明
物流管理系統主要為物流公司解決日常辦公和項目管理的需求，協助工作人員進行日常物流管理和人員管理，提高管理效率，降低運作成本，增強企業長期競爭力。
通過該系統，物流公司運輸管理人員能實現對車隊、車輛的動態管理；調度人員能隨時了解車輛動向和使用情況；承運業務員能開出和接收承運單；財務人員也能通過該系統進行運輸成本的核算。
1.2.2系統名稱定義與目標對象：
本案例中系統名為“物流管理系統”，主要供物流公司內部使用。
1.2.3系統面向的用戶群體
系統面向物流公司的工作人員，包括財務人員、運輸管理人員、調度人員、承運業務員
等。
1.2.3.1用戶的特征
用戶大都具備以下特征：
l
有IE使用經驗
l
了解網絡
l
了解辦公自動化
1.2.3.2用戶環境
用戶的計算機環境大致如下：
l
Windows
XP簡體中文版
l
IE瀏覽器
l
MS
Office辦公軟件
l
Outlook或Foxmail郵件管理
1.3術語定義
序號
名
稱
說
明
LMS
物流管理系統
1.4參考資料
序號
文
檔
版本
說
明
《企業物流管理》
2005-1-1
本系統查閱了本書的相關資料
2業務概述
2.1業務場景和約束
2.1.1概述
物流管理系統主要為物流公司解決日常辦公和項目管理的需求，協助工作人員進行日常
物流管理和人員管理，提高管理效率，降低運作成本，增強企業長期競爭力。
通過該系統，物流公司運輸管理人員能實現對車隊、車輛的動態管理；調度人員能隨時了解車輛動向和使用情況；承運業務員能開出和接收承運單；財務人員也能通過該系統進行。
簡單示意圖如下：
2.1.2業務流程
車輛管理模塊：
車輛管理模塊分車隊信息維護和車輛信息維護。在車隊信息維護中，由運輸管理員新增車隊、更新車隊、查詢車隊和刪除車隊。其中，查詢車隊分按車隊編號查詢、按車隊名稱查詢、按車輛柜型查詢、按車輛容積查詢、按車輛狀態查詢。在車輛信息維護中，由運輸管理員新增車輛、更新車輛、查詢車輛和刪除車輛。其中，查詢車輛分按車牌號碼查詢、按車輛類型查詢、按車輛載重查詢、按車輛使用狀態查詢、按車輛所屬車隊查詢、按車輛當前任務查詢、按車輛計劃任務查詢;在新增車輛時，運輸管理員填入車輛詳細信息，并在車隊列表中選擇所屬車隊。
駕駛員管理模塊：
本模塊由運輸管理員新增駕駛員，更新駕駛員，查詢駕駛員及刪除駕駛員。其中，查詢駕駛員分按姓名查詢、按政治面貌查詢、按所屬車隊ID查詢、按狀態查詢。
運力查詢模塊：
本模塊分為運力綜合查詢和歷史承運任務查詢。運力綜合查詢分車隊查詢和車輛查詢。其中，車隊查詢分按車隊狀態查詢、按車隊ID查詢、按車隊名字查詢、按柜型查詢;車輛查詢按車輛狀態查詢、按車牌查詢、按所屬車隊查詢。歷史承運任務分按客戶名稱查詢、按取貨時間查詢、按車牌號碼查詢、按主駕駛員查詢、按交貨地點查詢、按托運單查詢、按預定車型查詢。
承運任務管理模塊：
本模塊分為開出承運單、承運單管理、承運單接收。承運單管理中，分查詢承運單，更新承運單，刪除承運單及承運單派車，其中，承運單查詢分按客戶名稱查詢、按取貨時間查詢、按車牌號碼查詢、按主駕駛員查詢、按交貨地點查詢、按托運單查詢、按預定車型查詢。承運單派車通過選擇未派車承運單并選取車輛。承運單接收中，通過客戶名稱、取貨時間、交貨地點查詢未接收承運單。
車隊運輸成本維護模塊：
本模塊分為查詢承運單、插入成本、修改成本。由財務人員查詢出承運單，并對相應承運單插入成本
用戶管理模塊：
本模塊由注冊用戶、修改用戶、刪除用戶組成。由擁有用戶管理角色人員負責錄入，查詢，修改及刪除用戶。
2.2系統角色分析
綜合客戶的業務流程并進行用戶分析后，可以把用戶分成如下的幾類角色。這樣可以基于這些角色進行系統流程的權限控制，并且這種基于角色的權限管理使業務系統更加靈活可擴展。
角色中文名稱
角色名稱
權限
用戶管理
administrators
用戶管理員,可做用戶相關操作。
車輛管理
transportUsers
可進入用車輛管理功能模塊，功能模塊入口權限。只有擁有此角色的用戶，登錄系統后才能看到左側用車輛管理功能菜單。
運力查詢
carryUsers
可查詢車輛及車隊操作和查詢歷史承運任務
承運任務管理
dispatcher
可執行插入承運單、管理承運單操作
運輸成本核算
FinanceUsers
可執行插入承運任務成本、管理承運任務成本操作
有了上面的角色分析后，我們按照角色進行用例分析如下：
?
用戶管理與角色對應
?
車輛管理與角色對應
?
駕駛管理與角色對應
?
承運單管理與角色對應
?
運力查詢與角色對應
?
運輸成本核算與角色對應
3具體需求
3.1功能性需求
3.1.1功能性需求分類
物流管理系統功能模塊劃分如下表：
功能模塊
子功能
功能細化
1用戶管理
1.1用戶信息維護
1.1.1增加新帳戶
1.1.2查看賬戶
1.1.3刪除賬戶
2車輛管理
2.1車隊信息維護
2.1.1錄入車隊信息
2.1.2修改車隊信息
2.1.3刪除車隊信息
2.1.4查詢車隊信息
2.2車輛信息維護
2.2.1錄入車輛信息
2.2.2修改車輛信息
2.2.3刪除車輛信息
2.2.4查詢車輛信息
3駕駛員管理
3.1駕駛員信息維護
3.1.1錄入駕駛員信息
3.1.2修改駕駛員信息
3.1.3刪除駕駛員信息
3.1.4查詢駕駛員信息
4運力查詢
4.1運力綜合查詢
4.1.1查詢承運車隊
4.1.2查詢承運車輛
4.2歷史承運任務查詢
4.2.1查詢承運單
5承運任務管理
5.1承運單開出
5.1.1開出承運單
5.1.2修改承運單
5.1.3刪除承運單
5.1.4查詢承運單
5.2承運單接收
5.2.1接收承運單
6運輸成本核算
6.1車隊運輸成本維護
6.1.1錄入成本
6.1.2查詢承運任務
6.1.3修改成本
6.2車隊運輸成本核算
6.2.1核算運輸成本
3.1.2用戶管理
在用戶管理功能模塊中，主要是完成公文的起草、審核、審批、發文和歸檔等操作，實現用戶管理的辦公自動化，主要功能見下表：
用戶管理模塊
模塊名稱
功能概述
【用戶管理區】
增加新帳戶
錄入用戶基本信息，選擇用戶角色，完成用戶的創建
查看賬戶
查看用戶基本信息及用戶角色
刪除賬戶
查看用戶基本信息及用戶角色，將一些沒用的用戶進行刪除
如上表所示，功能分為“用戶辦公區”和“系統管理區”等兩個大的部分，主要供系統管理員創建、刪除用戶。
幾個模塊要求實現的功能具體說明如下：
1)
用戶注冊
l
用戶注冊，錄入用戶信息和選擇用戶角色
2)
用戶修改
在“用戶修改”功能中，要求系統顯示已有用戶列表。如果需要刪除某個用戶，需要在用戶列表中選擇刪除。具體實現要求如下：
l
顯示已有用戶信息，包括“用戶名”、“郵箱”等信息
l
在每條用戶信息后，有“刪除”按鈕，點擊“刪除”按鈕后能夠實現刪除操作
3.1.3車輛管理
車輛管理模塊
模塊名稱
功能概述
【用戶辦公區】
錄入車輛信息
運輸管理人員錄入車輛的基本信息，車輛添加
查詢車輛信息
運輸管理人員輸入查詢車輛的條件，查詢車輛信息
錄入車隊信息
運輸管理人員錄入車隊的基本信息，車隊添加
查詢車隊信息
運輸管理人員輸入查詢車隊的條件，查詢車隊信息
修改車隊信息
運輸管理人員將一些錯誤的車隊信息，進行修改
修改車輛信息
運輸管理人員將一些錯誤的車輛信息，進行修改
刪除車隊信息
運輸管理人員將一些已不存在的車隊信息，進行刪除
刪除車輛信息
運輸管理人員將一些已不存在的車輛信息，進行刪除
如上表所示，功能分為“用戶辦公區”和“系統管理區”等兩個大的部分，主要供系統運輸管理錄入、修改、刪除車輛及車隊信息。
幾個模塊要求實現的功能具體說明如下：
1)
錄入車輛信息
l
運輸管理，錄入車輛的基本信息，并提交
2)
查詢車輛信息
在“查詢車輛信息”功能中，要求系統顯示已有車輛列表。如果需要刪除、修改某個車輛信息，需要在車輛列表中選擇刪除、修改。具體實現要求如下：
l
顯示已有車輛信息，包括“車牌號碼”、車輛類型”等信息
l
在每條車輛信息后，有“刪除”按鈕，點擊“刪除”按鈕后能夠實現刪除操作
l
在每條車輛信息后，有“編輯”按鈕，點擊“編輯”按鈕后能夠實現修改操作
4)
錄入車隊信息
l
運輸管理，錄入車隊的基本信息，并提交
5)
查詢車隊信息
在“查詢車隊信息”功能中，要求系統顯示已有車隊列表。如果需要刪除、修改某個車隊信息，需要在車隊列表中選擇刪除、修改。具體實現要求如下：
l
顯示已有車隊信息，包括“車隊編號”、“車隊名稱”等信息
l
在每條車隊信息后，有“刪除”按鈕，點擊“刪除”按鈕后能夠實現刪除操作
l
在每條車隊信息后，有“編輯”按鈕，點擊“編輯”按鈕后能夠實現修改操作
3.1.4駕駛員管理
駕駛員管理模塊
模塊名稱
功能概述
【用戶辦公區】
錄入駕駛員信息
運輸管理人員錄入駕駛員的基本信息，駕駛員添加
查詢駕駛員信息
運輸管理人員輸入查詢駕駛員的條件，查詢駕駛員信息
修改駕駛員信息
運輸管理人員將一些錯誤的駕駛員信息，進行修改
刪除駕駛員信息
運輸管理人員將一些已不存在的駕駛員信息，進行刪除
1)
錄入駕駛員信息
l
運輸管理，錄入駕駛員的基本信息，并提交
2)
查詢駕駛員信息
在“查詢駕駛員信息”功能中，要求系統顯示已有駕駛員列表。如果需要刪除、修改某個駕駛員信息，需要在駕駛員列表中選擇刪除、修改。具體實現要求如下：
l
顯示已有駕駛員信息，包括“姓名”、“性別”等信息
l
在每條駕駛員信息后，有“刪除”按鈕，點擊“刪除”按鈕后能夠實現刪除操作
l
在每條駕駛員信息后，有“編輯”按鈕，點擊“編輯”按鈕后能夠實現修改操作
3.1.5運力查詢
運力查詢模塊
模塊名稱
功能概述
【用戶辦公區】
查詢承運車隊
調度員與承運業務員輸入查詢車隊的條件，查詢車隊基本信息
查詢承運車輛
調度員與承運業務員輸入查詢車輛的條件，查詢車輛基本信息
查詢承運單
調度員與承運業務員輸入查詢承運單的條件，查詢已完成的承運單基本信息
1)
查詢承運車隊信息
在“查詢承運車隊信息”功能中，要求系統顯示已有承運車隊列表。如果需要查詢特定條件的車隊信息，可輸入條件查詢。
l
顯示已有車隊信息，包括“車隊編號”、“車隊名稱”等信息
2)
查詢承運車輛信息
在“查詢承運車輛信息”功能中，要求系統顯示已有承運車輛列表。如果需要查詢特定條件的車輛信息，可輸入條件查詢。
l
顯示已有車輛信息，包括“車牌號碼”、“車輛類型”等信息
3)
查詢承運單
在“查詢承運單”功能中，要求系統顯示已有承運單列表。如果需要查詢特定條件的承運單信息，可輸入條件查詢。
l
顯示已有承運單信息，包括“托運單號”、“貨物名稱”等信息
3.1.6承運任務管理
承運任務管理模塊
模塊名稱
功能概述
【用戶辦公區】
開出承運單
承運業務員錄入承運單的基本信息，并提交，開出承運單
查詢承運單
承運業務員輸入查詢承運單的條件，查詢承運單
接收承運單
承運業務員接收未接收的承運單
修改承運單
承運業務員在承運列表中選擇要修改的承運單號，對承運單進行修改
刪除承運單
承運業務員人員將一些不接收的承運單，進行刪除
1)
錄入承運單信息
l
承運業務員，錄入承運單的基本信息，并提交
2)
接收承運單
l
承運業務員，可在承運單列表中選擇要接收的承運單，點擊“接收”按鈕
3)
查詢承運單信息
在“查詢承運單信息”功能中，要求系統顯示已有承運單列表并可通過條件查詢。如果需要刪除、修改某個承運單信息，需要在承運單列表中選擇刪除、修改。具體實現要求如下：
l
顯示已有承運單信息，包括“托運單號”、“貨物名稱”等信息
l
在每條承運單信息后，有“刪除”按鈕，點擊“刪除”按鈕后能夠實現刪除操作
l
在每條承運單信息后，點擊“托運單號”后能夠實現修改操作
3.1.7運輸成本核算
承運任務管理模塊
模塊名稱
功能概述
【用戶辦公區】
錄入成本
財務人員為承運單錄入成本
查詢承運任務
財務人員輸入條件查詢承運單任務
核算運輸成本
財務人員通過選擇承運單列表中的成本ID查看成本核算
1)
錄入成本信息
l
承運業務員，錄入成本的基本信息，并提交
2）查詢承運任務
在“承運單查詢”功能中，要求系統顯示已有用戶列表并可根據條件查詢。具體實現要求如下：
l
顯示已有承運信息，包括“托運單號”、“貨物名稱”等信息
3）核算運輸成本
l
財務人員可在承運單列表中選擇要添加的成本的承運單，在點擊“插入成本”
l
財務人員可在承運單列表中選擇已插入成本的承運單的成本ID查看成本核算
3.2非功能性需求
3.2.1可用性
由于本系統面向非專業的IT辦公人員，因此要求系統符合一般的物流管理系統操作方式，每個操作步驟都有詳細的操作說明或者提示，指引用戶完成承運任務，要求簡單、易用。
3.2.2可靠性
1、系統每天至少保持23小時30分的可用時間，每天凌晨3：30到4：00之間進行日常系統維護工作，如數據傳輸，交換等。
2、臨時系統停機時間，每月合計必須小于3小時。
3.2.3性能
在多個并發用戶更新同一賬戶信息時，第一個可以成功更新。隨后的更新在提交之前，顯示錯誤信息“用戶數據已經更改，是否需要刷新用戶數據？”。
3.2.4可支持性
系統提供如下兩種瀏覽器兼容支持：
Microsoft
Internet
Explorer
6.0及其以上版本；
Netscape
Navigator
6.0及其以上版本。
3.2.5設計約束
1、遵循《C#編碼規范》
2、ASP.NET
2.03、SQL
Server20054、Microsoft
Visual
Studio20055、IIS5.0或以上版本
3.2.6安全性
安全性需求通常分為六類：
1、對于重要數據（比如用戶密碼）進行了不可逆加密，防止泄露。
2、在與數據庫交互中，不使用SQL拼接方式，全部使用傳參方式，有效杜絕了SQL注入。
3、用戶認證需求：闡述系統表示用戶和用戶認證的方法。
4、授權：如果認證成功，根據用戶的級別，允許其執行不同的系統功能。
5、數據完整性和隱私需求：
確保數據完整，不會影響系統安全。
6、事務完整性和審計需求：確保用戶無法清除自己的在系統中的活動。記錄活動相
關的數據，使得系統管理員可以發現所有可能的危險行為。
3.2.7用戶界面
符合物流管理公司人員的使用習慣，界面以簡潔大方為主，適合有IE使用經驗及了解網絡的辦公人員使用。
3.2.8授權需求
系統必須實現一定的頁面訪問限制。用戶只能訪問自己有權限操作的頁面（具體可操作的部分詳見系統的功能性需求中各模塊的用例）。
文檔內容僅供參考
點擊咨詢 