序論：寫作是一種深度的自我表達。它要求我們深入探索自己的思想和情感，挖掘那些隱藏在內心深處的真相，好投稿為您帶來了七篇管理系統需求范文，愿它們成為您寫作過程中的靈感催化劑，助力您的創作。

篇(1)

當前許多承擔基礎設施建設等大型項目的投融資平臺由于業務性質特殊，缺少通用軟件支持，長時間處于手工填寫報表的工作狀態，本文針對投融資平臺公司的建設投資業務，進行了計算機信息化管理系統的需求分析，為后續的設計開發奠定基礎。

【關鍵詞】

投融資平臺；投資管理系統；需求分析

1前言

浦發集團是一家國有獨資有限責任公司，負責上海浦東新區城市基礎設施項目的投融資建設等業務。其本身并不參與具體的工程建設業務，通過為項目提供資金支持來跟蹤，管理大量建設項目的運行。本文在用戶調研的基礎上，遵循需求分析的流程［1］，通過應用結構化和快速原型等分析方法［2］，得到《浦發集團基礎設施項目投資管理系統》的需求文檔。

2功能需求

浦發集團的基礎項目投資方式主要有兩種，一種是BT模式，也就是建成后移交模式。一種是BOT模式，也就是建設，運營一段時間后再移交的模式。項目主要是政府部門提出的公共建設項目，如軌道交通，道路，公交，公共綠地等。政府職能部門，如建交委，環保局等是項目的最終接收方，但他們本身并不參與項目建設，而是委托給浦發集團這樣的投融資平臺公司進行操作。而浦發集團本身也不進行實際項目的建設，他們通過招標將實際的建設工作交給專業的代建公司來完成，本身只完成對項目資金流的管控工作。所以業務涉及跨企業合作，一個是具體建設的代建公司，他們主要根據項目的建設進展情況提出資金使用需求。一個是浦發集團公司，他們主要負責項目資金的募集，審核，撥付。系統以立項的建設項目為核心，由代建公司根據項目進展提出資金申請，集團公司多個部門進行審核，通過后付款給代建公司。系統有兩類用戶，代建公司和集團公司，有三大主要功能，建設項目管理，資金管理以及回購管理。其中，建設項目管理主要是把各種項目信息管理起來，使得業務中各相關方都能方便地檢索到需要的項目信息，從而為處理申請和審核業務提供依據。項目信息包括三大類，項目基本信息，相關合同信息以及與該項目有關的合同外費用支出信息，也就是項目相關的非合同信息。項目信息的創建者是代建公司的工作人員，該信息將由集團公司市政部的相關工作人員來做復核，復核通過后即可作為后續資金申請的依據。這里的項目信息除了項目名稱，關聯公司等最簡單的基本信息外，就是與項目相關的費用預算，支付條件等和資金相關的信息，體現了本系統的圍繞著資金流進行項目管控的特色。而資金管理資金管理是核心業務，主要包括資金計劃，資金申請和審核，以及審核通過后的資金撥付三方面功能。資金計劃是代建公司根據正在進行中的項目情況，制定出各個項目的月度及年度資金使用計劃。資金計劃的目的是預估未來的資金需求量，集團公司的投資金融部會匯總各個代建公司的資金計劃，以此為依據，開展融資活動，以確保項目資金及時到位，保證項目的正常開展。集團公司會定期召開資金計劃會議，審議各個代建公司提交上來的資金計劃，生成匯總的審核通過后的集團公司資金計劃。代建公司根據項目需要向集團公司提交用款申請，集團市政部先審核用款申請是否合乎標準，通過后，轉交給投金部和計財部，這些部門通過后，再由市政部復審，確保無誤后，提交給集團領導最終審批。資金申請的依據是項目的合同或非合同信息，受合同支付條件約束，同時也不能超出已經確定的資金計劃。資金申請獲批后，代建公司就可以提起付款申請了。相關的資金就會按照合同支付條款分期分批的打入代建公司的銀行賬戶。最后，回購是指政府職能部門在項目完成后將建成的基礎設施整體購買的行為。回購需要集團公司和政府簽訂回購合同，一般情況下，政府并不是一次性付清款項，而是在一個回購合同中協商好的回購期內，分期分批的付款。由于不是一次性付款，就會產生資金成本，集團公司會在回購合同中約定相應的利息。系統需要根據回購合同生成申請信息，供回購款申請時使用。回購管理主要就是管理回購項目的回購合同信息以及回購申請的審批。

3非功能需求

考慮到業務本身的特點，在非功能需求方面將安全性和穩定性作為首要目標。要求系統具有硬件和軟件兩方面的容錯功能。另外，考慮到使用該系統的人員分散在不同的多家公司，所以要求系統易于部署，兼容性好，支持多種操作系統，并且具備一致的用戶界面。同時要求系統易于維護，可以方便地配置不同用戶的相應權限。

4結論

遵循著軟件工程思想，對浦發集團的投資管理業務進行了需求分析，闡述了業務范圍及內容，明確了不同的用戶角色和業務流程。

作者：彭小勇 單位：上海大學計算機工程與科學學院

參考文獻:

篇(2)

【關鍵詞】:圖書管理系統;需求;功能

二十一世紀是信息高度交流與發展的時代,面計算機系統則在信息時代扮演著極為重要的腳色,隨著計算機的不斷發展,計算機以滲透到各個領域,圖書館也不例外,圖書館的計算機化以不容遲緩。

圖書館在正常運營中總是面對大量的讀者信息、書籍信息以及兩者相互作用產生的借書信息、還書信息。需要對讀者資源、書籍資源、借書信息、還書信息進行管理,及時了解各個環節中信息的變更,有利于提高管理效率。作者針對圖書館手工管理的現狀,經過詳細系統的調查,闡明了圖書管理系統的需求和功能,為圖書館管理信息系統的開發打下堅實基礎。

一、圖書管理系統的需求分析

