论需求管理在民航系统研发中的重要性

卢栩茵

摘要：随着民航业的发展，信息化系统建设不断推陈出新，如何能够开发出符合行业标准，切实满足用户需求的系统变得尤为重要。事实证明，项目研发初期的需求管理是项目成功与否的关键。基于此，该文详细论述如何在民航项目中进行需求管理。

关键词：系统研发；需求管理；需求验证

中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2017）17-0203-02

1背景

近年来，随着民航业的发展，民航信息技术的深入推进，全国各地在保障空管设备运行的基础上，进行了大量信息系统的研发工作。以中南空管局技术保障中心为例，自主研发了空管设备信号覆盖评估系统、机场净空管理分析系统、空管设备运维信息化平台等。在研发的系统中，有些在后续上线使用过程中发现，部分功能设计并不能很好地解决用户的痛点，甚至个别功能与所提出的需求出入较大。事实上，用户对系统的接受程度和使用情况取决于项目初期系统需求设计是否真真切切反映用户的需求。因此，项目研发初期的需求管理成为了项目成功与否的关键。

2软件需求管理

随着信息技术的发展，尽管软件项目管理的经验积累不断丰富，软件管理的工具也不断推陈出新，但仍然有相当比例的软件项目以失败告终，究其原因，大部分是在项目初期没有正确地确定和定义需求，或是随着项目的推进没有正确地管理需求。百度百科中对软件需求管理的定义如下：一个为系统的需求进行启发、组织、建档的系统方法，一个建立和维护客户和项目团队之间关于变更系统需求所达成的一致性的过程。软件需求管理，主要包括4个方面：需求获取、需求分析和确认、需求验证和需求管理。在民航项目研发中，大部分的开发模式为，民航單位描述项目预期能够实现的功能，作为需求提供方，即项目的甲方；合作的IT公司根据甲方提出的需求，进行系统研发，即项目的乙方。本文主要论述民航单位即甲方所需完成的软件需求管理工作。

2.1需求获取

需求获取指需求的收集分析细化过程。对于一个新项目，在需求获取阶段要充分对系统未来的用户群（可以理解为不同的角色）进行分类，从不同的用户群中选择具有代表性的用户，分析不同用户的工作流程，确定使用场景使用实例，并以此为基础，编写初步的项目需求文档。

2.2需求分析和确认

需求分析根据需求获取中得到的需求文档，分析可行的系统实现方案。该阶段，作为甲方技术开发室的项目负责人员，主要完成的工作包括：设计系统原型，确定需求优先级，编写数据字典。以往在这个阶段，甲方只完成确定需求优先级这一项工作，并没有对系统的实现方案进行审核确认，只有在项目开发完成后才对系统的具体实现方式进行确认，届时发现项目实现与需求偏离为时已晚。

2.2.1设计系统原型

需求分析阶段，最重要的工作为设计系统原型，由于甲方作为项目的最终使用用户，对项目的业务需求、功能需求、非功能需求等的把握要远远清楚于开发方，因此在需求分析阶段，在乙方的建议和配合下，由甲方主要完成系统原型的设计工作，并由甲乙方共同对设计原型进行确认是避免系统开发完成后无法满足用户需求最行之有效的方法。

设计系统原型指当开发人员或用户不能明确需求时，利用原型工具，开发一个系统原型，用直观明了的方式清晰描述业务逻辑。当前最主流的几款原型工具包括：Axure RP、Gui De-sign Studio、JustInMind等，其中Axure RP拥有全套web控件库，直接拖拽即可快速制作网站原型并可自动生成用于演示的网页文件，丰富的动态面板可以用来模拟各种复杂的交互效果，支持多人协作设计和版本控制管理。由于Axure RP的实用性及快捷性，在实际工作中，通常采用其作为原型设计工具。例如，在设计规章手册管理模块时，在充分收集、分析、细化及核实用户需求后，利用Axure工具设计了模块原型，将模型生成网页文件后，对用户进行演示，验证是否符合用户需求。下图就是利用Axure工具设计的规章手册管理模块原型发布后的网页文件。

