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

篇(1)

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

【關(guān)鍵詞】

投融資平臺；投資管理系統(tǒng)；需求分析

1前言

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

2功能需求

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

3非功能需求

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

4結(jié)論

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

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

參考文獻:

篇(2)

【關(guān)鍵詞】:圖書管理系統(tǒng);需求;功能

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

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

一、圖書管理系統(tǒng)的需求分析

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

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

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

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

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

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

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

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

④該圖書暫停外借。

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

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

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

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

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

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

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

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

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

>讀者查詢:根據(jù)讀者號,查詢讀者借閱情況。

二、圖書管理系統(tǒng)的功能分析

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

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

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

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

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

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

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

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

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

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

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

參考文獻

[1]EWinemiller,J.Roff,著.VisualBasic6.0數(shù)據(jù)庫開發(fā).清華大學出版社,1999.

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

篇(3)

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

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

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

1.系統(tǒng)目標

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

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

在外界環(huán)境（如網(wǎng)絡病毒、停電等）干擾本系統(tǒng)時，系統(tǒng)可自動保護原始數(shù)據(jù)的安全。

數(shù)據(jù)查詢方便靈活。操作過程、方便、快速。

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

完善的權(quán)限管理，提高系統(tǒng)的安全性。

能夠快速得到業(yè)務相關(guān)的各種數(shù)據(jù)與報表。

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

2.系統(tǒng)的功能需求分析

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

2.1系統(tǒng)管理人員的功能的需求

系統(tǒng)管理員有最大權(quán)限，可完成對系統(tǒng)的管理。內(nèi)容包括對員工權(quán)限的設置、對汽車維護維修客戶服務管理系統(tǒng)的數(shù)據(jù)庫進行備份和恢復等。

系統(tǒng)管理員對員工權(quán)限進行管理，如增加、修改、刪除權(quán)限等，并將信息存入數(shù)據(jù)庫中。

為了避免操作或者病毒感染而造成的數(shù)據(jù)損失，系統(tǒng)管理員應能夠?qū)?shù)據(jù)庫的備份和數(shù)據(jù)庫的恢復進行操作。

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

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

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

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

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

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

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

3.性能需求分析

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

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

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

篇(4)

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

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

2.1目標 ............................................................ 2 2.2運行環(huán)境 ........................................................ 3 2.3條件與限制 ...................................................... 3 3．數(shù)據(jù)描述 ............................................................ 3

3.1靜態(tài)數(shù)據(jù) ........................................................ 3 3.2動態(tài)數(shù)據(jù) ........................................................ 4 3.3數(shù)據(jù)庫介紹 ...................................................... 5 3.4數(shù)據(jù)詞典 ........................................................ 6 3.5數(shù)據(jù)采集 ........................................................ 7 4．功能需求 ............................................................ 8

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

5.1數(shù)據(jù)精確度 ..................................................... 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編寫目的

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

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

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

1.2項目背景

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

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

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

開發(fā)平臺開發(fā)系統(tǒng)。

1.3定義

靜態(tài)數(shù)據(jù)：主要是由表和視圖組成，應該注意的是，數(shù)據(jù)字典中的表是不能直接

被訪問的，但是可以訪問數(shù)據(jù)字典中的視圖。

動態(tài)數(shù)據(jù)：SQL 包含了一些潛在的由系統(tǒng)管理員如SYS 維護的表和視圖，由于當

數(shù)據(jù)庫運行的時候它們會不斷進行更新，所以稱它們?yōu)閯討B(tài)數(shù)據(jù)字典（或者是動態(tài)性能視圖）。這些視圖提供了關(guān)于內(nèi)存和磁盤的運行情況，所以我們只能對其進行只讀訪問而不能修改它們。

數(shù)據(jù)字典：數(shù)據(jù)字典是SQL 存放有關(guān)數(shù)據(jù)庫信息的地方，其用途是用來描述數(shù)據(jù)

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

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

標準，規(guī)范或其它正式規(guī)定文檔所需具有的條件或權(quán)能。

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

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