當決定要開發一個信息系統時,首先要對信息系統的需求進行分析,需求分析要做的工作是深入描述軟件的功能和性能,確定軟件設計的限制和軟件同其他系統元素的接口細節,定義軟件的其他有效性需求。

獲得當前系統的處理流程,在此首先假設當前系統是手工處理系統。手工處理流程大致是這樣的。讀者將要借的書和借閱證交給工作人員,工作人員將每本書附帶的描述書信息的卡和讀者借閱證一起放在一個小格欄,并在借閱證和每本書上貼的借閱信息。這樣借書過程就完成了。還書時讀者將要還的圖書交給工作人員,工作人員圖書信息找到相應的書卡和借閱證,并填寫相應的還書信息。

抽象出當前系統的邏輯模型。在理解當前系統“怎么做”的基礎上,抽取其“做什么”的本質,從而從當前系統的物理模型抽象出當前系統的邏輯模型。在物理模型中有許多物理因素,隨著分析工作的深入,有些非本質的物理因素就成為不必要的負擔,因而需要對物理模型進行分析,區分出本質的物理因素就成為不必要的負擔,因而需要對物理模型進行分析,區分出本質的和非本質的困素,去掉那些非本質的困素即可獲得反映系統本質的邏輯模型。

建立目標系統的邏輯模型。分析目標系統與當前系統邏輯上的差別,明確目標系統到底要“做什么”,從而從當前系統的邏輯模型導出目標系統的邏輯模型。在對上述流程進行分析后,我們對新的圖書處理流程進行整理,圖書館借還書過程如下:

借書過程:讀者從架上選到所需圖書后,將圖書和借書卡交管理人員,管理人員用碼閱讀器將圖書和借書卡上的讀者條碼2碼讀入處理系統。系統根據讀者條碼從讀者文件和借閱文件中找到相應記錄;根據圖書上的條碼從圖書文件中找到相應記錄,讀者如果有如下列情況之一將不予辦理借書手續。

①讀者所借閱圖書已超過該讀者容許的最多借書數目。

②該讀者記錄中有止借標志。

③該讀者還有已超過歸還日期而仍未歸還的圖書。

④該圖書暫停外借。

若讀者符合所有借書條件時,予以借出。系統在借閱文件中增加一條記錄,記入讀者碼、圖書條碼、借閱日期等內容。

還書過程:還書時讀者只要將書交給管理人員,管理員將書上的圖書條碼讀入系統,系統從借閱文件上找到相應記錄,填上還書日期后寫入借閱歷史文件,并從借閱文件上刪去相應記錄,同時系統對借還書日期進行計算并判斷是否超期,若不超期則結束過程,若超期則計算出超期天數、罰款數、并打印罰款通知書,記入罰款文件。同時在讀者記錄上作止借標記。當讀者交來罰款收據后,系統根據讀者條碼查罰款文件,將相應記錄寫入罰款歷史文件,并從罰款文件只刪除該記錄,同時去掉讀者文件中的止借標記。

為了對圖書管理系統做完整的描述,還需要對上面得到的邏輯模型做一些補充.首先采用圖形的方式描述圖書管理系統的用戶界面,這樣做的目的是保證整個系統的用戶界面的一致性,同時也有國助于后續的開發人員更好地理解系統需要實現的功能.其次,說明圖書管理系統的一些特珠性能要求。如借書、還書服務花費的時間一次不得大于5分鐘等。

前面著重對借還書流程進行了說細的闡述,下面介紹圖書管理系統的總體功能要求。簡單的圖書管理系統主要包括下面的功能:

>借書處理:完成讀者借書這一業務流程。

>還書處理:完成讀者還書這一業務流程。

>罰款處理:解決讀者借書超期的罰款處理。

>新書上架:輸入新書資料。

>舊書淘汰:刪除圖書資料。

>讀者查詢:根據讀者號,查詢讀者借閱情況。

二、圖書管理系統的功能分析

系統功能分析是在系統開發的總體任務的基礎上完成。圖書館管理信息系統需要完成功能主要有:

.有關讀者種類標準的制定、種類住處的輸入,包括種類編號、種類名稱、借書數量、借書期限、有效期限、備注等。

.讀者種類信息的修改、查詢等。

.讀者基本信息的輸入,包括讀者編號、讀者姓名、讀者種類、讀者性別、工作單位、家庭住址、電話號碼、電子郵件地址、辦證日期、備注等。

.讀者基本信息的查詢、修改,包括讀者編號、讀者姓名、讀者種類、讀者性別、工作單位、家庭住址、電話號碼、電子郵件地址、辦證日期、備注等等。

.書籍類別標準的制定、類別信息的輸入,包括類別編號、類別名稱、關鍵詞、備注信息等。

.書籍信息的輸入,包括書籍編號、書籍名稱、書籍名稱、書籍類別、作者姓名、出版社名稱、出版日期、書籍頁書、關鍵詞、登記日期、備注信息等。

.借書信息的輸入,包括借書信息編號、讀者編號、讀者姓名、書籍編號、書籍名稱、借書日期、備注信息等。

.借書信息的查詢、修改,包括借書信息編號、讀者編號、讀者姓名、書籍編號、書籍名稱、借書日期、備注信息等。

.還書信息的輸入,包括還書信息編號、讀者編號、讀者姓名、書籍編號、書籍名稱、借書日期、還書日期、備注信息等。

還書信息的查詢和修改,包括還書信息編號、讀者編號、讀者姓名、書籍編號、書籍姓名、借書日期、還書日期、備注信息等。

參考文獻

[1]EWinemiller,J.Roff,著.VisualBasic6.0數據庫開發.清華大學出版社,1999.

[2]郭盈發,張紅娟.《數據庫原理》.西安電子科技大學出版社,2002.

篇(3)