从图1中可以看出，原型可以充分模拟系统的实现效果，大部分的交互都可以直观地展现。根据演示结果修改原型，直至完全符合用户需求。由于此处进行的修改是在原型工具上进行的，涉及的修改工作量相对于代码的修改工作量非常小，而且修改起来简单快捷。

原型的优势除了便于与用户进行需求验证，还可以使前端和开发人员更容易理解需求。作为甲方的需求管控人员，在与用户确定需求无误后，可以配上注释等演示给乙方的前端和开发人员，大部分的疑问都可以针对模拟效果提出，避免了前端和开发人员的理解“误入歧途”。

2.2.2确定需求优先级

根据业务逻辑、工作流程等确定需求实现的优先级别，帮助乙方以优先级为基础，确定系统的版本及项目的开发阶段。这里的需求应涵盖所有需求，包括性能需求等特性需求。

2.2.3编写数据字典

创建数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。该步骤的工作主要为乙方完成，建议有计算机研发基础的甲方负责人员参与到数据字典的审核工作中，尽可能地减少后期的代码变更。

2.3需求验证

需求作为系统设计和最终验收的依据，其重要性不言而喻，因此需求验证至关重要。需求验证务必确保符合完整性、正确性、无二义性、一致性、可跟踪性及可验证性等。作为甲方，应主要完成以下几项工作：

1）确保系统设计原型满足用户需求；

2）审核需求文档，包括需求规格说明书及其他业务规范文档；

3）审核测试用例。乙方应依据需求编写测试用例，包括性能等特殊功能需求，撰写测试用例作为系统测试依据；

4）审核用户手册。乙方在系统设计原型定稿后即可起草一份用户手册，用它作为需求规格说明的参考并辅助需求分析。当前，经常采用的是Backlog的形式，用具体的语言详细描述不同功能点的业务流程。

2.4需求管理

需求开发的结果经验证批准就定义了开发工作的需求基线，甲方和乙方基于此基线达成需求约定。需求管理指在项目进展过程中维持需求约定一致性和精确性的所有活动。对于甲方而言，主要完成的需求管理工作包括如下几点：

2.4.1审核需求规格说明书

需求管理的最终成果是甲方和乙方对将要开发的系统达成一致协议，这一协议的基础就是需求规格说明书。需求规格说明书由乙方提供，甲方负责审核。需求规格说明书需采用标准模板，详细记录系统需求和各种其他与需求相关的重要信息。其中，每项需求都要指明需求来源，并清晰记录在需求的跟踪能力矩阵中，把每项需求来源、定义与实现、测试设计和代码部分联系起来，这样有利于需求管理和评估需求变更。

在撰写需求规格说明书时，乙方最容易忽略的一点是清晰记录业务规范。所谓业务规范是指系统的操作原则。由于民航的大部分项目都是在原有系统的基础上进行扩展功能，因此如何能够保持新模块和已有功能模块的操作一致性非常重要。甲方应监督乙方将业务规范编写成需求规格说明书中的一个独立部分，或撰写独立的业务规范文档，并对文档进行审核。

2.4.2管理需求变更

在项目开发过程中，由于业务流程变更等原因，造成需求变更在所难免，有些严重的需求变更可能会导致项目的重新开发，因此如何管理需求变更是需求管理工作的技术难点所在。可以从以下几个方面来控制：

1）确定变更控制过程。制定详细的变更控制过程，所有的需求变更都需遵循此流程；

2）分析变更可能造成的影响。评估需求变更对项目进度、工作量以及其它需求的影响；

3）跟踪变更。当进行某项需求变更时，在需求跟踪能力矩阵找到相关的其他需求，对造成影响的设计文档、源代码和测试用例等，进行同步修改；

4）记录需求变更。详细记录需求变更的日期以及所做的变更、原因、更新人、更新版本号等情况。

3结束语

需求管理作为软件项目管理的一个重要分支，其重要性不言而喻，在未来的民航项目开发中，将继续沿用文中提到的管理方式并研究学习最新的需求管理方法，最大程度地保证项目开发的质量。