北京廣利核系統(tǒng)工程有限公司 吳彬，張?jiān)?，趙勇

1 引言

隨著越來(lái)越多的核電站使用數(shù)字化儀控系統(tǒng)，數(shù)字化儀控系統(tǒng)對(duì)核電站安全的重要性也正在增加，系統(tǒng)需求在數(shù)字化儀控系統(tǒng)研發(fā)過(guò)程中的地位也越來(lái)越重要。需求收集階段在IEEE1213中規(guī)定的需求開發(fā)流程中的位置如圖1所示。

本文通過(guò)分析標(biāo)準(zhǔn)中對(duì)需求收集方法的介紹和核電數(shù)字化儀控平臺(tái)的特殊性，最終得出適合核電數(shù)字化儀控平臺(tái)的需求收集方法。

2 標(biāo)準(zhǔn)要求

IEEE 1233-1996（IEEE Guide for Developing System Requirements Specifications）用于指導(dǎo)開發(fā)系統(tǒng)需求規(guī)格書，該標(biāo)準(zhǔn)中描述需求收集的來(lái)源如圖2所示。

圖1 需求開發(fā)流程

圖2 系統(tǒng)需求收集來(lái)源

標(biāo)準(zhǔn)中給出了一些需求收集方法的建議：

調(diào)查/問(wèn)卷；

對(duì)手系統(tǒng)評(píng)定；

原型；

頭腦風(fēng)暴會(huì)議或問(wèn)題-方案會(huì)議；

仿真；

工作模式的觀察（e.g. 工業(yè)操作效率的研究分析）；

會(huì)談；

逆向工程（從后期的工作產(chǎn)品導(dǎo)出作為其基礎(chǔ)的前期工作產(chǎn)品的過(guò)程）；

研究系統(tǒng)的組織和政治環(huán)境（e.g., 社會(huì)關(guān)系圖）。

由于標(biāo)準(zhǔn)中更多注重的是系統(tǒng)需求，如果單純按照標(biāo)準(zhǔn)中的方法進(jìn)行需求收集，開發(fā)人員會(huì)面臨無(wú)法將收集到的系統(tǒng)需求轉(zhuǎn)化為自己熟悉的平臺(tái)需求，所以標(biāo)準(zhǔn)中的需求收集方法僅作為參考，需求開發(fā)人員應(yīng)找出一種適合自己的平臺(tái)需求收集方法，但在需求收集階段應(yīng)遵照標(biāo)準(zhǔn)中提到的需求來(lái)源。

3 核電數(shù)字化儀控平臺(tái)要求

由于核電數(shù)字化儀控平臺(tái)的特殊性，需求收集的對(duì)象應(yīng)關(guān)注：

核電相關(guān)法規(guī)標(biāo)準(zhǔn)（IEEE、IEC、GB、HAD、HAF……）；

核電廠設(shè)計(jì)準(zhǔn)則（單一故障、共因故障、多樣性……）；

核電廠可靠性指標(biāo)（拒動(dòng)率、誤動(dòng)率、MTBF……）。

數(shù)字化儀控平臺(tái)，是指一系列硬件產(chǎn)品、軟件產(chǎn)品和輔助工具的組合，由這些產(chǎn)品所集成的系統(tǒng)，應(yīng)具備DCS的基本功能特征，如信號(hào)調(diào)理、信號(hào)采集與輸出、數(shù)據(jù)通信、運(yùn)算處理、信息控制與顯示、系統(tǒng)接口和組態(tài)工具等，它還應(yīng)具有可升級(jí)性和可擴(kuò)展性的特征。數(shù)字化儀控平臺(tái)需求是平臺(tái)研發(fā)人員可以直接用于開發(fā)平臺(tái)的需求，對(duì)于平臺(tái)研發(fā)人員來(lái)說(shuō)，合適的需求收集方法不需要逐步分析如何從系統(tǒng)需求轉(zhuǎn)化為平臺(tái)需求，能夠提高工作效率，降低最后開發(fā)出來(lái)的產(chǎn)品不滿足客戶要求的風(fēng)險(xiǎn)。

4 平臺(tái)系統(tǒng)的需求收集方法

針對(duì)標(biāo)準(zhǔn)中對(duì)需求收集的要求及核電數(shù)字化儀控平臺(tái)的要求，需求收集方法的使用應(yīng)該是一個(gè)相互結(jié)合而又反復(fù)進(jìn)行的過(guò)程，每種方法進(jìn)行完之后都要對(duì)收集的需求做記錄，并交由各方審查核實(shí)，以保證需求信息的可靠和準(zhǔn)確。我們選取了兩種適用于數(shù)字化儀控平臺(tái)開發(fā)的需求收集方法。