目前網絡技術迅速的普及和推廣，為汽車服務產業提供了一個新的平臺，網絡化與智能化的管理服務在當前與今后的一段時間內已成為汽車服務企業競爭制勝的關鍵籌碼。面對現代化的需求，一個仍然使用傳統管理技術與管理手段的汽車服務企業是不可能適應現代化汽車服務與現代人的管理服務要求的，了解和掌握汽車維護維修管理智能化設施設備的維護與管理，利用網絡技術進行全方位管理、利用和監控汽車維護維修管理信息對汽車服務行業及時增強市場競爭力、提高管理技術以及促進整個行業的進步都十分重要。

本課題為了實現人性化、智能化的汽車維護維修管理與服務，根據目前市場上的汽車維護維修的管理業務流程制定了切實可行的汽車維護維修客戶服務管理系統的軟件需求，對該管理系統的系統架構和主要功能模塊進行了設計。考慮到信息技術與網絡技術的發展以及它們帶給人們工作模式的改變，對比目前多種網絡開發技術，提出了采用先進的JSP開發平臺、利用B/S模式Web應用程序的汽車維護維修客戶服務管理系統解決方案。

基于JSP平臺構建汽車維護維修客戶服務管理系統是綜合應用了數據庫技術、網絡技術及WEB開發技術等多個技術。如何有效地在汽車維護維修管理系統的軟件開發中應用多個技術，如何使整個系統更加靈活與穩定，以適應在管理服務上汽車維護維修的業務擴展等多個問題都具有一定理論意義，都是值得深入研究和探討的。

1.系統目標

汽車維護維修客戶服務系統是一個涉及管理、服務和財務等多方面的系統工程。現代汽車維護維修管理系統應滿足以下要求：一是全面化，滿足汽車用戶的需求以及工作人員的管理需求；二是數字化，實現數字化，減少重復勞動，提高工作效率，加速信息記錄、檢索；三是先進性，體現時代需要，使維護維修管理更細致、深入。作為現代汽車維護維修中不可缺少的一部分，該系統在其中應達到以下目標：

汽車用戶能夠預約，工作人員進行預約管理，并提供及時周到的服務。

在外界環境（如網絡病毒、停電等）干擾本系統時，系統可自動保護原始數據的安全。

數據查詢方便靈活。操作過程、方便、快速。

提供簡潔、標準化的管理過程。

完善的權限管理，提高系統的安全性。

能夠快速得到業務相關的各種數據與報表。

操作界面統一，友好美觀，具有可擴展性、易操作性和易維護性。

2.系統的功能需求分析

由于該系統是針對汽車維護維修公司內部使用的系統，所以系統建設前需要分析該系統的基本用戶以及他們的需求，然后設計系統應具有的基本功能和應包含的信息內容，從系統用戶的性質來看，該系統主要有系統管理人員、汽車維護維修公司管理人員這兩類。經過仔細調查和分析該系統用戶的需求，這兩類用戶對系統基本功能和信息內容呈現著不同的需求。

2.1系統管理人員的功能的需求

系統管理員有最大權限，可完成對系統的管理。內容包括對員工權限的設置、對汽車維護維修客戶服務管理系統的數據庫進行備份和恢復等。

系統管理員對員工權限進行管理，如增加、修改、刪除權限等，并將信息存入數據庫中。

為了避免操作或者病毒感染而造成的數據損失，系統管理員應能夠對數據庫的備份和數據庫的恢復進行操作。

2.2公司管理人員的功能需求

汽車維護維修公司管理人員主要完成公司日常的工作事項，包括客戶信息管理、客戶預約管理、配件信息管理、供應商管理、入庫管理、庫存報警管理及維修管理等。公司管理人員功能需求如下：

前臺登記管理主要對客戶信息、預約信息、維修管理信息進行管理，從而對公司客戶的情況有一個概括性的了解。

登記汽車用戶的姓名、身份證、電話、地址、車牌、車型等信息，并對客戶信息進行瀏覽、修改以及刪除；當客戶進行了提前預約，前臺人員在每天的固定時間需進行預約查詢，以確保及時為客戶服務，并對預約記錄進行瀏覽、修改、刪除；及時瀏覽維修記錄，以確保向用戶反映正確的維修信息。

汽車維修人員主要對維修信息進行管理，做到及時反饋信息，讓前臺人員能夠有一個大概的了解，同時也讓庫管人員對現有配件信息及時做出調整。登記用戶姓名、車牌信息、車型、身份證、故障描述，以及使用的配件信息、數量等信息。

庫管人員主要對配件信息、供銷商、入庫等進行管理。

登記配件類別，對配件信息進行登記、修改和刪除；并對配件做入庫管理，添加、修改、刪除配件名稱、入庫數量以及供銷商等信息；其中還對供銷商進行管理，添加、修改、刪除供銷商公司名稱、電話、郵箱、地址等信息。以便于以后正常開展公司的管理工作，其中某些數據將為汽車維護維修公司在配件出現一些問題時提供重要依據。

3.性能需求分析

系統的性能需求一般是指正確分析協議、順利傳遞相互消息，友好界面，運行時間能滿足使用需求，安全性能得到保障。

在高網絡寬帶、高系統配置容易得到保障的情況下，最先考慮的性能需求就是系統安全性問題。本系統是針對公司內部使用，不涉及到聯網操作，在非工作人員不當操作的情況下，該系統能夠得到安全保障。但考慮到操作人員的特質，先做出以下要求：

（1）在操作成員輸入一些不合理的數據的時候，能夠進行一些合理的提示信息，不能因為輸入錯誤而導致系統的錯誤，或者程序停止運行。

篇(4)

1. 引言 ................................................................. 1

1.1編寫目的 ........................................................ 1 1.2項目背景 ........................................................ 1 1.3定義 ............................................................ 2 1.4參考資料 ........................................................ 2 2．任務概述 ............................................................ 2

2.1目標 ............................................................ 2 2.2運行環境 ........................................................ 3 2.3條件與限制 ...................................................... 3 3．數據描述 ............................................................ 3