1.4參考資料

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

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

2．任務概述

2.1目標

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

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

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

己的動手能

（2）應用范圍：理論上能夠?qū)崿F(xiàn)于鐵路部門的售票系統(tǒng)，其目的在于在原有的

系統(tǒng)基礎使得火車售票便捷化，以期實現(xiàn)完善日常生活中火車售票的各種缺陷。

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

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

2.2運行環(huán)境

操作系統(tǒng)：Microsoft Windows 2007或Microsoft Windows XP 支持環(huán)境：IIS 5.0

數(shù) 據(jù) 庫：Microsoft SQL Server 2005

2.3條件與限制

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

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

3．數(shù)據(jù)描述

3.1靜態(tài)數(shù)據(jù)

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

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

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

3.2動態(tài)數(shù)據(jù)

輸入數(shù)據(jù)：（根據(jù)界面提示，鍵盤輸入操作） 輸出數(shù)據(jù)：

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

3.3數(shù)據(jù)庫介紹

名稱：Microsoft SQL Server 2005

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

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

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

管理。Business Intelligence 從業(yè)者都將得益于 Microsoft 服務器“能力”擴展這一用戶盼望已久的功能增強，即從關(guān)系引擎（伸縮性、可靠性、可用性、可編程性，等等）擴展為全套的 BI 平臺組件。 支持的操作系統(tǒng)： 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 的可用硬盤空間

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

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

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

3.4數(shù)據(jù)詞典

3.5數(shù)據(jù)采集

（1） 車票信息由數(shù)據(jù)庫設計人員加入錄入數(shù)據(jù)庫中

（2） 用戶賬戶及密碼由登陸人員自行設計有數(shù)據(jù)庫設計人員設計的系統(tǒng)方

式錄入數(shù)據(jù)庫中。

（3） 其他數(shù)據(jù)如票務信息由系統(tǒng)自動生成

4．功能需求

4.1功能劃分

圖 3.1 系統(tǒng)管理用例圖

表3-1 登錄系統(tǒng)用例規(guī)約

表3-6 維護數(shù)據(jù)管理規(guī)約

圖 3.2 售票用例

表3-7登錄系統(tǒng)用例規(guī)約

表3-8 退票規(guī)約

表3-9 統(tǒng)計信息用例規(guī)約

表3-10 售票規(guī)約

表3-11查詢信息規(guī)約

表3-12 購票規(guī)約

4.2功能描述

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

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

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

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

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

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

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

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

情況；

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

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

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

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

據(jù)庫，保證系統(tǒng)正確運行。

5．性能需求

5.1數(shù)據(jù)精確度

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

5.2時間特性

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

5.3適應性

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

6．運行需求

6.1用戶界面

圖3.3 系統(tǒng)登錄界面

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

圖 3.5 管理員功能界面

圖 3.6 列車信息

圖 3.7售票員功能

圖 3.8 退票界面

圖 3.9 人員管理

圖 3.10 權(quán)限管理

圖 3.11 售票管理

圖 3.12 列車管理

圖 3.12 維護后臺

6.2硬件接口

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

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

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

6.3軟件接口

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

6.4故障處理

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

正常使用時不用出錯，對于用戶的輸入錯誤應及時給出適當?shù)母恼畔⑻?/p>

示，若運行遇到不可恢復的系統(tǒng)錯誤，也必須保證數(shù)據(jù)庫完好無損。

7．其它需求

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

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

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

8. 附錄

1. 車輛類型

篇(5)

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

裝備主動式保障系統(tǒng)需求建模

對象模型

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

動態(tài)模型

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

功能模型

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

各功能子系統(tǒng)信息流程

篇(6)

關(guān)鍵詞：學生操行管理；數(shù)據(jù)庫；MySQL

1.概述

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

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

2.數(shù)據(jù)庫系統(tǒng)設計

2.1系統(tǒng)需求

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

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

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

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

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

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

6）能錄學生作業(yè)完成情況；

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

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

