任务描述
从用户的角度阐述项目的开发背景、使用范围及功能需求，从而指导学生独立完成项目的设计与开发。
任务指导
目录
| 标题 | 内容 | 备注 |
|---|---|---|
| 1. 项目概述 | 1.1 项目背景介绍 | （1）说明产品是什么，什么用途 （2）介绍产品的开发背景。提供需求方的组织概要，包括组织使命及业务目标 |
| 1.2 产品使用范围 | （1）描述软件产品的特征，对软件的功能进行简要说明 （2）描述软件产品“适用的领域”和“不适用的领域”（即，要做什么，不做什么） （3）说明软件应用，描述软件的相关的收益、目的和目标等 | |
| 1.3 用户群体及角色 | （1）描述本产品面向的用户（客户、最终用户）的特征。 （2）根据用户的特征，按照功能、位置等识别每类用户，划分产品中定义的角色及其工作职责 | |
| 1.4 项目运行环境说明 | （1）描述软硬件运行环境。包括硬件平台、操作系统和版本，以及服务器和数据库的地理位置 （2）列出系统必须和平共存的其他软件组件或应用程序 | |
| 1.5 假设、依赖和约束 | （1）假设：在项目的生命周期中被认为是真的因素，如果这种假设改变，会对项目产生负面的影响，包括但不限于最终用户的特点，已知的技术基础设施、资源可用性等。 （2）依赖：在项目的范围和控制之外，并且为了项目取得成功而必须为真的情况。例如，一个应用程序依赖于一个不同的应用提供的数据或者第三方应用程序的接口 （3）约束：提供各种限制软件的范围和功能的因素的描述，包括但不限于行业标准与规范，业务规则，监管政策，基础设施的限制，资源和许可。 | |
| 2. 产品功能性需求 | 2.1 整体业务流程 | 以结构化或面向对象的方法绘制出产品整体业务的流程图或用例图。 |
| 2.2 功能性需求分类 | 将功能性需求进行粗分 | |
| 2.3 功能性需求详解 | 将功能性需求进行细分 | |
| 3. 产品非功能性需求 | 3.1 用户界面需求 | 用户界面需求用于捕获应用程序的人机界面的预期行为。例如，用户通过显示终端操作，所需的屏幕内容，任何报告或菜单的内容，输入和输出的相对时间。 |
| 3.2 产品性能需求 | （1）涵盖设备的承受能力的量化标准，用于在规定的环境和其他条件下满足用户的需求，包括最低总寿命。说明了需要的持续运行时间以及计划的可用率 （2）运行的阶段和模式的性能需求，支持的终端数量，支持的并发用户数量 （3）在正常以及峰值负载的条件下，特定时间内可以处理的事务和任务以及数据量，在非正常的工作压力下可接受的性能 | |
| 3.3 产品质量需求 | 质量特性的定义包括正确性、有效性、完整性/安全、可维护性、可移植性、可靠性、可重用性、可测试性、易用性等 | |
| 4. 扩展功能性需求 | 4.1 扩展功能需求分类 | 描述不在前面需求章节中的任何其他的需求。如信息管理需求、安全需求，可以在此扩展 |
| 4.2 扩展功能需求详解 | 将扩展功能性需求进行细分 |
======================================= 华丽的分割线 =======================================
1. 项目概述
1.1 产品介绍
当今社会，“大数据”已经不再是令人陌生的一个词汇，特别是在国家大数据与“互联网+”战略下，大数据、移动互联网、物联网、云计算等新兴技术正在快速增长与发展，大数据时代已经正式到来。在航空业与人们日常出行越来越紧密的大背景下，大数据在民航领域的应用也为航空公司在运营和管理方式上的改变助力。最大化地利用数据对于航空公司而言，意味着效率和效益。针对大数据对民航领域的意义，特别是在航空指挥领域的使用进行分析，可有效发掘民航的商业价值。
本项目是用于民航行业一个应用，主要用于管控收集各民航机构上报的雷达数据、航班数据、飞行数据据等，并对其进行标准化处理，形成合理有用的民航数据，通过大数据技术对民航数据进行处理分析，形成各种分析报告和图表，并展示给不同需求的客户。利用成熟的大数据技术，建立数据采集、数据挖掘和数据服务的三层架构，整合空管数据资源，提供统一且灵活的数据服务，提高数据的使用效率，降低维护和开发成本，发挥空管大数据平台的技术优势。
项目以实时提供的真实历史数据，通过大数据平台进行清洗、统计并将数据回馈给大屏指挥展示，提供多方位的数据维度图形分析，为航空指挥平台提供决策所用的数据支撑。
1.2 产品范围
项目通过研究民航空管大数据建设的相关理论和相关技术，结合当地空管数据的实际情况和特点，考虑空管、机场、航空公司的业务交互需求，以当地空管为例，建设当地地区空管大数据平台。
| 产品特征 | 以实时提供的真实历史数据，通过大数据平台进行清洗、统计并将数据回馈给大屏指挥展示，提供多方位的数据维度图形分析，为航空指挥平台提供决策所用的数据支撑 |
| 适用领域 | 民航航空指挥领域，区域性航空指挥平台 |
| 目标收益 | 整合空管数据资源，提供统一且灵活的数据服务，提高数据的使用效率，降低维护和开发成本，发挥空管大数据平台的技术优势 |
1.3 用户群体及角色
| 角色名称 | 职责描述 |
|---|---|
| 普通用户 | 执行空管、机场、航空公司的业务交互操作；对当前监管的空域进行扇区监管； |
| 管理员 | 同“普通用户” |
1.4 运行环境
| 需求名称 | 详细要求 |
|---|---|
| 硬件环境 | 需要4台服务器或虚拟机：在3台服务上部署大数据集群，并使用其中1台用于发布，另外需要1台开发服务器 |
| 硬件配置 | 每台集群服务器建议配置：CPU 8核，内存 16G，硬盘 80G；开发服务器的建议配置： CPU 4核，内存 8G，硬盘 80G |
| 操作系统 | 大数据集群服务器操作系统：CentOS 7 x64 |
| 开发工具 | 建议开发工具：IDEA、VSCode |
1.5 假设、依赖和约束
| 假设 | 项目的开发环境和运行环境需要访问外网，请确保开发和运行环境可以访问外网 |
| 依赖 | 项目中会使用到报表组件和地图组件，这些组件为商业组件，在使用过程中可能会需要注册使用，并可能会产生费用 |
| 约束 | 民航空管数据为重要敏感的隐私数据，虽然经过脱敏，但是在未经授权的情况下，禁止任何商业用途 |
2. 产品的功能性需求
2.1 整体业务流程
2.2 功能性需求分类
| 功能类别 | 子功能 |
|---|---|
| 大数据环境准备（A） | A.1 准备项目开发运行的基础集群环境 |
| A.2 安装配置当前项目所需的大数据处理组件 | |
| A.3 安装项目开发工具，并搭建项目的基础开发框架 | |
| 数据采集（B） | B.1 导入空管基础数据，分别将数据存储到MySQL和HBase |
| B.2 读取HBase中的雷达数据、AFTN报文、综合航迹数据等，并推送到Kafka | |
| Spark清洗和统计（C） | C.1 数据融合成综合航迹数据（集合不同的数据进行规则融合） |
| C.2 相似航班号告警（根据规则告警） | |
| C.3 相撞危险告警（根据规则告警） | |
| C.4 清洗后数据存储到MySQL | |
| C.5 对机场、航空公司的航班数量进行统计，将统计结果保存进 Mysql | |
| C.6 获取航线统计 | |
| C.7 机场负荷统计 | |
| C.8 告警统计 | |
| C.9 扇区架次动态 | |
| C.10 各扇区通话饱和度 | |
| C.11 冲突指令告警分析 | |
| C.12 指挥航空架次占比 | |
| C.13 航空公司架次和延误率占比 | |
| C.14 扇区架次数 |
2.2.A 大数据环境准备
A.1 准备项目开发运行的基础集群环境
项目开发测试环境为分布式集群环境，当前项目中使用多台基于CentOS 7的云主机来模拟生产环境。在生产环境中建议使用高性能物理主机或云主机搭建集群环境。
- 规划服务节点的功能和数量，以及网络分配情况
- 配置虚拟机的主机名称和网络，确保各主机之间可以通过主机名和IP互相ping通
- 配置各虚拟机之间可以SSH免密码连接
- 在各虚拟机上安装JDK并配置环境变量
A.2 安装配置当前项目所需的大数据处理组件
根据项目的用户需求和数据处理流程等判断，当前项目的大数据环境至少包括以下组件：
- Zookeeper
- Hadoop
- Spark
- HBase
- Kafka
- MySQL
- Redis
A.3 安装项目开发工具，并搭建项目的基础开发框架
当前项目的开发使用SpringBoot作为后端开发框架，使用Vue作为前端开发框架，需要根据实际情况安装配置相兼容的合适版本。
2.2.B 数据采集
B.1 基础数据表创建和数据导入
导入项目的基础数据，包括空管基础数据和离线的实时飞行数据（已经脱敏）。按照空管数据库设计文档，建立标准数据库，再将原始的数据进行导入，形成初始版本的数据库，保证数据移植正常，数据不丢失。此过程中会将基础数据存储到MySQL数据库中，将离线的实时飞行数据（data.tar.gz）导入到HBase中。
B.2 AFTN报文、雷达数据、航迹数据模拟生成器程序
由于无法接入真实的民航数据接口，再根据民航日常数据实际情况，对AFTN报文、雷达数据、航迹数据进行模拟生成，可以做到模拟接收数据，供接下来数据的清洗和分析使用。
在当前任务中会读取民航数据（在前面的步骤中已经放到HBase当中），并将数据推送到Kafka的Topic中，这样做的目的是模拟实时从民航数据实时推送到Kafka，在后续的任务中将从Kafka中获取数据。
注意：AFTN/SITA报文：AFTN全称为民用航空飞行动态固定电报格式，SITA为航空公司使用的电报，都是飞行动态固定格式电报。两种格式不能混合使用。
2.2.C Spark清洗和统计
C.1 数据融合
读取不同的原始数据并推送到Kafka，然后传入到Spark中进行融合，产出综合航迹数据保存到MySQL数据库中，提供给前端使用。例如：
C.2 相似航班号告警
根据航班号判别规则，将相似的航班号进行甄别，提取，并向前台发送告警信息，通知相关操作人员注意相似航班号，避免误操作。
C.3 相撞危险告警
根据航线，航迹，高度数据，判断飞机路线是否有相撞危险，如果存在危险，进行通知告警，相关人员，进行操作处理，避免危险发生。
C.4 清洗后数据存储到MySQL
将数据进行清洗，将清洗后的数据存储到MySQL数据库，以提供Api接口等功能调取，查看统计数据。
C.5 获取航线统计
为方便机场和各航空公司直观了解某一时段内各航空公司的境内和跨境进出港航线数据情况，提供对未来航线布局和安排的数据依据，将所有航线进行统计、展示。将航线按照起飞地、将落地、时间分类，行程数据，由前端ECharts图表展示。
C.6 机场负荷统计
主要是计算出机场的起飞架次，降落架次。此部分数据对于提高机场运行效率和运作精细化管理水平具有重要意义，根据日起落架次可以评估出机场规划设计和运行管理的标准。前台统计需按照航空公司聚合，统计起飞架次，降落架次。
C.7 告警统计
将告警信息按照扇区进行分类统计，可以直观看到哪个扇区产生的告警数量较多，有帮助扇区改善交通流量，规范管制指令的作用。
C.8 扇区架次动态
空中交通管制扇区是空域运行的基本单元，扇区的通行能力在一定程度上反应了扇区的服务水平，将扇区的架次动态统计出来，是对扇区通行能力的有效评估方式。可以减少航班延误，促进空中交通流的顺畅有序。
C.9 各扇区通话饱和度
随着空中交通流量的激增和管制运行规模的扩大，管制员工作负荷在不断增加，扇区通话饱和度直接反映出这一问题，对于机场而言，可以更加有效的调整扇区状态，调整管制员工作，间接的决定了管制扇区的容量以及运行安全与效率。
C.10 冲突指令告警分析
每日管制人员会发出大量的航空指令，对于这些指令会出现相互冲突，将冲突指令记录并分析，行程提示信息，对帮助管制人员提高管制能力有非常积极的作用。
C.11 指挥航空公司架次占比
将指挥过的飞机架次按照航空公司分类统计，并计算出延误率。通过这项统计可以有效提高管制人员业务能力。
C.12 扇区架次数
为了保障扇区负荷平均，管制员工作强度维持在合理范围内，间接保障飞行安全，将飞机起落架次数，按照扇区分类，统计显示，动态安排扇区的使用。
3. 产品的非功能性需求
3.1 用户界面需求
1. 登录：
用户通过输入用户名和密码进行登录，后台验证用户名密码是否正确，如果不正确给出提示，并且通过后台下发用户权限，进入系统后，会根据用户角色权限显示不同的统计数据板块，进行展示。
2. 数据统计：
将扇区架次、动态航线图、扇区架次数、扇区通话饱和度，扇区架次数、年度告警统计、指挥航空公司架次、冲突指令告警在首页进行展示。表格数据均采用ECharts进行展示。
3. 航空实时监控
实时显示扇区内飞机位置，可以选择不同的扇区查看轨迹数，告警数，扇区内相似航班号提醒以及对管制指令进行纠错。有告警的航班会变红，提示管制员加以注意。
3.2 性能需求
| 主要性能属性 | 性能指标 |
|---|---|
| 页面响应时间 | 30ms |
| 同时连接的终端数 | 300个 |
| 支持最大并发用户数 | 1000人 |
| 正常以及峰值负载条件下的性能 | |
| 正常的工作压力下可接受的性能 |
3.3 产品质量需求
| 主要质量属性 | 详细要求 |
|---|---|
| 正确性 | 用户需求规格说明书中定义的功能全部正确实现 |
| 健壮性 | 根据测试用例进行测试，覆盖率达到90%以上 |
| 可靠性 | 项目持续运行至少3天，无异常 |
| 易用性 | 使用者找到所需功能入口的步骤深度不超过2层 |
| 安全性 | 权限认证机制，数据库安全，API调用安全 |
| 可扩展性 | 预留功能扩展接口 |
| 兼容性 | 浏览器同时兼容“谷歌”、“火狐”、“Edge”，界面同时兼容电脑PC端和移动端 |
4. 扩展功能性需求
4.1 功能性需求分类
| 功能类别 | 子功能 |
|---|---|
| 完善用户界面设计（A） | A.1 完成页面的布局设计和美化 |
4.1.A 完善用户界面设计
A.1 完成页面的布局设计和美化
例如可以通过修改Style样式的方式完成布局调整，具体页面显示样式，需要学生根据自己的喜好和设计自行完成，建议每个学生的页面尽量个性化设计，不要重复。
- 可选样式1：
- 可选样式2：
