第一篇：電子商務系統(java)需求分析說明書

電子商務系統需求分析說明書

一． 引言...............................................................................................................................................1 1.編寫目的............................................................................................................................................1 2.背景..................................................................................................................................................1 3.定義..................................................................................................................................................1 二． 任務概述.......................................................................................................................................2 1．目標.................................................................................................................................................2 2.用戶的特點......................................................................................................................................2 3.系統功能示例..................................................................................................................................2 三． 需求細則.......................................................................................................................................2 1.對功能的規定...............................................................................................................................2 2.對性能的規定...............................................................................................................................5 3.對排版的規定...............................................................................................................................5 4.對可維護性的規定........................................................................................................................5 5.對個性的規定...............................................................................................................................6 6.對項目過程的規定........................................................................................................................6

一． 引言

1.編寫目的

通過與多位軟件使用者進行全面深入地探討和分析，并完成《電子商務系統》市場的前期調查后，提出了這份軟件需求分析說明書。

此需求分析說明書對《電子商務系統》軟件做了全面細致的用戶需求分析，明確所要開發的系統應具有的功能、性能與界面，使系統分析人員及軟件開發人員能清楚地了解用戶的需求，并在此基礎上進一步提出概要設計說明書和完成后續設計與開發工作。

本說明書的預期讀者為客戶、業務或需求分析人員、測試人員、用戶文檔編寫者、項目管理人員。

2.背景 3.定義

二． 任務概述 1．目標 2.用戶的特點 3.系統功能示例

需求：

1、購物車管理

購物車內商品的增、刪、改 生成訂單

2、訂單管理

訂單的增、刪、查

3、使用數據庫（mysql）保存用戶信息、商品信息、訂單信息 用戶表，商品表，訂單表，訂單項表

技術要求：

1、商品類

2、購物車類

3、購物項類

4、訂單類

5、訂單項類

6、用戶類

7、應用MVC模式

購物流程：

用戶登錄，瀏覽商品頁面，挑選商品加入購物車，繼續瀏覽商品頁面…… 購物車頁面顯示當前所購商品信息（名稱、數量、價格），提交生成訂單，保存到數據庫中（訂單表存儲訂單基本信息：訂單號、用戶名、訂單總價、生成時間

訂單項表存放各訂單詳細訂單項信息：所屬訂單號、商品號、數量）

三． 需求細則 1.對功能的規定

分必選項和任選項，其中，必選項是必須完成的，屬于項目答辯的入口條件，所有人都要做，未完成者取消答辯資格；任選項不是入口條件，但每完成一項都會加分，對于完成了必選項的同學，盡可能地多完成一些任選項，以期獲得更高的答辯成績。如果所有項（包括必選和任選）都完成，那么功能分就是滿分。如果設計思路、界面效果、代碼組織等方面有個性（或和別人的不同），則獲得附加分。

1.1 注冊、登錄功能

屬性：必選

描述：用戶必須注冊，登錄之后才能使用本電子商務系統

1.2 商品瀏覽功能

1.2.1 商品類定義 屬性：必選

描述：商品信息必須包含如下項（包括但不限于）：

● ID：要求全局唯一

● 商品名稱（字符串）● 商品單價 ● 商品庫存 ● 商品類別

1.2.2 用戶類定義 屬性：必選

描述：用戶信息必須包含如下項：

● 用戶ID：要求全局唯一 ● 用戶密碼 ● 用戶名

● 用戶送貨地址 ● 用戶郵箱 ● 用戶等級

1.2.3 瀏覽商品 屬性：必選

描述：用戶登陸以后能夠按類別瀏覽商品信息。

1.2.4 數據庫保存商品和用戶信息 屬性：必選

描述：商品信息（用戶信息）能夠存于數據庫中，掉電后信息不丟失。必須完成下面兩種情況：

在數據庫中，以表的形式存放商品和用戶信息。

1.3 購物車功能 1.3.1 購物車類 屬性：必選

描述：購物車類必須包含如下項（包括但不限于）：

● 購物項集合（購物項類類型）

● 購物總額

1.3.2 購物車功能實現 屬性：必選 描述：增刪改查。

● 添加購買商品 ● 修改購買商品數量 ● 刪除購物項 ● 顯示購物車內容

