任务描述

知识点：需求分析

重  点：原型设计工具，用例图，流程图绘制工具

难  点：功能点的梳理

内  容：完成本次实训项目的需求分析

1. 先共同讨论处本项目的主要功能模块，并确定每个模块的负责人（第一天完成，截止到晚上12点需要提交项目整体模块图，第二天上午在云平台上可供老师查看）
2. 第2天分工完成每个功能模块的需求和原型设计
3. 第3天汇总再集中每个模块之间的相关性，调整完善项目的需求和原型

任务指导

1、掌握用例图,ER图，UML图的绘制工具，推荐使用在线工具

• 如果之前已经安装过其他工具，可以使用，如果没有安装过，推荐使用processon在线工具，注册后即可使用
• 注册地址：568***54e邀请您加入Processon-1.1亿人都在用的在线作图工具_ProcessOn思维导图流程图

2、项目的用户需求及相关资料请从“资料”中下载使用。

任务实现

一、分组实施

1. 先共同讨论项目的主要功能模块，并确定每个模块的负责人（第一天完成，截止到晚上12点需要提交项目整体模块图，第二天上午在云平台上可供老师查看）
2. 第2天分工完成每个功能模块的需求和原型设计
3. 第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）对需求的承诺之前，该《产品需求规格说明书》必须先通过需求评审。

需求评审报告摘要
需求文档	输入名称，标识符，版本，作者，完成日期，…
需求评审报告	输入名称，标识符，评审日期，…
评审结论	[  ] 工作成果合格，“无需修改”或者“需要轻微修改但不必再审核”。 [√] 工作成果基本合格，需要作少量的修改，之后通过审核即可。 [  ] 工作成果不合格，需要作比较大的修改，之后必须重新对其评审。
评审意见
评审小组成员	输入评审小组成员

需求承诺
需求文档	输入名称，标识符，版本，作者，完成日期
客户承诺	承诺… 签字，日期
项目经理承诺	承诺… 签字，日期