3.1靜態數據 ........................................................ 3 3.2動態數據 ........................................................ 4 3.3數據庫介紹 ...................................................... 5 3.4數據詞典 ........................................................ 6 3.5數據采集 ........................................................ 7 4．功能需求 ............................................................ 8

4.1功能劃分 ........................................................ 8 4.2功能描述 ....................................................... 21 5．性能需求 ........................................................... 22

5.1數據精確度 ..................................................... 22 5.2時間特性 ....................................................... 22 5.3適應性 ......................................................... 22 6．運行需求 ........................................................... 23

6.1用戶界面 ....................................................... 23 6.2硬件接口 ....................................................... 28 6.3軟件接口 ....................................................... 28 6.4故障處理 ....................................................... 28 7．其它需求 ........................................................... 29 8. 附錄 .............................................................. 29

1. 引言

1.1編寫目的

隨著計算機技術的發展，人類生活速度的加快，單一的人工售票方式已經不能滿足人們出行的要求。每逢出行高峰都會造成火車站售票的擁擠，因此售票自動化應運而生。車站售票管理系統就是這樣的一個產物。經過我開發小組的調研與討論研究，基本上明確了該系統的需求，并在此基礎上完成軟件需求規格說明書。該文檔旨在對該系統的需求做出綜合的分析，對各個模塊的功能做出具體的說明。

《車站售票管理系統需求規格說明書》的目的是明確《車站售票管理系統》中各項功能和非功能需求，確定系統功能模塊，同時為概要設計和詳細設計人員提供設計依據，也可供本項目的其他開發人員參閱。本需求分析報告的目的是規范化本軟件的編寫，旨在于提高軟件開發過程中的能見度，便于對軟件開發過程中的控制與管理，同時提出了本火車售票系統的軟件開發過程，便于程序員與客戶之間的交流、協作，并作為工作成果的原始依據，同時也表明了本軟件的共性，以期能夠獲得更大范圍的應用。。

本文檔需要交于論證人員進行論證修改，無誤后供軟件開發人員進行后期的軟件設計

1.2項目背景

委托單位：呼和浩特火車站 開發單位：內蒙古工業大學軟件工程 主管部門：內蒙古工業大學計算機系 項目開發者： 周偉，馬星，張玲燕，苗欣宇 用戶：呼和浩特火車站 產品的所有權：呼和浩特火車站

項目背景：火車票出售管理系統是典型的信息管理系統(MIS),其開發主要包括后

臺數據庫的建立和維護以及前端應用程序的開發兩個方面。本項目適用于Windows 操作系統，使用SQL Server 2005數據庫，利用C++,JAVA

開發平臺開發系統。

1.3定義

靜態數據：主要是由表和視圖組成，應該注意的是，數據字典中的表是不能直接

被訪問的，但是可以訪問數據字典中的視圖。

動態數據：SQL 包含了一些潛在的由系統管理員如SYS 維護的表和視圖，由于當

數據庫運行的時候它們會不斷進行更新，所以稱它們為動態數據字典（或者是動態性能視圖）。這些視圖提供了關于內存和磁盤的運行情況，所以我們只能對其進行只讀訪問而不能修改它們。

數據字典：數據字典是SQL 存放有關數據庫信息的地方，其用途是用來描述數據

的。比如一個表的創建者信息，創建時間信息，所屬表空間信息，用戶訪問權限信息等。當用戶在對數據庫中的數據進行操作時遇到困難就可以訪問數據字典來查看詳細的信息。

需求：用戶解決問題或達到目標所需的條件或功能；系統或系統部件要滿足合同、

標準，規范或其它正式規定文檔所需具有的條件或權能。

需求分析：包括提煉，分析和仔細審查已收集到的需求，以確保所有的風險承擔

者都明其含義并找出其中的錯誤，遺憾或其它不足的地方。

1.4參考資料

[1] 劉利民、田寶軍 .軟件工程綜合設計指導書,2011

[2] 張海藩. 軟件工程導論（第五版）. 北京清華大學出版社,2003 [3] 黃國興、周勇著 .軟件需求工程. 清華大學出版社,2008-05 [4] 車站售票管理系統——項目開發計劃書 [5] 車站售票管理系統——可行性分析報告

2．任務概述

2.1目標

利用信息化手段緩解火車站售票壓力，滿足廣大人民群眾的購票需求，使管理人員能夠方便進行售票管理工作，包括修改、維護、統計等，使廣大人民用戶能夠利用該系統進行信息的查詢，購票，退票等。

用自然語言或者形式化語言與圖形等完整、準確、具體地描述系統的數據需求、功能需求、性能需求、可靠性需求和可用性需求、接口需求、約束、逆向需求以及將來可能提出的要求。

（1) 完善目前火車售票系統，使之能跟上時代的發展。同時通過實踐來提高自

己的動手能

（2）應用范圍：理論上能夠實現于鐵路部門的售票系統，其目的在于在原有的

系統基礎使得火車售票便捷化，以期實現完善日常生活中火車售票的各種缺陷。

（3）可實現旅客對于火車票的查詢與購買功能，售票員則可實現查詢、添加和

刪除等功能；對于所查詢的車次結果提供列表顯示輸出；有一定的安全機制，普通旅客不能對車次信息隨意刪改，只有系統管理員可通過密碼識別進行維護。

2.2運行環境

操作系統：Microsoft Windows 2007或Microsoft Windows XP 支持環境：IIS 5.0

數 據 庫：Microsoft SQL Server 2005

2.3條件與限制

應具備的設備：計算機4臺，打印機1臺 應具備的人員：軟件專業學生4人

其他條件：保證相關開發人員全部到位，不缺勤；資金全部到位

3．數據描述

3.1靜態數據

列車信息：列車車號 (int SerialNumber) 列車始發時間 (struct time SetOut) 列車始發站(char DeparturePoint) 列車終點站(char TerminalPoint) 額定載量（int FixNumber ）

票務：列車車號 (int SerialNumber) 發車時間 票價 發出車站

