面向核电数字化仪控平台研发的需求收集方法研究

北京广利核系统工程有限公司 吴彬，张源，赵勇

1 引言

随着越来越多的核电站使用数字化仪控系统，数字化仪控系统对核电站安全的重要性也正在增加，系统需求在数字化仪控系统研发过程中的地位也越来越重要。需求收集阶段在IEEE1213中规定的需求开发流程中的位置如图1所示。

本文通过分析标准中对需求收集方法的介绍和核电数字化仪控平台的特殊性，最终得出适合核电数字化仪控平台的需求收集方法。

2 标准要求

IEEE 1233-1996（IEEE Guide for Developing System Requirements Specifications）用于指导开发系统需求规格书，该标准中描述需求收集的来源如图2所示。

图1 需求开发流程

图2 系统需求收集来源

标准中给出了一些需求收集方法的建议：

调查/问卷；

对手系统评定；

原型；

头脑风暴会议或问题-方案会议；

仿真；

工作模式的观察（e.g. 工业操作效率的研究分析）；

会谈；

逆向工程（从后期的工作产品导出作为其基础的前期工作产品的过程）；

研究系统的组织和政治环境（e.g., 社会关系图）。

由于标准中更多注重的是系统需求，如果单纯按照标准中的方法进行需求收集，开发人员会面临无法将收集到的系统需求转化为自己熟悉的平台需求，所以标准中的需求收集方法仅作为参考，需求开发人员应找出一种适合自己的平台需求收集方法，但在需求收集阶段应遵照标准中提到的需求来源。

3 核电数字化仪控平台要求

由于核电数字化仪控平台的特殊性，需求收集的对象应关注：

核电相关法规标准（IEEE、IEC、GB、HAD、HAF……）；

核电厂设计准则（单一故障、共因故障、多样性……）；

核电厂可靠性指标（拒动率、误动率、MTBF……）。

数字化仪控平台，是指一系列硬件产品、软件产品和辅助工具的组合，由这些产品所集成的系统，应具备DCS的基本功能特征，如信号调理、信号采集与输出、数据通信、运算处理、信息控制与显示、系统接口和组态工具等，它还应具有可升级性和可扩展性的特征。数字化仪控平台需求是平台研发人员可以直接用于开发平台的需求，对于平台研发人员来说，合适的需求收集方法不需要逐步分析如何从系统需求转化为平台需求，能够提高工作效率，降低最后开发出来的产品不满足客户要求的风险。

4 平台系统的需求收集方法

针对标准中对需求收集的要求及核电数字化仪控平台的要求，需求收集方法的使用应该是一个相互结合而又反复进行的过程，每种方法进行完之后都要对收集的需求做记录，并交由各方审查核实，以保证需求信息的可靠和准确。我们选取了两种适用于数字化仪控平台开发的需求收集方法。

4.1 增加概念分析阶段

在收集需求之前，需求开发人员经常感觉收集对象不清晰，不知道从哪些方面去收集需求，最终导致收集到的需求庞大而无用。在需求开发流程中增加概念分析阶段可极大的减少这种情况的发生。

增加概念分析阶段的目的是根据核电厂中应用系统、公司或部门的规划文件，确定平台的设计基础框架；提前解决在需求开发中会遇到的矛盾的、有冲突的、不确定的问题，使项目的管理人员、技术人员、用户在后续的需求开发理解上保持一致；提前分析并评估在平台系统设计中可能会遇到的关键问题，降低开发过程中的风险，为后续的需求开发过程提供输入。

概念分析阶段应注意以下几个方面。

4.1.1 确定目标应用范围

概念分析阶段的首要任务是确定平台开发的目标应用范围，如应用于保护系统、控制系统或某类专用系统等。

需求开发人员应根据来自用户或设计院的目标应用系统需求文件及相关设计文件，公司或部门发布的平台可行性报告、立项报告或平台规划等文件，初步确定目标应用范围。在初步确定目标应用范围后，结合系统设计人员、平台开发人员和其他相关技术人员的开发、设计经验，对目标应用范围进一步讨论，形成一致意见并最终确定目标应用范围。