4.1 增加概念分析階段

在收集需求之前，需求開發(fā)人員經(jīng)常感覺收集對(duì)象不清晰，不知道從哪些方面去收集需求，最終導(dǎo)致收集到的需求龐大而無(wú)用。在需求開發(fā)流程中增加概念分析階段可極大的減少這種情況的發(fā)生。

增加概念分析階段的目的是根據(jù)核電廠中應(yīng)用系統(tǒng)、公司或部門的規(guī)劃文件，確定平臺(tái)的設(shè)計(jì)基礎(chǔ)框架；提前解決在需求開發(fā)中會(huì)遇到的矛盾的、有沖突的、不確定的問(wèn)題，使項(xiàng)目的管理人員、技術(shù)人員、用戶在后續(xù)的需求開發(fā)理解上保持一致；提前分析并評(píng)估在平臺(tái)系統(tǒng)設(shè)計(jì)中可能會(huì)遇到的關(guān)鍵問(wèn)題，降低開發(fā)過(guò)程中的風(fēng)險(xiǎn)，為后續(xù)的需求開發(fā)過(guò)程提供輸入。

概念分析階段應(yīng)注意以下幾個(gè)方面。

4.1.1 確定目標(biāo)應(yīng)用范圍

概念分析階段的首要任務(wù)是確定平臺(tái)開發(fā)的目標(biāo)應(yīng)用范圍，如應(yīng)用于保護(hù)系統(tǒng)、控制系統(tǒng)或某類專用系統(tǒng)等。

需求開發(fā)人員應(yīng)根據(jù)來(lái)自用戶或設(shè)計(jì)院的目標(biāo)應(yīng)用系統(tǒng)需求文件及相關(guān)設(shè)計(jì)文件，公司或部門發(fā)布的平臺(tái)可行性報(bào)告、立項(xiàng)報(bào)告或平臺(tái)規(guī)劃等文件，初步確定目標(biāo)應(yīng)用范圍。在初步確定目標(biāo)應(yīng)用范圍后，結(jié)合系統(tǒng)設(shè)計(jì)人員、平臺(tái)開發(fā)人員和其他相關(guān)技術(shù)人員的開發(fā)、設(shè)計(jì)經(jīng)驗(yàn)，對(duì)目標(biāo)應(yīng)用范圍進(jìn)一步討論，形成一致意見并最終確定目標(biāo)應(yīng)用范圍。

4.1.2 確定認(rèn)證要求

需求開發(fā)人員應(yīng)確定平臺(tái)產(chǎn)品將來(lái)可能需要的認(rèn)證要求，如核安全級(jí)鑒定、功能安全認(rèn)證等。

4.1.3 確定平臺(tái)架構(gòu)

需求開發(fā)人員應(yīng)在概念分析階段確定平臺(tái)架構(gòu)，劃分平臺(tái)子功能模塊，并描述各子功能模塊的相應(yīng)功能。

架構(gòu)圖應(yīng)包含如下內(nèi)容：

平臺(tái)產(chǎn)品的范圍；

平臺(tái)與外部系統(tǒng)的接口關(guān)系；

平臺(tái)中的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)；

平臺(tái)中的功能單元，以及各單元之間的關(guān)系；

控制站內(nèi)部功能單元；

對(duì)各種功能單元的目標(biāo)功能進(jìn)行詳細(xì)描述；

對(duì)各種網(wǎng)絡(luò)拓?fù)浜蛡鬏敺绞竭M(jìn)行描述；

圖3 平臺(tái)系統(tǒng)架構(gòu)圖

4.1.4 關(guān)鍵技術(shù)點(diǎn)分析

在概念分析階段，需求開發(fā)人員應(yīng)對(duì)關(guān)鍵技術(shù)進(jìn)行分析，包括如下內(nèi)容：

對(duì)接口關(guān)系及接口信號(hào)進(jìn)行描述；架構(gòu)圖示意圖如圖3所示。

識(shí)別出應(yīng)用系統(tǒng)對(duì)平臺(tái)的重要約束；

識(shí)別出平臺(tái)設(shè)計(jì)中可能遇到的難點(diǎn)和關(guān)鍵技術(shù)點(diǎn)；

分析以上問(wèn)題，提出解決問(wèn)題的幾種方案并確定解決方法。

4.2 事件驅(qū)動(dòng)法