● 計算購物車內商品總價（考慮用戶等級折扣）

1.3.3 購物項類 屬性：必選

描述：購物項類必須包含如下項（包括但不限于）：

● 商品ID

● 購買數量

1.3.4 通過購物車下訂單 屬性：必選

描述：根據購物車內購物項集合下訂單，生成訂單內容信息必須保存在數據庫中

1.4 訂單處理功能 1.4.1 訂單類定義 屬性：必選

描述：訂單信息必須包含如下項（包括但不限于）：

● ID：要求全局唯一

● 訂單明細集合（訂單明細項類型）● 訂單總額 ● 下單用戶ID ● 下單時間

● 訂單狀態（提交、審核、等待付款、發貨、完成）

1.4.2 訂單明細項類定義 屬性：必選

描述：訂單明細信息必須包含如下項（包括但不限于）：

● 商品ID

● 購買數量 ● 訂單ID

1.5 數據庫功能 屬性：必選

1.5.1 用戶信息表 1.5.2 商品信息表 1.5.3 訂單信息表

1.5.4 訂單明細項信息表

1.6 商品評價

屬性：任選

描述：購買過某商品的用戶可以對該商品進行評價，評價內容保存在數據庫中，用戶瀏覽商品時可以查看評價信息

1.7 管理員后臺管理模塊

屬性：任選

描述：管理員登錄系統，查看商品庫存，查看用戶訂單，進貨處理，訂單狀態管理

2.對性能的規定

本系統在設計方面本著方便、實用的宗旨，性能方面應遵循如下原則： ● 執行效率（時間）： 軟件運行應該盡量高效；避免沒有必要的循環處理、重復處理； ● 資源損耗（空間）：設計盡量節約資源（內存、數組、鏈表等）； ● 初始化： 局部變量、數組成員、內存塊等都要初始化； ● 健壯性：

◎ 申請內存之后，應該立即檢查引用值是否為null； ◎ 方法的入參必選進行有效性判斷；

◎ switch-case一定要有default；if-else if等后要有else； ◎ 數組的下標不要發生“多1”或者“少1”操作。

3.對排版的規定

● 縮進要對齊； ● 長行拆分；

● 二元操作符的前后應當加空格，包括如下操作符：

賦值操作符、比較操作符、算術操作符、邏輯操作符、位域操作符，如“=”、“+=” “>=”、“<=”、“+”、“*”、“%”、“&&”、“||”、“<<”, “^” 等；

● 空行：

◎ 類聲明之后、每個方法定義結束之后都要加2行空行；

◎ 邏輯上密切相關的語句之間不加空行，其它地方應加空行分隔； ◎ 一行代碼只做一件事情；

◎ “if”、“for”、“while”、“do”等語句自占一行，執行語句不得緊跟其后。不論執行語句有多少都要加 “{ }”；

4.對可維護性的規定

對可維護性的最終要求：別人能夠輕松上手你的代碼。

● 結構清晰：

◎ 模塊化：對界面（顯示）、菜單管理、邏輯管理、文件操作等等代碼要獨立； ◎ 封裝：一個模塊只做一件事，模塊功能要單一；一個方法不能超過50行；

避免重復、冗余代碼； ◎ 代碼塊清晰。

● 變量命名規范，變量名應該具有自明性：

◎ 常量定義命名

常量名由全大寫字母組成，單詞間通過下劃線來界定； ◎ 方法的命名：

使用“動詞”或者“動詞＋名詞”（動賓詞組）的形式，由一個或多個單詞組成且以小寫字母開頭，以后每個單詞的首字母要大寫便于界定 ◎ 變量的命名與定義

應當使用“名詞”或者“形容詞＋名詞”，由一個或多個單詞組成且以小寫字母開頭，以后每個單詞的首字母要大寫便于界定。

● 注釋充分：變量、方法（包括參數、返回值）、代碼功能塊、一些復雜算法??等都需要

清晰明了地說明；

5.對個性的規定

把項目做出個性出來。下列各項中有和比人不同之處、或很有創意，即可認為有個性。獨立設計的軟件，一般都會出現一些個性。參考、抄襲不會出現個性。