售票員：用戶名 （char name） 密碼(char password)

3.2動態數據

輸入數據：（根據界面提示，鍵盤輸入操作） 輸出數據：

輸出信息：查詢車次確定的數據庫記錄的子集；

3.3數據庫介紹

名稱：Microsoft SQL Server 2005

介紹：微軟SQL Server 2005 SP1加入數據庫鏡像功能，為SQL Server 2005

Express Edition提供新管理工具，并且加強了SAP NetWeaver智能商務系統的報告反饋支持功能。

管理：SQL Server Management Studio 集成了對 SQL Server 2005 所有組件的

管理。Business Intelligence 從業者都將得益于 Microsoft 服務器“能力”擴展這一用戶盼望已久的功能增強，即從關系引擎（伸縮性、可靠性、可用性、可編程性，等等）擴展為全套的 BI 平臺組件。 支持的操作系統： Windows 2000 Service Pack 4;

Windows Server 2003 Service Pack 1; Windows XP Service Pack 2

硬件要求：具有 Intel Pentium III 600 MHz（或同等性能的兼容處理器）或速

度更快處理器（建議使用 1 GHz 或速度更快的處理器。）的計算機 最低 192 MB 的 RAM（建議使用 512 MB 或更高的 RAM。） 100 MB 的可用硬盤空間

注意事項：安裝此包之前，必須從系統中刪除 SQL Server Management Studio

Express 的任何 Beta 版本或 Community Technology Preview (CTP) 版本。如果不執行此操作，則將導致此包安裝 失敗。

安裝條件：您必須在計算機上具有管理權限才能安裝SQL Server 2005。

3.4數據詞典

3.5數據采集

（1） 車票信息由數據庫設計人員加入錄入數據庫中

（2） 用戶賬戶及密碼由登陸人員自行設計有數據庫設計人員設計的系統方

式錄入數據庫中。

（3） 其他數據如票務信息由系統自動生成

4．功能需求

4.1功能劃分

圖 3.1 系統管理用例圖

表3-1 登錄系統用例規約

表3-6 維護數據管理規約

圖 3.2 售票用例

表3-7登錄系統用例規約

表3-8 退票規約

表3-9 統計信息用例規約

表3-10 售票規約

表3-11查詢信息規約

表3-12 購票規約

4.2功能描述

售票：根據旅客的需求如發車日期、發車時間、車廂類型、車票類型（學生票、

軍人票?）、旅客終點站等選擇用戶所需要的車次，然后結算并打印車票給旅客。

訂票：由售票點授權或是有一定信譽的售票商替代旅客進行預訂車票，售票

商通過電話或是親自到售票點預訂的方式進行預訂車票。

退票：處理用戶由于某種情況需要退回車票的情況，旅客要在車站指定的時間內

進行退票，此外車站售票點還要扣除一定的手續費。如若改簽則由售票員改簽到旅客所要的車次、時間、地點。

查詢：查詢分為車次查詢、站點查詢、時刻表查詢、票價查詢、剩余票數查詢。

車次查詢提供了所有車次瀏覽、按車次查詢、和站站查詢，用戶可以通過查詢來了解列車所經車站以及發車時間等信息。時刻表查詢可以查詢每一車次在每一站的發車時間和到站時間。票價查詢可以讓用戶按自己的需求來查詢所有車次的車票價格；余票查詢可以查詢到所有車次的剩余車票的

情況；

統計：售票統計分別可以按日期統計、按車次統計、按客流方向統計等統計方式，

通過察看車票的流向可以得知旅客的大致流向，列車管理人員可以根據客流的流向隨時調整列車運行車次，達到列車的合理調度，使列車最大限度的投入使用中，實現資源的合理利用。

信息修改：包括車次修改、票價修改、站點修改。車次修改包括增加車次，減少

車次，車次的臨時調度和由于自然災害造成的臨時路線更改。票價修改為節假日、春運等特殊時段或某些特殊地域需要適量增加或減少票價，具體數字有鐵路管理定。站點修改可是某些車次增加或減少一些站點。 系統管理：管理員通過系統添加用戶或者刪除用戶，并且授予權限，同時維護數

據庫，保證系統正確運行。

5．性能需求

5.1數據精確度

由于采用數據庫技術并且用戶的應用領域對數據精確度的要求不是太高，所以這點在系統中表現得比較少，但是用戶數據的安全性與正確性是完全保證的，所以對用戶的使用沒有多大的障礙。輸入數據精度要求不高，但用戶輸入不精確時有提示。

5.2時間特性

對于用戶的輸入應該在較短的時間里給出回應。若出錯，應有出錯報告。由于該系統要求36臺機器能夠同時運行，要求較高的并發處理功能。當增加多臺機器后，要求系統的響應時間不會有過大的延時。

5.3適應性

該軟件只能在Windows 系統下運行，所以兼容性不高，但應用戶特殊需求在維護階段會保持一個與其它類軟件接口，隨時滿足客戶的使用需求。

6．運行需求

6.1用戶界面

圖3.3 系統登錄界面

圖 3.4 旅客及售票員查詢界面

圖 3.5 管理員功能界面

圖 3.6 列車信息

圖 3.7售票員功能

圖 3.8 退票界面

圖 3.9 人員管理

圖 3.10 權限管理

圖 3.11 售票管理

圖 3.12 列車管理

圖 3.12 維護后臺

6.2硬件接口

（1）硬件接口：支持x86系列PC 機

（2）網絡硬件接口要求：現實中要求具有高速以太網組網一實現聯網銷售，但是在理論實驗驗證軟件本身的目的來看，無需網絡通訊接口。

軟件除較小硬盤和顯示器，鼠標外，服務器，基本沒有與外界硬件的聯系，不過考慮到數據庫大量數據的備份等要求可以保持與磁帶機和光盤刻錄機的接口。

6.3軟件接口

