任務描述
知識點：需求分析
重? 點：原型設計工具，用例圖，流程圖繪制工具
難? 點：功能點的梳理
內? 容：完成本次實訓項目的需求分析
- 先共同討論處本項目的主要功能模塊，并確定每個模塊的負責人（第一天完成，截止到晚上12點需要提交項目整體模塊圖，第二天上午在云平臺上可供老師查看）
- 第2天分工完成每個功能模塊的需求和原型設計
- 第3天匯總再集中每個模塊之間的相關性，調整完善項目的需求和原型
任務指導
1、掌握用例圖,ER圖，UML圖的繪制工具，推薦使用在線工具
- 如果之前已經安裝過其他工具，可以使用，如果沒有安裝過，推薦使用processon在線工具，注冊后即可使用
- 注冊地址：568***54e邀請您加入Processon-1.1億人都在用的在線作圖工具_ProcessOn思維導圖流程圖
2、項目的用戶需求及相關資料請從“資料”中下載使用。
任務實現
一、分組實施
- 先共同討論項目的主要功能模塊，并確定每個模塊的負責人（第一天完成，截止到晚上12點需要提交項目整體模塊圖，第二天上午在云平臺上可供老師查看）
- 第2天分工完成每個功能模塊的需求和原型設計
- 第3天匯總再集中每個模塊之間的相關性，調整完善項目的需求和原型
二、需求分析（此處僅供參考，實際請根據用戶需求及相關資料完成需求分析設計和原型設計）
0.?文檔介紹
0.1?文檔目的
本文檔對民航項目需求進行文檔化整理，主要目的是：
- 作為產品需求組和開發組進行需求評審的基礎文檔
- 作為開發組進行產品設計和產品測試的基礎
- 作為交付物的必須的組成部分交付給客戶
0.2?文檔范圍
提示：描述本文檔的范圍，即本文檔包含了哪些內容。
?本文檔包含項目的基本介紹，包括項目的背景，范圍，所使用的環境等，還對項目的整體功能進行詳細的描述，包括流程圖和各部分的功能介紹，查詢條件，顯示字段等。
0.3?讀者對象
提示：描述編寫本文檔的讀者對象。
本文檔適合民航項目項目經理、開發人員、測試人員、實施工程師等，有必要了解民航大數據的人員閱讀。
0.4?參考文檔
提示：列出本文檔的所有參考文獻（可以是非正式出版物），格式如下：
[標識符]?作者，文獻名稱，出版單位（或歸屬單位），日期
例如：
[SPP-PROC-PP] SEPG，需求開發規范，機構名稱，日期
0.5?術語與縮寫解釋
| 縮寫、術語 | 解?釋 |
| … |
1.?項目概述
1.1 產品介紹
提示：
（1）說明產品是什么，什么用途。
（2）介紹產品的開發背景。提供關于發起這個軟件開發的業務組織的概要，包括業務組織的使命及業務目標
本項目是用于民航行業一個應用，主要用于管控收集各民航機構上報的雷達數據、航班數據、飛行數據據等，并對其進行標準化處理，形成合理有用的民航數據，通過大數據技術對民航數據進行處理分析，形成各種分析報告和圖表，并展示給不同需求的客戶。
1.2?產品范圍
提示：描述待開發軟件產品的范圍。在描述中應該包括：
- 描述軟件產品的特征
- 介紹軟件的功能，并進行簡要說明
- 描述軟件產品“適用的領域”和“不適用的領域”，本產品“應當包含的內容”和“不包含的內容”。（做什么，不做什么）
- 說明軟件應用
- 描述軟件的相關的收益、目的和目標等
此處的描述應與之前的項目文檔的類似描述保持一致。說清楚產品范圍的好處是：（1）有助于判斷什么是需求，什么不是需求；（2）可以將開發精力集中在產品范圍之內，少干吃力不討好的事情；（3）有助于控制需求的變更。
| 航空數據管控系統項目功能表 | ||||||
| 序號 | 功能 | 模塊 | 詳細功能 | 涉及技術點 | 備注 | |
| 1 | 公共 | 需求調研 | 需求調研以及功能溝通 | |||
| 2 | 框架 | 項目開發框架搭建 | Springboot框架 | |||
| 3 | 設計 | 案例UI設計 | ||||
| 4 | 功能開發 | 大數據開發 | 準備環境 | 搭建集群環境：Hadoop、HBase、Kafka、Spark、MySQL | Hadoop生態 | |
| 5 | 創建數據庫表 | 航空公司表、機場列表、管制人員表、AFTN報文表、綜合航跡數據表數據等 | ||||
| 6 | 數據采集 | 基礎數據表創建和數據導入，存入HBase數據庫 | ||||
| 7 | AFTN報文、雷達數據、航跡數據模擬生成器程序 | |||||
| 8 | 獲取數據到Kafka | |||||
| 9 | 整合Kafka | 配置Kafka參數 | ||||
| 10 | 創建不同的topic | |||||
| 11 | Spark清洗和統計 | Spark環境參數配置 | ||||
| 12 | 數據融合成綜合航跡數據（集合不同的數據進行規則融合） | |||||
| 14 | 相似航班號告警（根據規則告警） | |||||
| 15 | 相撞危險告警（根據規則告警） | |||||
| 19 | 清洗后數據存儲到MySQL | |||||
| 20 | Spark任務 | 對機場、航空公司的航班數量進行統計，將統計結果保存進 Mysql | ||||
| 21 | 獲取航線統計 | |||||
| 22 | 機場負荷統計 | |||||
| 24 | 告警統計 | |||||
| 25 | 扇區架次動態 | |||||
| 26 | 各扇區通話飽和度 | |||||
| 27 | 沖突指令告警分析 | |||||
| 28 | 指揮航空架次占比 | |||||
| 29 | 航空公司架次和延誤率占比 | |||||
| 30 | 扇區架次數 | |||||
| 31 | 大屏開發 | 展示UI界面（首頁和實時飛行監控） | ||||
| 32 | 開放API開發 | |||||
| 33 | 對接后端Api接口并在此基礎上計算和聚合 | |||||
| 34 | ||||||
| 35 | 測試 | 測試相關模塊功能 | 對所有模塊進行全面測試 | |||
| 36 | 培訓 | 錄制培訓介紹視頻和給學生培訓 | 錄制學生操作視頻和培訓視頻 | |||
| 37 | 文檔整理 | 用戶需求文檔，教師指導手冊，實例指導手冊，數據庫設計文檔，數據集，完整的鏡像 | 整理滿足教學用的需求和手冊 | |||
1.3 用戶群體及角色
提示：
（1）描述本產品面向的用戶（客戶、最終用戶）的特征。
（2）說明本產品將給他們帶來什么好處？他們選擇本產品的可能性有多大？
（3）根據用戶的特征，按照功能、位置和設備類型等識別每一類用戶。明確每一類型的用戶的數量，以及他們使用軟件的特點。根據這些特點劃分產品中定義的角色及其工作職責，填寫在下表中，各種角色的具體行為將在功能性需求中描述。軟件產品用戶的特征會影響特定的需求。許多人在軟件生命周期的運行和維護階段使用軟件。這些人是用戶、操作員、系統維護人員。這些人的某些特點，如教育水平，經驗和技術專長，可能成為軟件的運行環境的重要制約因素。
| 角色名稱 | 職責描述 |
| 項目教學者 | 了解整個項目的情況和功能情況并可通過個人理解講解整個項目 |
| 項目開發者 | 了解整個項目的大致情況，并能根據功能設計數據庫和開發功能 |
1.4?運行環境
提示：描述軟硬件運行環境。包括硬件平臺、操作系統和版本，以及用戶、服務器和數據庫的地理位置。列出系統必須和平共存的其他軟件組件或應用程序，前景和范圍文檔中可能包含這樣的高層信息。
| 需求名稱 | 詳細要求 |
|---|---|
| 硬件 | 需要3臺服務器或虛擬機，3臺部署大數據集群，其中1臺用于發布 |
| 每臺配置（最小配置） | CPU：8核?內存：16G?硬盤：100G ? |
| … |
1.5?假設、依賴和約束
提示：列舉軟件產品的假設、依賴和約束。但不是每個產品都同時具備這三個條件。
? ? 假設?描述那些影響在軟件需求說明書描述的需求的假設。假設是那些在項目的生命周期中被認為是真的因素，如果這種假設改變，會對項目產生負面的影響，包括但不限于最終用戶的特點，已知的技術基礎設施，資源可用性和資金可用性等。
依賴?描述那些影響在軟件需求說明書中描述的需求的依賴。依賴是指在項目的范圍和控制之外，并且為了項目取得成功而必須為真的情況。舉例來說，一個依賴可能是一個應用程序依賴于一個不同的應用提供具體的數據或者是一個與第三方應用程序的接口需要購買一個應用程序編程接口（API）。
約束?提供各種限制軟件的范圍和功能的因素的描述，包括但不限于行業標準與規范，業務規則，監管政策，基礎設施的限制，資源和許可。約束是通過環境、權利或強制規定施加到解決方案上的限制。約束通過無法改變的邊界及限制，制約了解決方案的設計師可供選擇的方案。
2.?產品的功能性需求
2.1?整體業務流程圖／用例圖
提示：以結構化或面向對象的方法繪制出產品整體業務的流程圖或用例圖。
2.2?功能性需求分類
提示：將功能性需求先粗分再細分，下表中的?功能 A,?功能 A.1等符號應當被替換成有含義的名稱。
| 功能類別 | 子功能 |
|---|---|
| 數據采集A | 基礎數據導入，數據存儲到hbase |
| AFTN報文、雷達數據、航跡數據模擬生成器程序 | |
| Spark清洗和統計B | 數據融合成綜合航跡數據（集合不同的數據進行規則融合） |
| 相似航班號告警（根據規則告警） | |
| 相撞危險告警（根據規則告警） | |
| 清洗后數據存儲到MySQL | |
| 對機場、航空公司的航班數量進行統計，將統計結果保存進 Mysql | |
| 獲取航線統計 | |
| 機場負荷統計 | |
| 告警統計 | |
| 扇區架次動態 | |
| 各扇區通話飽和度 | |
| 沖突指令告警分析 | |
| 指揮航空架次占比 | |
| 航空公司架次和延誤率占比 | |
| 扇區架次數 | |
| 統計分析展示C | 展示UI界面（首頁和實時飛行監控） |
| 開放API開發 | |
| 對接后端Api接口并在此基礎上計算和聚合 |
2.3?數據采集
2.3.1 基礎數據表創建和數據導入
提示：當采用功能分解的方式描述功能性需求的時候，可按照2.3.xf的模板描述所有的子功能。需要按照具體的功能標識及命名每一個功能，其中xf是子功能序號，X是功能的名稱。
??????? 按照空管數據庫設計文檔，建立標準數據庫，再將原始的數據進行導入，形成初始版本的數據庫，保證數據移植正常，數據不丟失。并將數據存儲到HBase數據庫中。
2.3.2 AFTN報文、雷達數據、航跡數據模擬生成器程序
由于無法接入真實的民航數據接口，再根據民航日常數據實際情況，對AFTN報文、雷達數據、航跡數據進行模擬生成，可以做到模擬接收數據，供接下來數據的清洗和分析使用。
AFTN/SITA報文：AFTN全稱為民用航空飛行動態固定電報格式，SITA為航空公司使用的電報，都是飛行動態固定格式電報。兩種格式不能混合使用。
2.4?Spark清洗和統計
2.4.1 數據融合
將不同的原始數據讀取到kafka中，傳入spark中，進行融合，產出綜合航跡數據。提供給前端使用。并對扇區增加電子圍欄，當飛機進入電子圍欄后進行提示。
2.4.2 相似航班號告警
根據航班號判別規則，將相似的航班號進行甄別，提取，并向前臺發送告警信息，通知相關操作人員注意相似航班號，避免誤操作。
2.4.3 相撞危險告警
根據航線，航跡，高度數據，判斷飛機路線是否有相撞危險，如果存在危險，進行通知告警，相關人員，進行操作處理，避免危險發生。
2.4.4 清洗后數據存儲到MySql
將數據進行清洗，將清洗后的數據存儲到MySql數據庫，以提供api接口等功能調取，查看統計數據。
2.4.5 獲取航線統計
為方便機場和各航空公司直觀了解某一時段內各航空公司的境內和跨境進出港航線數據情況，提供對未來航線布局和安排的數據依據，將所有航線進行統計、展示。將航線按照起飛地、將落地、時間分類，行程數據，由前端echarts圖表展示。
2.4.6 機場負荷統計
主要是計算出機場的起飛架次，降落架次。此部分數據對于提高機場運行效率和運作精細化管理水平具有重要意義，根據日起落架次可以評估出機場規劃設計和運行管理的標準。前臺統計需按照航空公司聚合，統計起飛架次，降落架次。
2.4.7 告警統計
將告警信息按照扇區進行分類統計，可以直觀看到哪個扇區產生的告警數量較多，有幫助扇區改善交通流量，規范管制指令的作用。
2.4.8 扇區架次動態
空中交通管制扇區是空域運行的基本單元，扇區的通行能力在一定程度上反應了扇區的服務水平，將扇區的架次動態統計出來，是對扇區通行能力的有效評估方式。可以減少航班延誤，促進空中交通流的順暢有序。
2.4.9 各扇區通話飽和度
隨著空中交通流量的激增和管制運行規模的擴大，管制員工作負荷在不斷增加，扇區通話飽和度直接反映出這一問題，對于機場而言，可以更加有效的調整扇區狀態，調整管制員工作，間接的決定了管制扇區的容量以及運行安全與效率。
2.4.10 沖突指令告警分析
每日管制人員會發出大量的航空指令，對于這些指令會出現相互沖突，將沖突指令記錄并分析，行程提示信息，對幫助管制人員提高管制能力有非常積極的作用。
2.4.11 指揮航空公司架次占比
將指揮過的飛機架次按照航空公司分類統計，并計算出延誤率。通過這項統計可以有效提高管制人員業務能力。
2.4.12 扇區架次數
為了保障扇區負荷平均，管制員工作強度維持在合理范圍內，間接保障飛行安全，將飛機起落架次數，按照扇區分類，統計顯示，動態安排扇區的使用。
2.5?統計分析
2.5.1 展示UI界面（首頁和實時飛行監控）
1.登錄：
用戶通過輸入用戶名和密碼進行登錄，后臺驗證用戶名密碼是否正確，如果不正確給出提示，并且通過后臺下發用戶權限，進入系統后，會根據用戶角色權限顯示不同的統計數據板塊，進行展示。
????????
2.數據統計：
將扇區架次、動態航線圖、扇區架次數、扇區通話飽和度，扇區架次數、年度告警統計、指揮航空公司架次、沖突指令告警在首頁進行展示。表格數據均采用echarts進行展示。
3.航空實時監控
實時顯示扇區內飛機位置，可以選擇不同的扇區查看軌跡數，告警數，扇區內相似航班號提醒以及對管制指令進行糾錯。有告警的航班會變紅，提示管制員加以注意。
2.5.2 開放API開發
為保證第三方應用的數據統一，數據正確，為其提供統一的數據接口，并且進行權限和時效驗證。
調試后臺提供的Api接口，并且根據實際情況在前臺進行數據調整，計算重新在頁面上進行展示。首先要向后臺發送token進行校驗，獲得數據后，進行合理的數據整理，字段對應。綁定頁面數據，顯示。
3.?產品的非功能性需求
3.1?用戶界面需求
提示：描述軟件的用戶界面需求。用戶界面需求用于捕獲應用程序的人機界面的預期行為。例如，如果用戶通過顯示終端操作，說明所需的屏幕內容，任何報告或菜單的內容，輸入和輸出的相對時間。用戶需求可能包括示例的屏幕或報表格式為原型來進行需求的說明。
| 需求名稱 | 詳細要求 |
| … |
3.2?性能需求
提示：描述性能條件以及相關的能力。考慮因素包括：
- 發生的動態行為或變化（如比率，速率，運動和噪聲水平）
- 涵蓋設備的承受能力的量化標準，用于在規定的環境和其他條件下滿足用戶的需求，包括最低總壽命。說明了需要的持續運行時間以及計劃的可用率。
- 運行的階段和模式的性能需求
- 支持的終端數量
- 支持9?的并發用戶數量
- 在正常以及峰值負載的條件下，特定時間內可以處理的事務和任務以及數據量
- 在非正常的工作壓力下可接受的性能
3.3?產品質量需求
提示：描述軟件的質量特性的需求。需求的描述應該是可度量、可驗證的。描述在特性之間（比如安全性和可移植性）之間的權衡關系。質量特性的定義包括正確性、有效性、靈活性、完整性/安全、互操作性、可維護性、可移植性、可靠性、可重用性、可測試性、易用性。
| 主要質量屬性 | 詳細要求 |
|---|---|
| 正確性 | |
| 健壯性 | |
| 可靠性 | |
| 性能，效率 | |
| 易用性 | |
| 清晰性 | |
| 安全性 | |
| 可擴展性 | |
| 兼容性 | |
| 可移植性 | |
| … |
3.4?其他需求
提示：描述不適合放在前面需求章節中的任何其他的需求。如有些軟件系統比較強調信息管理需求、安全需求，也可以在此擴展。
4.?接口
提示：描述應用和其他軟件、硬件以及通信協議之間的接口的邏輯特性。每個接口的描述包括：
- 該接口的目的
- 應用接口對應的系統，包括外部的或內部的
- 交換機制
附錄A：需求建模與分析報告
建議用Rational Rose對產品需求進行建模與分析。
A.1?需求模型1
A.n?需求模型N
附錄B：需求跟蹤矩陣
提示：提供指向需求跟蹤矩陣的鏈接，需求跟蹤矩陣中說明了在系統需求規格說明中的系統需求、在本軟件需求規格說明書中的軟件需求以及系統設計中的設計元素之間的對應關系。SRS中的需求跟蹤矩陣應該：
- 含有用來說明系統需求與系統設計、軟件需求、軟件設計等元素之間的可追溯性的列
- 含有用來說明集成、驗收、回歸、性能測試等的可追溯性的列
- 填入了所有記錄在系統需求規格說明中的需求
- 填入了所有記錄在系統設計中的設計項
- 填入了所有記錄在需求規格說明書中的需求項
- 說明了系統規格說明書中的系統需求與系統設計中的設計項之間的對應關系
- 說明了系統設計中的設計項與需求規格說明中的需求的對應關系
- 說明了每一個需求的出處及來源
附錄C：需求確認
提示：主要分兩步：（1）需求評審，（2）需求承諾。對需求的評審應當采用“正式技術評審方式”，將產生一份“需求評審報告”。在獲取責任人（Stakeholders）對需求的承諾之前，該《產品需求規格說明書》必須先通過需求評審。
| 需求評審報告摘要 | |
|---|---|
| 需求文檔 | 輸入名稱，標識符，版本，作者，完成日期，… |
| 需求評審報告 | 輸入名稱，標識符，評審日期，… |
| 評審結論 | [? ]?工作成果合格，“無需修改”或者“需要輕微修改但不必再審核”。 [√]?工作成果基本合格，需要作少量的修改，之后通過審核即可。 [? ]?工作成果不合格，需要作比較大的修改，之后必須重新對其評審。 |
| 評審意見 | |
| 評審小組成員 | 輸入評審小組成員 |
| 需求承諾 | |
|---|---|
| 需求文檔 | 輸入名稱，標識符，版本，作者，完成日期 |
| 客戶承諾 | 承諾… 簽字，日期 |
| 項目經理承諾 | 承諾… 簽字，日期 |
)