● 設計思路：包括軟件的整體架構、功能塊的設計思路、類封裝等等； ● 功能實現：從用戶的角度，使用上發現與眾不同的地方； ● 其它方面；

6.對項目過程的規定

本著緊張但不急躁、不參考、不拷貝的原則進行。? 緊張但不慌張

項目周期只有一周，這還包括項目答辯時間。所以項目時間比較緊張，但不能慌張。要有自己明確的設計思路，一步步沿著思路走下去，以此來鞏固自己所學，鍛煉自己的獨立工作能力。? 能自己做，絕不參考別人

自己還沒有做，還沒有想，就去看比人的，這樣盡管功能做出來了，但卻沒有什么意義，真正面試時還是不會。作者和讀者，天壤之別。

如果自己實在無法搞定，一個問題卡了快一天了，則可以咨詢別人一下想法，再行編碼；盡量不直接看別人代碼。? 不拷貝

一旦發現拷貝，取消答辯資格。答辯時發現，答辯成績減半。

copy別人的代碼，甚至直接運行別人的代碼，以此作為自己的項目進展，這是嚴禁的。嚴禁運行效果出來了，卻不知道是哪些代碼造成的，嚴禁明明是自己寫的代碼，但卻不知道為什么這么寫。

第二篇：教師工資管理系統需求分析說明書

學校內部工資管理系統

需求分析報告

系統分析員：張倩、施婷婷、毛思雨、吳園希、陳金淼

日期：2011-5-3

1、目導言

1.1 目的

為工資管理系統提供一套具有基本功能的模擬軟件支持系統提供基本的需求分析和描述，為軟件的開發參與者（系統設計人員、程序員、測試人員、開發商、管理人員等）提供完整的需求信息。

1.2 范圍

本軟件適用于我校工資系統的管理和應用，它是完善、安全、穩定的系統管理模擬軟件。待開發軟件系統的名稱：基于Web應用的學校教師工資管理系統

本產品能具體化、合理化、安全的模擬實現基于Web應用的工資管理系統的各種基本操作。

2、系統定義

2.1 項目來源及背景

本系統是一個學校內部工資管理系統。對教職員工的基本信息和工資信息進行添加和修改，能夠調整工資項目，根據需要對教職員工基本信息和工資信息的查詢，本系統能夠生成各個月的工資表，能夠打印報表方便保存和管理，還包括對系統的一些基本操作功能，比如為完善系統管理功能，增加工資系統用戶管理功能，系統應該包括系統用戶數據的添加，修改和刪除。教職員工為系統普通用戶，只能運行系統個人工資查詢功能；系統管理員則能運行系統所有功能，從而有效保證系統數據的安全性，系統應該具有簡單，易用，小巧，經典的特色，應該能夠對高校工資管理進行優化，使其系統化，高效化，智能化。并保證工資管理的準確性，簡易性，為學校財務人員提供便利。

2.2 用戶的特點

本系統的用戶主要有以下幾類：

教職工：提交各人信息和查詢總工資表；

財務處：查詢總工資表，生成正確的工作表，生成各教職工工資條； 人事處：提交人員變動情況，制定獎懲實施細則，生成可變工資； 學校各部門：提交出勤情況，提交業績情況，讀取工資條。

本軟件的使用對象是我校全體教職員工,必須通過IE瀏覽器訪問該系統，然后再登陸頁面輸入正確的用戶明和密碼方可使用（即成功登陸）。

3、功能規格

3.1 角色定義

角色或者執行者指與系統產生交互的外部用戶或者外部系統。

3.1.1 教職工

學校教職工通過系統可以實現以下使用需求：提交個人信息，登陸修改個人信息，查詢個人工資各項詳情。

3.1.2 財務處

學校財務處可以通過系統實現以下需求：讀取工資表，生成正確工資表及查詢工資情況。

3.1.3 人事處

學校人事處可以通過系統實現以下使用需求：輸入教職工調動信息，讀取教職工出勤及業績情況，制定獎懲實施細則，生成教職工出勤工資、獎金及扣款清單。

3.1.4 學校各部門

學校各部門可以通過系統實現以下使用需求：給出教職工出勤情況，給出教職工業績考核情況，讀取各部門匯總表，得到工資條。

