城市軌道交通信號系統項目需求管理方案研究

渠 軍，蔣 莉

(卡斯柯信號有限公司 城軌系統部 200071)

城市軌道交通信號系統項目需求管理方案研究

渠 軍，蔣 莉

(卡斯柯信號有限公司 城軌系統部 200071)

需求管理是城軌信號系統項目能夠按要求順利實施的保障。由于信號系統項目的復雜性，需求管理一直是項目實施過程中的難題。本文結合信號系統項目的特點，提出一種基于平臺研發的需求管理方案。

需求管理；信號系統項目；平臺研發

需求管理是使系統必須滿足各種條件和功能的一種管理方案，是決定一個項目成敗的關鍵因素。需求管理主要包括需求的獲取、跟蹤、變更維護等過程。本文結合實際城軌信號系統項目特點，提出一種基于平臺研發的需求管理方案。

1 項目特點

城軌的信號系統是列車運行的神經系統，是保證列車安全運行的中樞。組成信號系統的子系統較多，且各子系統之間的接口也較為繁雜，一般來講信號系統可以劃分為如下幾個子系統：列車自動駕駛子系統、計算機聯鎖子系統、列車自動監控子系統、數據傳輸子系統、維護支持子系統，除此之外，項目實施過程中還包括電磁兼容要求、安全要求、可靠性可用性分析要求、對調試和安裝的要求以及對整個系統設計的要求。由于地鐵信號系統項目在實施過程中要求較為嚴格，項目需求一般還包含了關于管理的需求。

地鐵信號系統項目中需求有著專業性高、涉及面廣等特點。按照一般的軟件需求管理方案，項目實施非常困難，信號系統項目的需求管理一直是項目實施過程中的難題。沒有一個完善的管理方案，很容易造成需求的遺漏，無法對龐大數量的需求進行追蹤管理，最終導致項目無法按要求正常交付。在目前地鐵建設的管理中，信號系統項目工期通常較為緊張，這就對需求管理提出了更嚴格的要求，也加大了管理的難度。

因而，一個完善的需求管理方案對信號系統項目管理有著至關重要的地位。本文結合具體項目實施經驗，提出一種基于平臺研發的需求管理方案，在一定程度上能夠解決以上問題。

2 需求管理

2.1 需求定義及特征

根據IEEE標準軟件工程定義，需求就是：用戶所需的用于解決一個問題或達成一個目標的條件或能力；系統或系統元件必須滿足或具有的條件或功能，以滿足合同、標準、規范或者其它正式附加文檔的要求；關于條件或功能的文檔描述。

需求一般具有以下幾個特征：

必要性：需求必須是產品或過程的基本功能，物理特性或質量因素。如果該需求被刪除將會造成缺陷，且此缺陷不能被該產品或過程的其它的功能所彌補。

簡要性：該需求說明只包括一個需求，即簡單和清晰的說明必須做的事情，它應易于閱讀和理解。

可行性：通過一個或多個已開發系統計劃，以預定的成本，所描述的需求能夠實現。

完整性：所表述的需求是完整的，不需進一步擴展，并且能提供足夠的性能。

一致性： 所表述的需求不能與其它需求相矛盾，它不是另一條需求的復制，在所有需求中，相同的術語用于相同的條款。

明確性：每項需求都必須有且只有一種解釋，用于描述的文字在表述和數值上不能給讀者留下疑惑。

可驗證性：所表述的需求清晰具體，在某種意義上可量化，并可通過4種方法之一來檢查、分析、驗證和測試。

2.2 需求管理方案

信號系統具有一個標準化平臺，可以適用于不同需求的項目研發。對于信號系統的需求，可以根據平臺特點劃分為平臺類需求和項目類需求，如圖1所示。平臺類需求是已經由通用的標準化平臺滿足，而項目類需求則是需要項目團隊去測試驗證或需重新配置數據的需求。這種管理方案能夠盡最大程度縮短項目周期，減少項目的測試驗證工作量。項目的平臺類需求已由平臺進行了測試驗證，項目實施過程中，無需再次進行測試此類需求。項目僅對項目特有的配置實現和新的需求進行測試驗證即可。