在這里主要考慮軟件與操作系統的接口，考慮到文檔處理的需要有可能需要與常用的辦公軟件的接口。例如Microsoft 的office 系列。另外查詢模塊需要與互聯網相連，以實現乘客的網上查詢。運行于Windows2000及更高版本并裝有JAVA 虛擬機的操作系統之上。

6.4故障處理

鑒于火車售票系統涉及的數據對于火車站日常管理的重要性，必須建立數據庫嚴格有效的恢復機制：數據必須每天進行一次備份，由于本信息涉及信息量巨大，應以天為周期進行增量轉儲，一般半個季度為周期進行刪除。

正常使用時不用出錯，對于用戶的輸入錯誤應及時給出適當的改正信息提

示，若運行遇到不可恢復的系統錯誤，也必須保證數據庫完好無損。

7．其它需求

本系統中對系統各個模塊功能，以分級菜單的形式給出；所有的提交，確認，刪除等操作以按鈕的形式給出，且名稱一律取為“提交”、“確認”、“刪除”等易于理解的形式；根據用戶統計信息計算，統計在正常情況下應該支持一定人數的并行操作能力，春運高峰期間人們要集中買票和查詢，應支持更多人數的并行操作能力；高峰期間服務器應支持幾十萬以上的日訪問量。 （1）可用性：該軟件也可以通過單步跟蹤的操作進行檢查處理。

（2）安全性：由于軟件運行數據放在數據庫中，所以參數不容易被錯改、破壞，萬一參數受到破壞也不會影響源程序。

（3）可維護性：該軟件利用數據庫進行編程，系統結構由程序基本確定，大量的參數及文本內容全部放于數據庫中。修改、更新數據只要在數據庫進行修改添加，而不需要對系統結構進行修改，這樣系統維護性、升級都十分方便。 （4）兼容性：由于尚未測試，故無法對兼容性進行評析。

8. 附錄

1. 車輛類型

篇(5)

裝備主動式保障系統是指使用和維修裝備所需的各種資源及其組織管理，在一定環境下為保證或者維持裝備戰備完好性目標而形成的相互影響、相互制約、相互促進的有機整體。裝備主動式保障系統以保障人員和資源為基礎，以武器裝備為保障對象，通過組織結構管理、協調系統運行，實現保障系統功能的循環過程，完成各類軍事資源到滿足部隊對裝備需求的轉換，其系統構成如圖3所示。針對信息化戰爭戰場范圍大、節奏快等特點，對裝備主動式保障系統的運行描述如下［4-6］:1)裝備在執行任務命令過程中受損，能夠顯示故障征兆，預測與健康管理系統可對裝備進行實時監測，記錄狀態數據，并生成監測報告，隨時發送至維修管理系統;2)維修管理系統可根據監測報告，結合數據管理系統提供的歷史監測數據，進行故障預測及診斷，制定維修規劃并發送至動態資源管理系統;3)動態資源管理系統分析維修規劃，計算維修資源需求，將需求數據發送至資源管理系統;4)資源管理系統管理裝備資源和維修資源，可根據維修資源需求，安排人員、設備對發生故障的裝備進行適時、適地、適量維修;5)戰場情況下損傷裝備在裝備修竣以后可根據情況繼續執行任務或返回車場進行保養，等待下一次任務。為保證裝備主動式保障系統運行的完整性，系統應從“任務下達”開始運行，因此，可對裝備主動式保障系統添加描述:1)指揮管理系統可隨時根據需要制定任務要求，任務要求至少包括任務目標、必要器材等，并發送至任務管理系統;2)任務管理系統可根據任務要求，制定任務規劃，并傳送至動態資源管理系統;3)動態資源管理系統可分析任務規劃，計算任務需求，向資源管理系統確認任務能力;4)資源管理系統確認任務能力之后，向任務管理系統反饋確認信息，接收確認信息后，任務管理系統向執行部隊的裝備群下達任務命令。

裝備主動式保障系統需求建模

對象模型

從上述系統描述中分析出保障系統需求信息，并在此基礎上確定對象、類以及它們之間的靜態聯系。獲取并篩選出保障系統的對象有:指揮管理系統、任務管理系統、動態資源管理系統、資源管理系統、PHM系統、維修管理系統、數據管理系統。類有:裝備、車場、任務要求、任務規劃、任務能力、任務命令、故障征兆、監測報告、歷史數據、維修規劃、維修資源、維修、保養。確定保障系統對象、類之后，需要從保障系統描述中獲取對象、類間的相互關系，具體如下:1)指揮管理系統下達任務要求;2)任務管理系統接收任務要求;3)任務管理系統制定并下達任務規劃;4)動態資源管理系統接收任務規劃;5)動態資源管理系統分析任務規劃;6)動態資源管理系統向資源管理系統發送確認信息;7)資源管理系統確定任務能力;8)資源管理系統將確認結果反饋給任務管理系統;9)資源管理系統包括裝備資源和維修資源;10)任務管理系統下達任務命令;11)裝備接收任務命令;12)裝備執行任務命令;13)裝備顯示故障征兆;14)PHM系統對裝備進行實時監測;15)PHM系統生成監測報告;16)PHM系統將監測報告發送至維修管理系統;17)數據管理系統儲存裝備歷史監測數據;18)數據管理系統向維修管理系統提供歷史數據;19)維修管理系統接收監測報告;20)維修管理系統接收歷史監測數據;21)維修管理系統生成維修規劃;22)維修管理系統將維修規劃發送至動態資源管理系統;23)動態資源管理系統接收維修規劃;24)動態資源管理系統向資源管理系統確認維修資源信息;25)維修資源管理系統安排維修人員和設備對裝備進行維修;26)裝備修竣后繼續執行任務;27)裝備修竣后返回車場保養。梳理保障系統對象、類之間的相互關系，剔除不必要、不正確的關聯，并定義各對象、類的屬性，之后，即可建立裝備主動式保障系統的對象模型，如圖4所示。對象模型清晰、直觀地表達了任務要求、任務規劃、指揮管理系統等保障系統各對象、類間輸入輸出關系，為動態模型中場景描述和功能模型中數據流信息描述奠定了基礎。