4.1.2 确定认证要求

需求开发人员应确定平台产品将来可能需要的认证要求，如核安全级鉴定、功能安全认证等。

4.1.3 确定平台架构

需求开发人员应在概念分析阶段确定平台架构，划分平台子功能模块，并描述各子功能模块的相应功能。

架构图应包含如下内容：

平台产品的范围；

平台与外部系统的接口关系；

平台中的网络拓扑结构；

平台中的功能单元，以及各单元之间的关系；

控制站内部功能单元；

对各种功能单元的目标功能进行详细描述；

对各种网络拓扑和传输方式进行描述；

图3 平台系统架构图

4.1.4 关键技术点分析

在概念分析阶段，需求开发人员应对关键技术进行分析，包括如下内容：

对接口关系及接口信号进行描述；架构图示意图如图3所示。

识别出应用系统对平台的重要约束；

识别出平台设计中可能遇到的难点和关键技术点；

分析以上问题，提出解决问题的几种方案并确定解决方法。

4.2 事件驱动法

确定了平台的范围之后，需求开发人员可以使用事件驱动法将平台要完成的事情划分为相互独立的用例，以分析平台必须具备的要求。事件驱动法通过发现平台所要响应的业务事件来确定平台要完成的事情，即平台的功能需求。如果平台的范围太大，难以作为一个整体进行研究，则可以把平台分解为一些独立的单元，通过研究分解的单元以发现平台系统需求。

使用事件驱动法收集需求的步骤如下：

4.2.1 识别事件

业务事件有两种触发方式：

（1）事件触发方式，例如下列事件：

现场传感器信号输入；

一定条件下（如现场传感器信号超阈值）向控制现场设备输出信号；

现场传感器信号的网络输出；

显示设备的控制信号输入；

网络输入数据的逻辑符合输出；

工程师站逻辑组态下装。

（2）时间触发方式，如下列事件：

平台自监视和自诊断信息显示。

4.2.2 确定平台用例

平台的功能是对事件响应的一系列处理过程，处理过程一直持续到要满足的事件全部完成（例如：信息被显示、控制被输出、数据被存储等）。如图4所示。

图4 事件驱动法用例图

由平台完成的响应就是一个用例，每个用例都是平台功能的一部分。通过研究事件以及平台如何响应外界的事件来发现用例。

4.2.3 发现需求

（1）功能性需求

通过事件用例分析功能性需求，把完成这个用例所需要的步骤列举出来，作为发现用例功能性需求的一种方法。

例如对于信号采集，用例步骤描述建议列举为：

信号从传感器输入，平台需实现与传感器信号的电气隔离；

对于隔离后的信号，平台需要分配为n路信号；

对信号进行量程比较，判断信号“好、坏”；

将信号转换为标准的电气信号，并采集为数字化信号进入平台处理。

可以得到以下用例图，如图5所示。

（2）非功能性需求

非功能性需求是产品必须具备的属性或品质。一旦知道了平台需要完成的事情，就可以确定它的行为方式，它需要具备什么品质，如它应该多大或者多快。非功能性需求通过其他需求收集

图5 功能性需求用例图

图6 非功能性需求用例图

5 结语

目前这两种需求收集方法已经在北京广利核系统工程有限公司的数字化核安全级控制保护系统（FirmSys）平台和基于现场可编程门阵列FPGA技术的数字化仪控系统平台（FitRel）成功使用。对于平台开发人员来说，使用这两种需求收集方法能更好的便于他们理解平台将要应用的环境，对原始需求转换为平台需求提供了良好的过渡。

[1]IEEE 1233-1996，IEEE Guide for Developing System Requirements Specifications[S].

[2]IEEE 830-1998，Recommended Practice for Software Requirements Specifications[S].

[3]（英）罗伯逊（Robertson，S.），掌握需求过程（第2版）[M].北京：人民邮电出版社, 2007.

[4]毋国庆. 软件需求工程[M]. 机械工业出版社2010,8.