解決需求工程中的基本問題

解決需求工程中的基本問題Amos(轉載自CSDN) 2002年09月16日引言當今，經(jīng)濟和社會生活對軟件的依賴程度急劇增長，軟件需求日益復雜，軟件開發(fā)成為一項跨越技能，職責范圍和時間階段的綜合團隊活動。實踐證明，良好的需求工程對于降低開發(fā)成本和保障項目成功至關重要。根據(jù)權威機構的統(tǒng)計，在全世界范圍，僅有四分之一的軟件開發(fā)項目能在規(guī)定的時間和預算內(nèi)達到客戶的目標?？v觀這些項目成功的項目，過硬的需求工程是成功經(jīng)驗中少有的共通部分。需求是系統(tǒng)或軟件必須達到的目標和能力；開發(fā)團隊的成功就是滿足軟件項目的需求。軟件需求工程化問題有綜合的內(nèi)涵：包括基于問題的需求捕獲、建立簡單原型、建立分析模型、開發(fā)需求歸約、相應的審核以及綜合的管理。國內(nèi)的軟件行業(yè)起步晚，起點高，任務急，時間短，在軟件需求工程方面暴露出很多問題。千頭萬緒之中，首要的著力點應該落實在基礎層面，具體講有兩方面問題：捕獲方法(elicitation)和內(nèi)容組織(specification)。解決基本問題不僅能夠作到短期見效，而且為圍繞需求問題的整體水平提升奠定堅實的基礎。圖表1軟件需求工程總覽捕獲方法捕獲需求就是引導客戶說出他們想要的東西，并確認被記錄下來的內(nèi)容確實是他們想要的東西。如果需求的捕獲方法選擇不當或使用不當，通常會暴露出兩方面問題。第一，軟件需求不能如實反映用戶的真正需要。比較常見的一種誤解是需求的簡單和復雜程度決定了用戶是否能夠真正理解相應的內(nèi)容：誤認為客戶只能看懂簡單的需求，但是對開發(fā)沒有直接幫助；只有復雜的需求才有用，但是大多用戶又不可能看得懂。事實上，造成這類問題的主要原因是捕獲的需求不能反映用戶的視角，因而，用戶站在自己的立場上很難判斷需求是否完備和正確，特別是在開發(fā)活動的早期。第二，軟件需求不能被開發(fā)團隊的不同工種直接共用。理論上，開發(fā)團隊所有成員的工作內(nèi)容都受軟件需求制約；現(xiàn)實中，如果不采用理想的需求捕獲方式，只有分析人員的工作看起來和軟件需求的內(nèi)容直接關聯(lián)，其它人的工作內(nèi)容和軟件需求的關聯(lián)并不直觀，形式上的差異或轉述往往不易察覺地造成了諸多歧義、冗余或者缺失。UseCase作為軟件需求的捕獲方法，在利用的當?shù)那闆r下，能夠很好地解決以上兩方面問題。第一，UseCase是軟件需求的載體，也是和用戶關于軟件需求進行討論的溝通方式，UseCase方法的最大特色就是充分反映軟件使用者的視角。以UseCase方法組織的需求內(nèi)容既有一目了然的圖形，又有深入細致的文字描述，從宏觀到微觀，無論繁簡，都能反映出用戶的視角，因而能夠被用戶充分的理解。換言之，用戶有可能判斷被捕獲的軟件需求是否能夠滿足他們的真正需要，從而加速雙方在早期達成共識。參見下圖。型吉 e 田書目丑誠3證來筑）圖表2UseCase圖形描述示意第二，基于UseCase組織的軟件需求具有顯著的外向型特征，是高度可復用的勞動成果。UseCase支撐分析人員幫助用戶理解系統(tǒng)能做些什么，幫助設計人員在適中的問題范圍內(nèi)識別基本元素的行為，幫助項目經(jīng)理預測開發(fā)任務的工作量，為測試活動和用戶文檔編輯提供了直接可用的依據(jù)和藍本。參見下圖。圖表3UseCase內(nèi)容被多工種直接共用內(nèi)容組織需求內(nèi)容的具體組織形式主要針對軟件需求歸約（SRS）,存在兩個比較突出的問題。第一，不符合國際通行的規(guī)范。主要癥狀表現(xiàn)為需求內(nèi)容的層次不清晰，往往是龐雜軟件需求細節(jié)的簡單堆砌，很難從高層次上理解軟件產(chǎn)品“為什么做和做什么?”。第二，與軟件需求歸約相關的流程指導薄弱。一方面，獲得高質(zhì)量軟件需求歸約過分依賴于分析師自身的經(jīng)驗，限制了并行開發(fā)需求內(nèi)容的可行性；另外，面對有價值的軟件需求內(nèi)容，團隊成員并不能充分地利用。RationalUnifiedProcess作為軟件開發(fā)流程的行業(yè)事實標準，其成熟的文檔體系及其相應的流程輔導，在利用的當?shù)那闆r下，能夠很好地解決以上兩方面的問題。第一，RationalUnifiedProcess中的軟件需求歸約符合國際規(guī)范IEEE830-1998,內(nèi)容劃分為概述、總體說明，詳細說明和支持信息等幾部分，各個部分內(nèi)容之間層次分明、關聯(lián)清晰。以UseCase描述的功能需求被平滑地融合在軟件需求歸約當中。于此同時，RationalUnifiedPrecess為軟件需求歸約的編制提供了詳細的指南和檢查點，能夠保障協(xié)同作業(yè)的質(zhì)量。參見下圖。

白“r工件［畝“卻業(yè)務建模工件集［申“緲需求工件集!!畝“咲主角|申+0邊界類iH.刮詞匸表需求雇性由“曹涪求管理計劃申“?涉眾諸戟-3摳南巴如訶模椅苗HTML模槻由，固補充規(guī)約由?②用例i畝“鴛用例模型圖表4與軟件需求歸約相關的指導第二，圍繞軟件需求歸約，RationalUnifiedProcess提供了豐富的流程指導。軟件需求歸約的基本內(nèi)容取材于“涉眾請求”，確保需求內(nèi)容反映使用者的要求；軟件需求歸約的指導原則依據(jù)“前景”，確保具體內(nèi)容和高層定位吻合；軟件需求歸約的文字描述嚴格遵守“詞匯表”，屏蔽來自微觀層面的歧義。在RationalUnifiedProcess中，軟件需求歸約的內(nèi)容作為軟件開發(fā)計劃、軟件構架文檔、分析模型、設計模型和測試模型的直接依據(jù)，流程不僅描述這些關鍵工件之間的關聯(lián)，而且對于內(nèi)容的映射和轉換給出了具體的建議和驗證點。參見下圖。ii-FFKft帆灼朋■計劃圖表5RationalUnifiedProcess的成熟文檔體系總結 ■蘭"需求的捕獲方法和內(nèi)容組織是需求工程中的基礎問題，相應的工作內(nèi)容體直接反映件需求的核心價值，也為展開和完成需求工程中其它任務建立了良好開端。在基礎