動態模型

動態模型用來表達保障系統對象、類之間因為事件發生所產生的動態時序關系。獲得動態模型的第一步是編寫系統場景，裝備主動式保障系統正常運行情況的場景描述如下:1)指揮管理系統主要負責下達任務要求;2)任務管理系統負責接收任務要求，并制定任務規劃;3)動態資源管理系統接收任務規劃，向資源管理系統確定任務能力;4)資源管理系統確認任務能力并將確認結果反饋給任務管理系統;5)任務管理系統向裝備下達任務命令;6)裝備接收并執行任務命令;7)裝備在執行命令過程中顯示故障征兆;8)PHM系統對裝備進行實時監測，并生成監測報告，發送至維修管理系統;9)數據管理系統儲存并向維修管理系統提供裝備歷史監測數據;10)維修管理系統接收監測報告及歷史監測數據，生成維修規劃，發送至動態資源管理系統;11)動態資源管理系統接收維修規劃，向資源管理系統確認維修資源信息;12)維修資源管理系統安排人員、設備對裝備進行維修;13)裝備修竣后繼續執行任務或者返回車場進行保養。認真分析各場景中內容，提取系統中信息傳遞及各子系統之間輸入輸出關系，畫出裝備主動式保障系統正常運行情況場景序列圖，如圖5所示。序列圖是保障系統運行場景的圖形表示，它清楚表達了保障系統中事件的時序關系。確定序列圖中保障系統對象、類的初態，將序列圖中事件作為狀態圖的有向邊，同時考慮系統邊界情況下可能發生的事件，構建的裝備主動式保障系統動態模型如圖6所示。在無任務運行時，裝備主動式保障系統表現為無任務狀態，隨著下達任務要求，下達任務規劃等一系列事件的發生，保障系統狀態不斷發生變化。動態模型正是以裝備主動式保障系統運行中可能發生的事件為出發點，按照事件發生的順序，描述其對保障系統狀態變化的影響。

功能模型

根據對象模型中系統各對象、類屬性及其相互關系和動態模型中引起系統狀態變化的事件序列關系，構建裝備主動式保障系統功能模型，如圖7所示。上述功能模型中，任務要求、裝備、車場是與保障系統進行數據流交互的現實載體，任務目標、任務類型及方案、人員裝備需求等是對象模型中定義的保障系統對象、類的屬性，即數據流信息，制定規劃、計算任務需求是保障系統需要完成的功能。功能模型描述了裝備主動式保障系統數據流從任務要求到最終裝備修竣進入車場進行保養的全過程，是對裝備主動式保障系統需求的直接體現。

各功能子系統信息流程

篇(6)

關鍵詞：學生操行管理；數據庫；MySQL

1.概述

在中等職業學校中，學生操行管理工作，主要體現在管理學生考勤、勞動、行為等日常表現中。通常班主任需要安排多名班干部分別負責管理、記錄，并于每周、每月及學期末進行統計匯總、評分，以評價學生表現，為學生的日常管理、班級管理及德育教育工作提供數據支持。數據越詳細，統計越及時，越有利于學生管理工作有的放矢。但是，在傳統模式下，數據多以紙質形式存在，即使錄入Excel，也存在統計匯總效率低，不及時等問題。

運用現代信息技術手段，建立基于WEB的學生操行管理系統，教師、學生通過手機等設備錄入原始數據，在WEB服務器中進行存儲，然后通過瀏覽器訪問，即可實時查詢學生的各項表現及統計數據，會極大提高數據統計工作效率。學生操行管理數據庫，則是此學生操行管理平臺中最基礎、最核心的部分。MvSOL數據庫是一個在WEB應用中非常流行的關系型數據庫管理系統，具有開源、免費、體積小，速度快、性能卓越，常與PHP及Java等搭配，組成開發應用環境。本文即采用Mysql來設計建立學生操行管理數據庫。

2.數據庫系統設計

2.1系統需求

學生操行管理系統需要能實時記錄學生的各項日常表現，實時匯總，為班主任的班級管理、學生德育教育、期末學生操行評定工作等提供數據依據。因此，本數據庫必須要滿足如下要求：

1）能記錄學生的基本信息，如姓名、籍貫、出生日期、家長聯系電話等；

2）能記錄學生考勤原始信息；

3）能記錄學生住宿信息，便于宿舍管理；

4）能記錄班班干部、寢室長等學生干部信息；

5）能記錄學生的勞動值日安排及學生勞動狀況等原始信息；

6）能錄學生作業完成情況；

7）能記錄學生的其他表現，如拾金不昧、打架、是否積極參加集體活動等事件信息；

8）有多用戶登錄功能，如不同的班干部可完成不同信息的錄入；

9）能自動完成每周、每學期考勤、作業、勞動等表現的匯總瀏覽；

10）能自動完成每學期各周學生操行表現的成績計算。

2.2數據表的設計原則

本數據庫的設計，遵循一事一地的原則，每一數據表只記錄某類實體的原始數據，數據的匯總統計，均采用視圖形式予以實現。

2.3系統的數據字典

根據系統需求及設計原則，本系統各數據表如下表所示。

2.4系統E-R圖

根據系統需求，數據字典，繪制本數據庫E-R圖，如下圖所示，圖中使用矩形表示實體，菱形表示聯系，線條用于連接。

2.5數據表設計

根據E-R圖，本數據庫創建了多個數據表，部分數據表結構如下。

1）管理員表：aid（int，notnull，auto_increment，主鍵），用戶名（varchar，255），密碼（varchar，255），權限（int，2），備注（vatchar，255）。

2）學期表：tid（int，not null，auto_increment，主鍵），學期（int，1），學年（varchar，20），開始日期（date），結束日期（date）。