2.3 需求識別、分類、追蹤

對于地鐵信號系統的需求來源，一般包括兩個部分：合同及設計聯絡會議紀要。（1）合同需求包含了對系統及設計需求（如正線追蹤間隔等）、各子系統設計需求（如ATS子系統的人機顯示方式等）、安全和可靠性需求（如設備的平均無故障時間）以及對項目管理類要求等（如交付資料等）。（2）設計聯絡會議紀要主要是合同需求的一個變更和澄清（如信號機顯示方式變更等）以及用戶新提出的需求。

圖1 基于平臺研發的需求管理方案

信號系統的需求識別主要依據需求的幾個特性，滿足必要性、簡要性、可行性、完整性、一致性、明確性、可驗證性等要求，則確認為一條需求。需求識別過程需要需求負責人和各子系統經理、項目技術負責人、項目經理等一致確認，確認每一條識別的需求是滿足需求特性的。

信號系統具有的通用性功能由平臺需求文檔覆蓋，這部分需求已由平臺進行追蹤管理，項目實施過程中不需要對該部分需求再次進行測試追蹤，這就很大程度上節省了項目的設計部署周期。

項目類需求是項目特有的要求或者在通用平臺上特有的配置類需求，該部分需求無法由通用平臺進行追蹤管理，需要項目實施者進行跟蹤管理。項目類需求可以劃分為非技術類需求和技術類需求。非技術類需求由項目的管理計劃文檔等進行覆蓋，完成對需求的追蹤管理。技術類需求是由各個子系統需求組成的，該部分需求需要再次分類到各個子系統，由各子系統的設計文檔進行覆蓋，并且在后期的測試中得到驗證。

2.4 需求變更管理

需求變更在需求管理中是十分常見的過程，在復雜的系統中管理需求變更是十分困難的，需要各個子系統進行配合完成。

項目實施者要分析變更對系統帶來的影響。由于城軌信號系統結構復雜，包含多個子系統，一個簡單的需求變更可能會引起多個子系統的需求同時發生變化，對于此類需求變更的管理需要各個子系統共同執行的。對于一個需求的變更，必須通過各個子系統共同合作完成。為了更好的管理此種需求變更，一般可以通過變更流程（CR，Change Request）分析來追蹤管理需求的變更。

2.5 需求GAP分析

GAP是指項目由于產品限制，目前項目無法在短期內快速解決的需求。對于此類無法短期完成的需求，項目也需要對其跟蹤。此類需求平臺應在后續的研發中追蹤管理，并在升級方案中得到解決。”

2.6 無法由文檔覆蓋的需求

對于某些無法由具體設計文檔或管理文檔覆蓋的需求，項目實施過程中又確實是按照要求來實現的需求，該部分需求需要需求的實施者通過郵件確認等方式完成對需求的追蹤。

3 結束語

本文提出的需求管理方案僅針對目前地鐵信號系統項目的需求管理，在實際的項目需求管理中有良好的追蹤管理效果。但是由于信號系統的復雜性，需求管理涉及的人員比較多，管理難度大，該方案仍需不斷的改善。

[1] 姬曉睛，吳朝暉.需求管理的一個系統解決方案[J].計算機工程，2003（19）.

[2] 袁 玨，胡 軍. 淺談軟件項目管理中的需求管理[J].計算機光盤軟件與應用，2011（17）.

責任編輯 徐侃春

Project requirement management for Signaling Systems of Urban Transit

QU Jun, JIANG Li
( Urban Transit System Department, CASCO Signal Ltd., Shanghai 200071, China )

Requirement management was the key to implement the Urban Transit Signaling System successfully. Requirement management was diff i cult in the process of project implementation because of the complexity of the Signaling System. This paper proposed a scheme which was based on the universal platform and characteristics of the signaling project.

requirement management; Signaling System project; research and development of platform

U231.7∶TP39

A

1005-8451（2015）06-0058-03

2014-11-18

渠 軍，工程師；蔣 莉，工程師。