孟祥文

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

關(guān)鍵詞：需求管理；擴展機制；需求跟蹤；需求變更

中圖分類號： TP319

文獻標識碼： A

文章編號： 16727800（2017）004016602

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

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

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

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

參考文獻：

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

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

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

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