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

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

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