3.1.5 數據庫數據庫是一個與系統產生交互的外部系統，這個角色負責系統的數據查詢、增加、刪除、和修改等操作。

3.1.6 學校人事處

在學校教師工資管理系統中，管理員可以提交人員變動，提交可變工資（統計出勤工資、獎金及扣款項目），制定獎懲明細，查詢工資表。具體描述如下。

用例描述：學校人事處管理； 執行者：學校人事處；

前置條件：人事處管理者已登錄系統；

后置條件上：如果人員和工資產生變化，則數據庫中的隨之變化。基本路徑：

登錄成功，進入管理界面。

然后根據選擇不同的操作分別進入不同狀態，如：選擇提交人員變動，可以對員工調入、調出、校內調動、離退休等數據進行修改，進入的狀態為一個系統

反饋的信息表。若選擇提交可變工資，則會再次給出選擇分別進入狀態為：出勤工資表，獎金表后者扣款清單表。

根據相應選擇查詢不同信息。查看信息完畢后，最后退出系統。

在學校教師工資管理系統中，財務處管理員可以查詢工資表，然后每月月底將教職工的工資表做好并將數據送往銀行。每月初（3日前）將工資條發給各單位。具體描述如下。

4、性能需求

4.1 界面需求

1.以通信功能作為界面設計的核心

人機界面設計的關鍵是使人與計算機之間能夠準確地交流信息。一方面，人向計算機輸入信息時應當盡量采取自然的方式；另一方面，計算機向人傳遞的信息必須準確，不致引起誤解或混亂。

2.界面必須始終一致

統一的人機界面不致于會增加用戶的負擔，讓用戶始終用同一種方式思考與操作。最忌諱的是每換一個屏幕用戶就要換一套操作命令與操作方法。

3.界面友好、使用方便

4.2 響應時間需求

系統能設置登錄等級，對于使用服務器端工作者可以先行響應；

4.3 開放性需求

一個優秀的軟件應該提供在線求助功能，甚至提供使用向導，這將給用戶帶來極大的方便。在多媒體環境下，以語音提示作為操作向導，不會干擾屏幕信息，是一個極佳的選擇。

4.4 可擴展安全性需求

系統對要提供與讀取信息的用戶進行身份驗證，登錄后各員工只能可以看到各自工資詳情；

第三篇：《社團管理系統》需求分析說明書

系統的前臺瀏覽功能需求

(一)游客的功能

(1)注冊成為會員

(2)信息查看,包括公告信息,和各協會活動的情況,照片,視頻和文章等

(3)可在交流區瀏覽帖子

(4)可以留言提出意見或建議

(二)協會會員的功能

(1)會員登錄

會員使用自己注冊的用戶名和密碼登錄

(2)站內信

有任何活動的發起給改協會成員發送站內信，會員有任何疑問也可以通過站內信進行交流

(3)留言

可以留言提出意見或建議

(4)加入新協會

每個會員都可以加入一到三個協會

(5)查看活動歷史

協會成員可以查看歷史活動，包括協會活動的所有有關的文檔

(6)信息查看

協會認為介紹主要介紹會長和副會長

(7)交流區

協會會員可以發表主題，并可以回復評論

(8)上傳,下載

協會會員可以上傳下載圖片和視頻

(9)新協會申請

會員可以申請注冊新協會

(10)協會注冊

協會根據規定進行學期注冊

(三)協會會長功能

(1)協會會長包括協會會員的所以功能

(2)會員管理

會長可以進行協會會員的添加刪除查詢等

(3)申請活動

申請活動必須填寫活動申請單

(4)填寫海報單

為每次活動出海報填寫海報單

(5)活動通知

活動審批通過后,系統自動通知協會會員有

(6)活動評分

每次活動會長都必須給自己組織的活動進行 評分

(7)系統設置

會長可以對自己協會頁面的相關內容進行設置

(8)飛信功能子系統

為確保活動通知到位,設置的附加功能

(9)協會換名

協會換名必須填寫換名申請單

(10)協會外請教師申請

申請外教必須填寫外請教室申請單

(11)十佳學生社團申請

十佳學生社團申請須填寫廈門理工學院十佳學生社團創建申報表

(12)外出活動申請