確定了平臺(tái)的范圍之后，需求開發(fā)人員可以使用事件驅(qū)動(dòng)法將平臺(tái)要完成的事情劃分為相互獨(dú)立的用例，以分析平臺(tái)必須具備的要求。事件驅(qū)動(dòng)法通過(guò)發(fā)現(xiàn)平臺(tái)所要響應(yīng)的業(yè)務(wù)事件來(lái)確定平臺(tái)要完成的事情，即平臺(tái)的功能需求。如果平臺(tái)的范圍太大，難以作為一個(gè)整體進(jìn)行研究，則可以把平臺(tái)分解為一些獨(dú)立的單元，通過(guò)研究分解的單元以發(fā)現(xiàn)平臺(tái)系統(tǒng)需求。

使用事件驅(qū)動(dòng)法收集需求的步驟如下：

4.2.1 識(shí)別事件

業(yè)務(wù)事件有兩種觸發(fā)方式：

（1）事件觸發(fā)方式，例如下列事件：

現(xiàn)場(chǎng)傳感器信號(hào)輸入；

一定條件下（如現(xiàn)場(chǎng)傳感器信號(hào)超閾值）向控制現(xiàn)場(chǎng)設(shè)備輸出信號(hào)；

現(xiàn)場(chǎng)傳感器信號(hào)的網(wǎng)絡(luò)輸出；

顯示設(shè)備的控制信號(hào)輸入；

網(wǎng)絡(luò)輸入數(shù)據(jù)的邏輯符合輸出；

工程師站邏輯組態(tài)下裝。

（2）時(shí)間觸發(fā)方式，如下列事件：

平臺(tái)自監(jiān)視和自診斷信息顯示。

4.2.2 確定平臺(tái)用例

平臺(tái)的功能是對(duì)事件響應(yīng)的一系列處理過(guò)程，處理過(guò)程一直持續(xù)到要滿足的事件全部完成（例如：信息被顯示、控制被輸出、數(shù)據(jù)被存儲(chǔ)等）。如圖4所示。

圖4 事件驅(qū)動(dòng)法用例圖

由平臺(tái)完成的響應(yīng)就是一個(gè)用例，每個(gè)用例都是平臺(tái)功能的一部分。通過(guò)研究事件以及平臺(tái)如何響應(yīng)外界的事件來(lái)發(fā)現(xiàn)用例。

4.2.3 發(fā)現(xiàn)需求

（1）功能性需求

通過(guò)事件用例分析功能性需求，把完成這個(gè)用例所需要的步驟列舉出來(lái)，作為發(fā)現(xiàn)用例功能性需求的一種方法。

例如對(duì)于信號(hào)采集，用例步驟描述建議列舉為：

信號(hào)從傳感器輸入，平臺(tái)需實(shí)現(xiàn)與傳感器信號(hào)的電氣隔離；

對(duì)于隔離后的信號(hào)，平臺(tái)需要分配為n路信號(hào)；

對(duì)信號(hào)進(jìn)行量程比較，判斷信號(hào)“好、壞”；

將信號(hào)轉(zhuǎn)換為標(biāo)準(zhǔn)的電氣信號(hào)，并采集為數(shù)字化信號(hào)進(jìn)入平臺(tái)處理。

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

（2）非功能性需求

非功能性需求是產(chǎn)品必須具備的屬性或品質(zhì)。一旦知道了平臺(tái)需要完成的事情，就可以確定它的行為方式，它需要具備什么品質(zhì)，如它應(yīng)該多大或者多快。非功能性需求通過(guò)其他需求收集

圖5 功能性需求用例圖

圖6 非功能性需求用例圖

5 結(jié)語(yǔ)

目前這兩種需求收集方法已經(jīng)在北京廣利核系統(tǒng)工程有限公司的數(shù)字化核安全級(jí)控制保護(hù)系統(tǒng)（FirmSys）平臺(tái)和基于現(xiàn)場(chǎng)可編程門陣列FPGA技術(shù)的數(shù)字化儀控系統(tǒng)平臺(tái)（FitRel）成功使用。對(duì)于平臺(tái)開發(fā)人員來(lái)說(shuō)，使用這兩種需求收集方法能更好的便于他們理解平臺(tái)將要應(yīng)用的環(huán)境，對(duì)原始需求轉(zhuǎn)換為平臺(tái)需求提供了良好的過(guò)渡。

[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.），掌握需求過(guò)程（第2版）[M].北京：人民郵電出版社, 2007.

[4]毋國(guó)慶. 軟件需求工程[M]. 機(jī)械工業(yè)出版社2010,8.