9）能自動完成每周、每學期考勤、作業(yè)、勞動等表現(xiàn)的匯總瀏覽；

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

2.2數(shù)據(jù)表的設計原則

本數(shù)據(jù)庫的設計，遵循一事一地的原則，每一數(shù)據(jù)表只記錄某類實體的原始數(shù)據(jù)，數(shù)據(jù)的匯總統(tǒng)計，均采用視圖形式予以實現(xiàn)。

2.3系統(tǒng)的數(shù)據(jù)字典

根據(jù)系統(tǒng)需求及設計原則，本系統(tǒng)各數(shù)據(jù)表如下表所示。

2.4系統(tǒng)E-R圖

根據(jù)系統(tǒng)需求，數(shù)據(jù)字典，繪制本數(shù)據(jù)庫E-R圖，如下圖所示，圖中使用矩形表示實體，菱形表示聯(lián)系，線條用于連接。

2.5數(shù)據(jù)表設計

根據(jù)E-R圖，本數(shù)據(jù)庫創(chuàng)建了多個數(shù)據(jù)表，部分數(shù)據(jù)表結(jié)構(gòu)如下。

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

2）學期表：tid（int，not null，auto_increment，主鍵），學期（int，1），學年（varchar，20），開始日期（date），結(jié)束日期（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，指勞動完成表現(xiàn)，操行項目表id）。

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

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

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

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

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

篇(7)

關(guān)鍵詞：需求側(cè) 管理系統(tǒng)

1 引言

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

2 電力需求側(cè)管理系統(tǒng)的需求分析及總體設計

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

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

2.3 總體設計 系統(tǒng)框架結(jié)構(gòu)如下圖：

如圖2-1電網(wǎng)的需求側(cè)管理系統(tǒng)整體框架結(jié)構(gòu)所示系統(tǒng)主要建立在地市電廠、關(guān)口電表、主要樞紐配電所、配變終端和用戶負荷側(cè)等關(guān)鍵電能量采集點的基礎之上的，在供、售、購電三個關(guān)鍵環(huán)節(jié)點上實現(xiàn)一體化管理，將用電負荷終端數(shù)據(jù)集中存儲分析；并且構(gòu)建出電能量采集一體化系統(tǒng)，對電廠、各級配變終端、用戶負荷側(cè)等電能量數(shù)據(jù)實現(xiàn)實時采集。

3 電力需求側(cè)管理系統(tǒng)的研究與實現(xiàn)

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

3.2 數(shù)據(jù)庫/應用服務器設計 采用三層分層分布式數(shù)據(jù)結(jié)構(gòu)后，底層數(shù)據(jù)庫及應用層數(shù)據(jù)庫服務器承擔著相應電力系統(tǒng)企業(yè)營銷業(yè)務線數(shù)據(jù)邏輯處理分析及運算的主要任務。

3.3 前置服務器設計 前置服務器主要完成整個需求側(cè)管理系統(tǒng)的通信、邏輯數(shù)據(jù)解析，實現(xiàn)用戶側(cè)終端數(shù)據(jù)及配變電能數(shù)據(jù)采集與系統(tǒng)終端數(shù)據(jù)聯(lián)系控制管理功能，應采用兩臺主備服務器，操作系統(tǒng)采用Linux系統(tǒng)構(gòu)成雙機主備結(jié)構(gòu)，提高系統(tǒng)可靠性。

3.4 備份系統(tǒng)設計

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

3.4.2 備份系統(tǒng)組成。備份系統(tǒng)是由備份系統(tǒng)管理軟件，備份管理后備服務器以及硬件構(gòu)成的。

4 總結(jié)

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

參考文獻：

[1]劉磊.新型需求側(cè)管理系統(tǒng)特點解析[J].華北電力技術(shù)，2009（01）.

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

[3]胡江溢，王鶴，周昭茂.電力需求側(cè)管理的國際經(jīng)驗及對我國的啟示[J].電網(wǎng)技術(shù)，2007（18）.

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