外出活動需填寫外出活動申請表

(13)周末文化大舞臺

周末文化大舞臺分單項節目申請表，專場活動項目申請表

系統的后臺管理需求

一.社團部管理

（一）部長功能

(1)部長審核新協會的申請：

部長對新協會申請的條件進行審核，審核通過后提交給社團部老師審核。

(2)部長對協會注冊的審核：

各協會每學期需進行注冊，部長對協會的注冊條件進行審核，審核通過后提交給社團部老師審核。

(3)審批社團外請教師：

協會會長填寫“社團外請教師申請表”后，提交給部長，由部長對具體內容進行審核。

(4)部長對工作時間的設置：

對整個社團部的工作，進行時間的控制，如：

1、活動必須在周幾之前提交申請，2、由部長必須在周幾審批活動，然后提交社團社團老師，3、再由社團部老師必須在周幾進行審批，超出規定的時間，將不能進行活動申請。

(5)審批活動申請：

對協會申請的活動進行審核，主要對活動申請表事項的審核，活動預算經費重點關注，應填寫詳細,包括宣傳經費等。

(6)審核活動質量匯報單、并評分：

會長審核完后，匯報單提交給部長，再由部長進行審核，主要針對各協會秘書、秘書組長、會長的意見內容。

提交前，并對此次活動進行評分，總分10，對應欄位后面有個下拉列表框，可選擇分數。

(7)協會分類管理：

部長可根據協會的定義，對協會原本類型進行修改，也可添加新類型、刪除類型。

(8)協會分級管理：

部長可根據協會的學年來的表現、活動總分數，對協會級別進行評定后錄入，并可進行修改，也可添加新級別、刪除級別。

(9)協會風采挑選：

部長可進步各協會界面，對所上傳的活動照片進行挑選后，關聯發布到社團部首頁的社團風采展示區。

(10)審批學生社團換名：

協會會長填寫換名申請表格，提交給部長，部長根據情況進行審批。

(11)協會解散、恢復審核：

部長對不符合協會條件的，可進行解散功能、恢復功能。

(12)部門管理與干事考評：

對各部們成員、協會會長（包括副會長）的管理：包括人員的錄入、修改、刪除； 期末總結：對副部、各組長、各協會會長進行綜合考核評語、評分；

對所有人考核完后，提交給社團部老師審批。

(13)各組干事的考核審評

各組組長對各組干事進行考核后的評語、評分提交給部長后，讓部長進行審批。

(14)站內信：

進行通知交流功能，可接收社團內部通知和活動通知，也可給社團內部所有成員發布信息。

(15)飛信功能子系統：

在對應的賬號里，嵌入飛信功能模塊，方便部長在一些工作上采用短信息通知，如：召開例會時間通知等。

（二）秘書組功能

(1)隨機指派秘書跟蹤協會活動（秘書組長的功能）：

每個協會的每次協會活動，由秘書組長隨機指派2個秘書去跟蹤協會活動；

(2)填寫質量匯報單、并評分：（各協會秘書）

由分派的的協會秘書，在活動過后進行填寫質量匯報單，填寫完后，點擊“提交按鈕”，提交給宣傳組長。

(3)審核質量匯報單、并評分：（秘書組長）

各協會秘書將提交質量匯報單給秘書組長后，秘書組長對質量匯報單進行審核。

(4)秘書組干事考核：

對本組成員的管理，包括人員的錄入、修改、刪除；

期末總結對每個干事進行綜合考核評語、評分；

對所有人考核完后，提交給部長審批。

（三）宣傳組功能

(1)指派宣傳成員出海報（宣傳書組長的功能）：

每個協會的每次活動，提交海報單以后，由宣傳組長指派成員去海報；

需設置成員與相應協會關聯。

(2)審核海報：（宣傳組成員）

對分配到的海報任務進行審核收集、修改。

(3)秘書組干事考核：

對本組成員的管理，包括人員的錄入、修改、刪除；

期末總結對每個干事進行綜合考核評語、評分；

對所有人考核完后，提交給部長審批。

（四）外聯組功能

(1)審核贊助事項：

如協會申請的活動需要經費贊助，在提交《活動申請書》時，需同時附加《活動贊助策劃書》，方便外聯組長對申請進行審核。

