一種基于EA的需求管理實施方案

孟祥文

摘要：良好的需求管理是軟件項目圓滿完成的保障，基于IBM Rational系列產品的需求管理方案代價高，安裝使用復雜，不能有效滿足中小型軟件公司的需要。針對中小規模項目，給出一種利用EA及其擴展機制實現的輕量級需求管理實施方案，可以提高中小型軟件開發團隊需求管理的效率和效果。

關鍵詞：需求管理；擴展機制；需求跟蹤；需求變更

中圖分類號： TP319

文獻標識碼： A

文章編號： 16727800（2017）004016602

0引言 在軟件開發領域，需求工程越來越受到重視，需求建模質量往往是決定項目成敗的關鍵，在面向對象方法中通常采用用例（Usecase）模型來描述需求。然而用例模型主要用來描述系統的功能需求，對于非功能需求及需求管理則必須借助于其它手段。 需求管理是一種用于定義、記錄、組織和跟蹤系統需求變更的系統化方法，可用于獲取、組織和記錄系統需求并使客戶和項目團隊在系統需求變更上保持一致[1]。實際項目中需要借助工具輔助進行需求管理工作。 IT168作的一項調查顯示[2]，需求管理工具在國內企業和開發者中的使用比率是 Rational Requisite Pro 占 48.7%，Borland Caliber RM占20.6%，而TelelogicDoors占3.2%，很多中小公司還在使用 Word 或者 Excel 管理需求。目前影響最大的需求管理工具是IBM公司的Rational RequisitePro，它以數據庫為核心，同時提供 與Microsoft Word的整合。它將與數據庫集成在一起，支持用自然語言清晰地表達需求，并同時組織它們，用戶對數據庫中特性的修改可以同步到Word文檔中，同時用戶對文檔的修改也可以同步到數據庫中[3]。通過與其它Rational系列軟件產品的廣泛集成，給軟件工程生命周期內的各個階段都提供了強大、方便的需求信息查詢、跟蹤、管理功能。然而使用Rational系列產品代價較高，安裝和使用也比較復雜，提供的是一個重量級的需求管理解決方案，對于大多數中小公司并不適合。 Enterprise Architect（EA）是澳大利亞Sparx軟件公司的UML建模工具[4]，是為數不多的可將需求管理與其它軟件開發規范集成為一體的UML工具。經過項目實踐發現，通過EA的需求模型和提供的擴展機制，可以完成需求管理的主要任務，能夠滿足大多數項目對需求管理屬性的描述要求、需求模型的變更控制要求以及與其它模型間的可跟蹤要求等。本文將介紹利用EA進行需求管理的解決方案。1需求屬性定義與擴展 需求是指系統必須符合的條件或具備的功能，要確定項目的宏觀要求，定義項目的業務需求，明確項目的目標與范圍，還包括對系統開發過程的約束。在進行需求管理時，往往需要從多個角度描述一項需求的屬性。在EA提供的需求模型中，定義了一些標準的需求屬性，如：狀態、難度、優先權、階段、作者、版本和類型等，用戶可以直接選用這些屬性描述需求的基本性質，如圖1所示。實際項目開發中可能經常需要描述某些需求的一些額外管理屬性，例如：任務開始時間、穩定性、延遲處罰、花費等。如果需要的額外需求管理屬性數量較少，可以利用UML提供的標記值技術（Tagged Value）擴展技術定義外部需求標記。圖2描述了一個枚舉類型的Review Status標記的定義，定義一個標記時需要描述。 Type=Enum；//標記為枚舉類型 Values=Not Reviewed，Accepted，Rejected； //枚舉取值集合 Default=Not Reviewed；//默認值自定義的標記Tag默認不會顯示在需求視圖中，但可以通過設置需求顯示開關中的Feature and Compartment Visuality Tags選項，以控制自定義需求管理屬性的顯示。

如果擴展的需求管理屬性數量較多且具有一定的通用性，為了方便在其它項目中使用，可以利用Profile機制定義一組EA標準元素的擴展并設置相應的工具箱，并把這組擴展保存到文件中以便于重用。圖3是利用Profile機制對功能需求和非功能需求管理屬性進行擴展的擴展視圖，可以將該Profile視圖存貯為XMI格式的文件，在其它項目中只要導入該Profile文件，就可直接描述功能需求的RequiredBy、ReviewCompleted、ReviewStatus、 Reviewer、Reviewercomments、Riskstatus、Risktype等和非功能需求的Costinvolved、 RequiredBy、Risk、Risk status等管理屬性。

2需求變更 隨著用戶業務及外部環境的變化，用戶對系統提出的需求經常會發生變化，因此需求變更會不可避免地頻繁出現。EA可以通過建立需求基線，制定變更控制流程，并形成文檔來處理需求的變更問題。 針對外部需求的更改請求和問題，可以用兩種不同方式來定義： （1）使用需求的Maintenance View描述和管理每項需求變化所要解決的問題、變更的內容、必須修改的問題及完成需求變更的具體任務。圖4的需求維護視圖可以描述需求變更的內容、變更報告人、提出日期、變更狀態、變更解決責任人、變更解決日期、變更優先級等信息。

（2）先定義常規元素類型“Issue”（問題）and “Change”（變化），描述需求變更所解決的問題及變更的內容，然后鏈接到某個變化的外部需求上。 在項目的整個生命周期中，需求變更可能會發生很多次，有時需要管理某些需求元素的變化歷史，這可以通過審計視圖（Audit View）來實現，開啟審計功能可以記錄 Enterprise Architect 中的模型變化。它將記錄誰修改了一個元素，什么時間和怎樣修改的，并附有這個元素之前的狀態。這在記錄需求模型歷史記錄方面極為有用。3需求跟蹤 在實際項目開發中，經常會發生這樣的情況：測試人員在進行測試時，發現某些需求并未實現，諸如此類問題，很大一部分原因是需求跟蹤未做好。EA中的需求跟蹤可通過建立與維護“關系矩陣”來實現，在關系矩陣中，可以定義不同抽象級別、不同階段模型元素之間的語義聯系。EA中支持的關系類型較多，也可以根據需要通過UML擴展機制進行擴展。其中Trace、Realize和Refinement經常用來表達追蹤關系，通過需求跟蹤矩陣可以描述每個需求同后期系統模型元素之間的聯系，確保后期軟件制品產品與用戶需求的一致性。這些元素包括其它類型的需求、體系結構、其它設計部件、源代碼模塊、測試及幫助文件等。圖5描述了需求模型與用例模型之間的跟蹤關系，縱向的需求模型元素作為源，橫向的用例模型元素作為目標，右下角矩陣中的箭頭代表兩個模型元素之間存在跟蹤關系。4結語 針對中小規模軟件企業需求管理的現實問題，本文利用UML標記值擴展技術及Profile機制彌補EA標準需求管理屬性的不足，利用維護視圖處理需求變更的記錄和控制，利用需求跟蹤矩陣定義有組織的層次需求模型，跟蹤從系統需求到模型元素的實施，對于中小規模項目中的需求管理問題給出了利用EA工具實現的一種輕量級解決方案。

參考文獻：

[1]DEAN LEFFINGWELL，DON WIDRIG.軟件需求管理：統一方法[M].蔣慧，林東，譯.北京：機械工業出版社，2002：914.

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

[3]賴信仁.UML與Enterprise Architect 7.5團隊開發實務手冊[M].北京：電子工業出版社，2010：1020.

[4]秦眾森，李娟.需求變更管理過程及其工具分析與展望[J].計算機工程與設計，2009（11）：26012605，2614.（責任編輯：孫娟）