第五屆北大青鳥杯全國IT精英挑戰賽全國一等獎項目——智慧水務管理系統
需求分析說明書
作者:武漢宏鵬田超凡
版權所有,轉載請註明原作者,仿冒侵權必究法律責任
編號:BDQN-WHHP 版本:1.0
目錄
3.1 功能描述 ...................................................................................................................7
3.2.2 二期開發模塊
3.2.3.4 運行調度.........................................................................................................11
3.2.3.5 管網模型.........................................................................................................12
1.1目的
水是居民生活重要的物資,水務管理的效率直接影響到居民的幸福指數。但是隨着經濟的發展,傳統的水務管理業務流程繁瑣,辦公效率低等問題凸顯,爲了提供水服務的公司如水利局、自來水公司、水資源管理公司提供系統化的解決方案,特此開發了本系統。
1.2 定義、簡寫和縮略語
編號 |
縮寫、術語 |
解 釋 |
1. |
建模語言 |
用語法和語義定義的、用來表示模型的語言。一些建模語言還有一些 實用規則。 |
2. |
UML |
Unified Modeling Language 統一建模語言,是一種建模語言,是第三 代用來爲面向對象開發系統的產品進行說明、可視化和編制文檔的方 法,已正式成爲進行軟件分析和設計方法的信息技術的國際標準。 |
3. |
用戶 |
指運行系統或者直接與系統發生交互作用的個人或集團。 |
4. |
迭代 |
迭代包括產生產品發佈(穩定、可執行的產品版本)的全部開發活 和要使用該發佈必需的所有其他外圍元素。所以,在某種程度上 發迭代是一次完整地經過所有工作流程的過程:(至少包括)需求 作流程、分析設計工作流程、實施工作流程和測試工作流程。 |
5. |
用例 |
從一個外部角色的角度描述如何使用系統。用例說明了系統的功能, 並且是用外部角色、用例和被建模的系統的角度來描述。用例應該對 某個特定角色產生一個可見的結果。 |
6. |
前置條件 |
在操作被執行前必須爲真的條件。 |
7. |
後置條件 |
在操作完成後必須爲真的一個條件。 |
8. |
擴展 |
在用例之間的一種通用關係,其中一個用例通過增加動作把另一個用 例擴展成一個更通用化的用例。擴展用例可能包含被擴展的用例(依 擴展的條件而定) |
9. |
優先級 |
5 最高、4 高、3 中、2 低、1最低。 |
10.
|
富文本編輯器
|
富文本編輯器, Rich Text Editor, 簡稱 RTE, 它提供類似於 Microsoft Word 的編輯功能,可以幫助用戶在瀏覽器中設置各種文本格式。 |
11. |
流程圖 |
本文專指業務流程圖, 就是用一些規定的符號及連線來表示某個具體業務處理過程。業務流程圖的繪製基本上按照業務的實際處理步驟和過程繪製。 |
表 1.2
1.3 綜述
本文檔第一部分爲引言,主要介紹需求規格說明書的背景內容;第二部分爲項目的總體描述,第三部分是系統具體需求說明和用例說明。
2 總體描述
2.1 產品描述
背景隨着計算機技術、網絡通訊技術以及電力系統保護及自控技術的發展,變電站的自動化水平不斷提高,大大減少了人爲操作事故,使變電站的無人值守逐步變成了可能,並已成爲電業系統的發展趨勢。目前已實現了將生產現場的設備運行數據、狀態傳送到遠方的監控中心,同時監控中心也可對遠程的現場設備進行控制和調節,電力系統內各種生產設備類型複雜,數目巨大,地域分佈廣,人工維護困難。同時,爲適應減員增效和現代化管理的要求,對生產現場的閉路電視監控系統在可靠性、易用性及易維護性,尤其對遠程監控方面提出了更高的要求。
針對當前情況,智慧水務系統致力於爲客戶提供更優的解決方案,推出了一套完整的智慧監控系統,通過智慧化管理平臺,對設備的監控、整體優化等技術措施,實現運行監視、操作與控制、信息綜合分析與智能告警和自動化管理等功能,爲客戶提供更好的方案解決實際問題。
2.2 產品功能(一期)
圖 2.2產品功能
2.2 產品功能(二期)
2.3 用戶特點
用戶分爲:巡檢用戶、採購用戶、水務經理、水務總監四類。水務經理和水務總監擁有本系統的所有權限,二者權限區別在於審覈額度不同。
3 功能性需求
3.1 功能描述
智慧水務系統主要有8大功能模塊:巡檢管理、設備管理、系統維修、爆管監控、G-S-M管理、SCADA管理、運行調度、管網模型
3.2 流程描述
3.2.1 一期開發模塊
3.2.1.1 巡檢管理
用例說明:
內容 |
說明 |
用例名稱 |
巡檢管理 |
主要參與者 |
巡檢用戶、水務經理、水務總監 |
簡要說明 |
巡檢人員完成巡檢任務,管理人員管理巡檢計劃和任務 |
事件流 |
1、 登錄系統 2、 進入巡檢管理列表頁面 3、 進行查詢、修改操作 |
前置條件 |
登錄後並具有該操作權限 |
後置條件 |
更改用戶信息,保存到數據庫 |
非功能需求 |
無 |
擴展點 |
無 |
優先級(數值 越大優先級越 低,下同) |
2 |
說明 |
無 |
表 3.2.1.1
3.2.1.2 設備管理
用例說明:
內容 |
說明 |
用例名稱 |
設備管理 |
主要參與者 |
水務經理、水務總監 |
簡要說明 |
用於管理員維護設備管理信息。 |
事件流 |
無 |
前置條件 |
登錄後並具有該操作權限 |
後置條件 |
保存到數據庫 |
非功能需求 |
無 |
擴展點 |
無 |
優先級(數值 越大優先級越 低,下同) |
2 |
說明 |
無 |
表 3.2.2.1
3.2.1.3 系統維護
用例說明:
內容 |
說明 |
用例名稱 |
系統維護 |
主要參與者 |
水務經理、水務總監 |
簡要說明 |
用於管理員維護派工單信息 |
事件流 |
無 |
前置條件 |
登錄後並具有該操作權限 |
後置條件 |
保存到數據庫 |
非功能需求 |
無 |
擴展點 |
無 |
優先級(數值 越大優先級越 低,下同) |
2 |
說明 |
無 |
表 3.2.2.3
3.2.2 二期開發模塊
3.2.2.1 爆管監控
用例說明:
內容 |
說明 |
用例名稱 |
爆管監控 |
主要參與者 |
水務經理、水務總監 |
簡要說明 |
監測和管理爆管數據、儀器管理和數據統計分析 |
事件流 |
無 |
前置條件 |
登錄後並具有該操作權限 |
後置條件 |
保存到數據庫 |
非功能需求 |
無 |
擴展點 |
無 |
優先級(數值 越大優先級越 低,下同) |
2 |
說明 |
無 |
3.2.2.2 G-S-M管理
用例說明:
內容 |
說明 |
用例名稱 |
G-S-M管理 |
主要參與者 |
水務經理、水務總監 |
簡要說明 |
監測和管理泵站和測點數據並進行數據分析 |
事件流 |
無 |
前置條件 |
登錄後並具有該操作權限 |
後置條件 |
保存到數據庫 |
非功能需求 |
無 |
擴展點 |
無 |
優先級(數值 越大優先級越 低,下同) |
2 |
說明 |
無 |
3.2.2.3 SCADA管理
用例說明:
內容 |
說明 |
用例名稱 |
SCADA管理 |
主要參與者 |
水務經理、水務總監 |
簡要說明 |
監測和管理泵站和測點數據及屬性、報表管理、數據統計分析 |
事件流 |
無 |
前置條件 |
登錄後並具有該操作權限 |
後置條件 |
保存到數據庫 |
非功能需求 |
無 |
擴展點 |
無 |
優先級(數值 越大優先級越 低,下同) |
2 |
說明 |
無 |
3.2.3.4 運行調度
用例說明:
內容 |
說明 |
用例名稱 |
運行調度 |
主要參與者 |
水務經理、水務總監 |
簡要說明 |
對方案和設備等信息進行管理維護 |
事件流 |
無 |
前置條件 |
登錄後並具有該操作權限 |
後置條件 |
保存到數據庫 |
非功能需求 |
無 |
擴展點 |
無 |
優先級(數值 越大優先級越 低,下同) |
2 |
說明 |
無 |
3.2.3.5 管網模型
用例說明:
內容 |
說明 |
用例名稱 |
管網模型 |
主要參與者 |
水務經理、水務總監 |
簡要說明 |
管理告警數據、溫溼度監測、供水統計、泵站工藝圖管理 |
事件流 |
無 |
前置條件 |
登錄後並具有該操作權限 |
後置條件 |
保存到數據庫 |
非功能需求 |
無 |
擴展點 |
無 |
優先級(數值 越大優先級越 低,下同) |
2 |
說明 |
無 |
4 非功能性需求
在這一部分應對所有的軟件需求進行足夠詳細的描述。詳盡程度應以足夠軟件
設計人員進行概要設計和系統測試人員進行系統測試計劃和編寫測試用例爲準。
4.1 技術需求
4.1.1 軟硬件環境需求
硬件需求: Web Server DBServer1(write) , DBServerR1(read), DBServerR2(read)
共3臺服務器。服務器配置如下:
CPU:4 核或8核
內存:8-16G
硬盤:500G
遠程控制卡
軟件需求:
帶寬:10M 或者100M
Java運行環境:JDK1.6以上
WebApplicationServer:Tomcat1.6 以上
DataBase:Oracle10.0
Memcache
Nginx1.4.2 (穩定版)
4.1.2 產品性能
系統需滿足以下性能:
最大併發用戶數 500人/次
最大同時在線人數 1000人/次
最大同時提交事務人數 50人/次
高峯時期系統響應時間 3~5秒
4.1.3 安全性
系統需滿足國家保密部門要求的分級保護中機密級信息系統設計的相關要求,
並採取必要的技術手段從應用開發層面保證數據的安全。
4.2 質量需求
4.2.1 可靠性
系統具有大量的數據統計彙總和查詢分析要求,因此,必須確保數據彙總、統
計、查詢分析的更準確有效。系統必須具備較強的可靠運行設計,可應對單點故障。保證數據安全,包括數據級備份與災難性恢復。
4.2.2 靈活性
系統要採用先進的技術,保證可靈活地按照不同方式組織其內部模塊,從而適
應不同網絡規模、不同個性化需求和不同組織模式。
4.2.3 兼容性
系統必須具有高度的可擴展性,能夠在規模、功能、性能三個方面進行擴展,
以適應應用和技術發展的需要,特別是對省(區、市)應用系統及其他紀檢監察業務系統的擴展。系統必須開發維護中心,使整個系統的管理維護工作量以及開銷較小,並提供完備的運行管理解決方案,包括性能、安全、統計、配置管理等。
4.2.4 易用性
須保證系統的易用性。具體可以通過以下方式保障系統的易用性:
1) 通過提供統一的信息門戶,使多種渠道的信息方便接入,並提供一致的渠
道服務手段。
2) 針對不同類型的用戶設計集成的用戶界面,保證用戶能夠方便快捷的使用
自己需要的常用功能。
3) 遵循統一的界面設計規範,在應用程序編碼階段監督編碼人員認真執行規
範,以做到:界面風格一致、顏色調和、提示清晰、窗口大小適當,提供常用
的快捷操作鍵,操作方法應符合日常習慣。
4.3 文檔需求
交付驗收時需交付的文檔清單:
《需求分析說明書》
《軟件開發計劃》
《概要設計說明書》
《詳細設計說明書》
《軟件測試計劃》
《測試用例》
《配置管理計劃》
4.4 設計約束
詳細說明對系統的設計侷限性。設計侷限的定義代表了對系統要求的決策, 這可
能出於商務運作、資金、人員、時間等多方面的綜合考慮從而指導軟件的設計和開
發。例如,軟件的開發語言、開發環境、開發工具、第三方軟件、 硬件使用以及網
絡設備等。
4.4.1 語言約束
本系統是基於中文系統環境開發和使用的,系統必須支持中文處理。
4.4.2 系統模型約束
本系統採用 MVC 模型,在保證實現技術簡單易維護的基礎上,實現表現層和
業務邏輯層的分離,提高可重用性、可移植性。
5 驗收標準
智慧水務管理系統驗收標準爲:
Ø 實現所有功能需求
Ø 滿足非功能性需求
Ø 系統設計文檔完整,且符合規範
Ø 代碼符合規範,且與系統設計一致
此要求將作爲驗收測試計劃和測試的基線。如果所開發的產品能滿足此要求,
則項目可結束並由客戶方按合同規定付款。