(2)贊助商信息發布：

如果通過審核的活動，將活動策劃書發布到網站上，方便贊助商瀏覽；

同時如果有贊助商想進行贊助，可聯系外聯組長或者部長。

(3)外聯組干事考核：

對本組成員的管理，包括人員的錄入、修改、刪除；

期末總結對每個干事進行綜合考核評語、評分；

對所有人考核完后，提交給部長審批。

（五）辦公室功能

(1)打印活動總單（社團留檔管理）：

打印內容包括：活動申請單、活動質量匯報單、活動總結（從活動申請到活動結束整個過程文檔）

(2)例會內容填寫：

對每周的例會，進行記錄整理后，上傳到網站上，方便工作人員瀏覽。

(3)辦公室干事管理與考核：（關系期末加分）

對本組成員的管理，包括人員的錄入、修改、刪除；

期末總結對每個干事進行綜合考核評語、評分；

對所有人考核完后，提交給部長審批。

(4)飛信功能子系統：

在對應的賬號里，嵌入飛信功能模塊，方便辦公室在一些工作上采用短信息通知，如：召開例會時間通知等。

(5)注意事項提醒：

系統自動檢測部長、社團部老師、宣傳組長、秘書組長、外聯組長（下稱工作人員）未登錄時間；

在規定的時間內未登錄，則發送站內信給辦公室成員；

檢測各工作人員賬號的站內信狀態，如果有信息，則用飛信自動通知，否則不通知； 飛信自動通知后，返回發送提示，如果未發送成功，則辦公室人員手動通知。

(6)通知各協會、宣傳組活動教室地點：

(7)收集各部門人員名單，分類收集：

（六）網絡部功能

(1)社團網站維護后臺子系統（對應頁面管理內容+附加內容）：

(2)頁面風格設置：

(3)校園音樂廣播：

(4)網絡部干事考核：

二.教師管理

1、社團部老師

(1)站內信：

進行通知交流功能，可接收社團內部通知和活動通知，也可給社團內部所有成員發送信息。

（2）審核新協會申請：

部長對新協會申請的條件進行審核，審核通過后提交給社團部老師，再由老師進行審核。

（3）審批協會注冊：

各協會每學期需進行注冊，部長對協會的注冊條件進行審核，審核通過后提交給社團部老師審核。

（4）審批活動申請：

部長對協會申請的活動進行審核通過后，提交到老師這邊，再由老師審核。

（5）審批社團外請教師：

協會會長填寫“社團外請教師申請表”后，提交給部長，由部長對具體內容進行審核。

（6）審批學生社團換名：

部長根據協會會長填寫換名申請表格，審批通過后，由老師再次進行審批。

（7）審核質量匯報單，并評分：

由部長進行審核后，提交給老師進行審核，（8）社團成員查詢：

可查看社團部各部門名單及相應職位，與各協會成員名單及相應職位，但不能進行修改等操作，此功能由社團部工作人員進行操作。

（9）社團部門組織管理：

可對社團內各部門進行增、刪、改，方便今后社團的組織結構變化。

（10）協會解散、恢復審核：

不符合協會條件的，部長審核后，提交給老師再次進行審核，可進行解散功能、恢復功能。

（11）部門干事考核審評：

通過部長將部門干事的審評后的結果提交給老師，讓老師進行再次審評：

老師審評對象：部長、副部長、各部們組長、協會會長（包括副會長）；

審評內容：進行綜合考核評語、評分；

對所有人考核完后，提交給社團相應成員。

2、團委書記

審批外出活動：

第四篇：車隊管理系統需求分析說明書

車隊管理系統需求分析書 基本檔案

1.1 公司信息管理

名稱、營業范圍、聯絡方式、其他

1.2 車輛信息

? 車輛基本信息

車輛資料的添加、修改、刪除、導出、打印：記錄車輛的基本信息，包括車輛編號、車牌號碼、發動機編號、車輛顏色、車輛類型、載客數量、營運種類、營運證編號、所屬公司、部門、車隊（組）、備注其他。? 車輛購買信息

廠牌型號、出廠日期、購買店家、購買日期、購入價格、購置稅及其他費用。

1.3 司機信息