3）操行項目表：did（int，not null，auto_increment，主鍵），行為類別（varchar，255），名稱（varchar，255），分值（double）。

4）勞動記錄表：fid（int，notnull，auto_increment，主鍵），日期（date），sid（int，11，指學生表id），時間（varchar，2，指中午、下午、晚上等），did（int，11，指勞動完成表現，操行項目表id）。

5）作業記錄表：wid（im，notnull，auto_increment，主鍵），eid（int，11，作業信息表id），sid（int，2，是學生表id），did（int，11，操行項目表id，指作業完成表現）。

6）考勤表：kid（int，notnull，auto_increment，主鍵），sid（int，11，是學生表id），日期（date），節次（varchar，10，采用n或m-n形式表示），did（int，11，操行項目表id，指考勤表現），缺勤節次（int，3）。

為簡化最終SQL查詢統計，還需要添加若干中間視圖，其一為按周顯示每天各節課學生考勤信息；其二為綜合各記錄表信息，匯總學生操行表現數據，為操行成績計算提供直接數據。

7）周考勤瀏覽：sid（int，11，是學生表sid），日期（date），w08（varchar，1，指周日晚自習第一節），w11（varchar，1，指周一第一節），……。

8）操行匯總：sid（im，為學生表sid），行為（va/'char，255，為行為名稱），日期（date），數量（decimal，32，0）

篇(7)

關鍵詞：需求側 管理系統

1 引言

電力需求側管理系統的首要功能任務就是解決電網缺電時如何做到電力需平衡。但不局限于當電網電力供應不足時做到供需動態平衡，通過研究負荷側實時的用電負荷變化和發展趨勢，為供電和發電兩側的5年發展規劃提供更加詳細的電網運行原始數據，使供需平衡點由靜態平衡達到一個動態平衡過程。

2 電力需求側管理系統的需求分析及總體設計

2.1 系統需求分析 電力需求側管理系統是在營銷運行的基礎上，將系統的用電監控與負荷需求側綜合分析綜合為一體化的綜合應用平臺。要求保證供電局其他系統上線的基礎性業務正常運行上線的前提下，為營銷部決策提供準確詳實的依據；并且通過將供電局眾多獨立的單個子系統整合成系統，達到數據資源最大程度優化和數據共享；制定統一標準的營銷業務流程。

2.2 系統的功能需求 電力需求側管理系統能夠實現主動采集負荷側電能參數、實時抄表、準確掌握用戶負荷側的數據變化趨勢、用戶負荷管理和控制、用電負荷側數據突變和實時監測分析、多線路線損并行計算分析等多種功能。因此系統要求具有高冗余度和可靠性，確保收集到監測數據的準確可靠和完整。從系統的硬件角度上，系統在CPU、RAM和硬盤存儲硬件設備等主要硬件方面留有足夠的發展升級空間。從軟件設計方面，電力需求側管理系統所要完成的主要功能可歸納為原始數據的收集、數據傳輸和實時監控、用戶負荷控制管理、用電數據突變異常、多路線損計算與綜合分析、電能數據報表的及時生成和打印、系統本身管理等幾大模塊。

2.3 總體設計 系統框架結構如下圖：

如圖2-1電網的需求側管理系統整體框架結構所示系統主要建立在地市電廠、關口電表、主要樞紐配電所、配變終端和用戶負荷側等關鍵電能量采集點的基礎之上的，在供、售、購電三個關鍵環節點上實現一體化管理，將用電負荷終端數據集中存儲分析；并且構建出電能量采集一體化系統，對電廠、各級配變終端、用戶負荷側等電能量數據實現實時采集。

3 電力需求側管理系統的研究與實現

3.1 主機系統設計 在建設思路上，這次電力需求側管理的規劃將數據庫的服務器與應用程序的服務器進行了一體化，但是有兩臺PC的配置。

3.2 數據庫/應用服務器設計 采用三層分層分布式數據結構后，底層數據庫及應用層數據庫服務器承擔著相應電力系統企業營銷業務線數據邏輯處理分析及運算的主要任務。

3.3 前置服務器設計 前置服務器主要完成整個需求側管理系統的通信、邏輯數據解析，實現用戶側終端數據及配變電能數據采集與系統終端數據聯系控制管理功能，應采用兩臺主備服務器，操作系統采用Linux系統構成雙機主備結構，提高系統可靠性。

3.4 備份系統設計

3.4.1 備份系統需求分析。首先，我們分析由于硬件故障、應用程序出錯、病毒入侵等多種可能導致業務系統功能中斷的原因，因此需要做好多種預防和解決各類系統缺陷故障的手段。對于系統硬件的故障，我們采用硬件備份的設計來解決這些問題。對于應用程序故障，采用三層分布式數據結構和多線程處理應用解決應用程序上的故障。但是對于自然災害導致的需求側管理系統癱瘓，為了在故障來臨時恢復原始數據，需要構建統一的備份中心來保護這些系統的數據，可通過異地數據恢復，將因系統無法自動恢復所帶來的損失減到最低程度。

3.4.2 備份系統組成。備份系統是由備份系統管理軟件，備份管理后備服務器以及硬件構成的。

4 總結

本文對整個電力需求側管理系統進行了全面的研究和開發。構建出電力需求側管理系統的需求分析及總體設計。對硬件平臺及軟件平臺設計及開發詳細的介紹。電力需求側系統將在電力企業與用電客戶之間架起溝通的橋梁，直接為電力部門產生良好的社會、經濟效益，因此本文研究具有良好的市場推廣應用前景。

參考文獻：

[1]劉磊.新型需求側管理系統特點解析[J].華北電力技術，2009（01）.

[2]鄭峰崖.當前實施電力需求側管理存在的問題和思考[J].廣東電力，2007（06）.

[3]胡江溢，王鶴，周昭茂.電力需求側管理的國際經驗及對我國的啟示[J].電網技術，2007（18）.

[4]楊林.電力需求側管理綜述[J].中國電力教育，2008（04）.