? 司機基本信息

編號、姓名、性別、出生年月、家庭電話、移動電話、住址、駕駛證號、準駕車型、駕駛證核發日期、發證機關、駕駛證有限期、就職時間等 ? 司機違章信息

時間、地點、描述、其他。

1.4 人車配屬關系

車與駕駛員的關聯關系，一輛車對應1或多位駕駛員。

1.5 站點管理

行車站點資料維護、統計查詢

1.6 線路管理

行車路線統計維護，查詢

1.7 電子圍欄設置

設置電子圍欄相關信息

? 行駛范圍：車輛有規定的營運范圍；

? 電子圍欄：把行駛范圍轉換成電子圍欄，支持矩形、圓形等區域

1.8 其他

用戶、車隊、組織、部門、權限管理等。車輛監控

Inhand GPS可以為我們提供經度、緯度、速度、航向四個參數。

基于GPS，我們可以實現的主要功能：車輛定位、車輛實時軌跡、車輛行駛里程（obd）、歷史路線、數據分析報表等。

注：以下截圖中有些參數需要obd上傳，可以不用考慮。

2.1 車輛定位

某車某時在某地。

2.2 車輛實時監控

車輛實時位置、速度、航向、及其他車輛參數。

2.3 歷史路線

隨時清查指定車輛某時段運行狀態的詳細運行軌跡線圖以及軌跡回放。

2.4 軌跡明細

列表顯示過去某天某車輛狀態，包括車輛信息、位置、回傳時間、當前速度（回傳時）、方向等。運營管理

3.1 司機與車輛調度

司機考勤、身份識別

3.2 車輛年檢

年檢記錄、年檢提醒

3.3 加油管理

外地加油、定點加油、內部加油站管理。加油的日期、車輛、油量、費用等。

3.4 維修管理

維修申請、審批、維修記錄

3.5 保險管理

保險記錄 保險提醒

3.6 保養管理

保養記錄（申請、審批）保養提醒

3.7 安全管理

車輛事故記錄、駕駛員違章記錄等

3.8 預警提醒

車輛年檢到期提醒 車輛保險提醒

車輛保養提醒 車輛超速提醒 車輛越界提醒

3.9 費用管理

行車費用管理、加油費用管理、維修費用管理、保險費用管理、年檢費用管理、其它費用管理

3.10 其他方向

1、培訓以及培訓資質相關

2、CRM（客戶關系管理）相關

客戶管理、合同管理等

3、供應商相關

供應商記錄、供應商合同、供應訂單、零售件（輪胎）等

4、汽車租賃業務 統計報表

4.1 位置報表

? 疲勞駕駛統計：車輛持續運行2、4、6以及其他判定為疲勞駕駛等。

疲勞駕駛明細表、疲勞駕駛日報表、疲勞駕駛月報表。

? 停車統計報表：可隨時查找某車輛在任一時間段內的停車時間和停車地點，并可生成報表。

? 停靠超時統計：車輛停靠某位置超過指定時間，則判定為停靠超時。

? 里程統計： 根據行駛路線，統計當日里程和月里程，同時支持數據報表導出、打印、其他。

? 車輛利用率：車輛是否到達某一站點。

里程、油耗都是通過obd上報，里程如果根據GPS計算，不確定是否可以計算，計算結果是否精確。

車輛運行狀態（ACC）也是obd連接車載電腦獲取狀態碼來判定行駛還是熄火。通過gps的速度區分，獲取到的數據都不精確。

以上功能報表勉強沾邊。

? 超速、時速統計：車輛管理系統自動統計出某段時間時速排名。? 偏離航向統計：統計某些車輛沒有按照固定軌跡運行。

可以將該部分報表劃分到報表管理模塊

4.2 運營報表

? ? ? ? ? ? ? ? ? 綜合費用統計 車輛保險信息統計 車輛年檢信息統計 車輛事故信息統計 行車信息統計 車輛維修信息統計 其他費用信息統計 車輛檔案查詢 駕駛員檔案查詢等

第五篇：學生公寓管理系統需求分析說明書

學生公寓管理系統需求概況

在學校面向現代化、面向世界、面向未來、面向互聯網的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）學生住宿情況臺賬(按指定區間)