• Menu

    軟件需求工程學習筆記(四)


    1. 需求基本概念

           IEEE 610.12-1990標準采用的Dorfman和Thayer的需求定義為:(1)用戶解決某個問題或者達到某個目標所需要的條件或能力;(2)一個系統或系統組件為了實現某個契約、標準、規格說明或其他需要遵循的文件而必須滿足的條件或擁有的能力;(3)前兩項中所描述的條件或能力的文檔化表示。

           Jones 1994年給出的定義是“用戶所需要的并能觸發一個程序或系統開發工作的說明”。Alan Davis 1993年給出的定義是:“從系統外部能發現系統所具有的滿足于用戶的特點、功能、屬性等”。Sawyer 1997年給出的定義是“需求是指明必須實現什么的規格說明。它描述了系統的行為、特性或屬性,是開發過程中對系統的約束”。Suzanne和James給出的定義是:需求是產品支持其擁有者的業務所必需完成的事,或讓擁有者接收并感興趣所必須具備的品質。需求之所以存在,要么是因為該類型的產品要求某些功能或品質,要么因為客戶希望該需求成為交付的產品的一部分。楊巨龍給出的定義是:(1)站在頂層和全局的角度從問題和目標開始全面細致地對業務進行分析和描述;(2)在業務分析的基礎上將信息系統的宏觀設計也納入到分析中,并描述出業務與信息系統的關系;(3)用戶解決問題或達到目標所需的條件或權能;(4)系統或系統部件要滿足合同、標準、規范或其他正式規定文檔所需具有的條件或權能;(5)一種反映上面4部分所描述的條件或權能的文檔說明。張維明等給出的定義是:需求是一個對用戶意圖不斷進行揭示和判斷的過程,其目的在于細化,精化產品的作用范圍,確定擬開發系統的功能和性能、約束、環境等。需求應是問題信息和系統行為、特性、設計及制造約束的描述的集合。潘加宇對需求的描述是:需求聚焦于待開發系統的邊界,詳細描述系統要賣得出去必須具有的表現,即功能和性能。此外,還有這樣的一些定義:需求是人的一種主觀心理狀態,是人們為了延續生命和發展自身,并以一定方式適應生存環境而產生的對客觀事物的要求和欲望。需求是人們對事物的期望。需求是人們對系統的主觀期望,真正的需求存在于人們的腦海中,任何文檔形式的需求僅僅是一個模型、一種敘述或描述。涉眾通過這種描述能夠對系統取得一致的理解。

           IEEE公布的定義包括從用戶角度(系統的外部行為)和開發者角度(一些內部特性)來闡述需求。從用戶角度來說,需求就是“從系統外部能發現系統所具有的滿足于用戶的特點、功能及屬性等”。它強調的是產品和何種形式,而并非產品是怎樣設計、構造的。從開發者角度來說,需求就是“指明必須實現什么的規格說明。它描述了系統的行為、特性或屬性,是在開發過程中對系統的約束”。Jones 1994、Alan Davis 1993 和Sawyer 1997提出的需求定義是從系統角度來看的。這些不同形式的定義分別從用戶或系統的角度對“需求”進行了描述,定義涵蓋了系統的外部條件和內部特征,以及用戶、系統、需求之間的聯系。這些定義分別從不同領域分析需求,但是其核心內容是“系統應滿足的外部條件或內部具備的功能”。實際上,沒有一個清晰、毫無二義性的“需求”術語存在,所謂的“需求”,是人們對系統的一種主觀期望,真正的“需求”存在于人們的腦海中。沒有絕對的“需求”,需求總是從一定的視角描述。需求是用戶(人或系統)為解決問題或達成目標所需要的特性或條件。

    2.市場需求、產品需求和組件需求

           在具體的軟件項目中,往往會從市場需求、產品需求和組件需求這三種視角觀察軟件需求。市場需求是從客戶的視角描述的對一個產品的需求。它用客戶或用戶的語言描述產品的用途和體驗。它描述為什么要實現這個項目。產品需求是從方案實現的角度描述對一個產品的需求。產品需求描述不同用戶可以用這個產品做什么,市場需求和客戶期望怎樣在這個產品中實現。它以產品的語言描述特性,定義方案域和優先級。組件需求是從實現和后期方案的角度描述的對產品組件的需求,描述怎樣通過組件實現產品需求。組件需求是產品需求或系統的遞歸式優化。這三種視角在方案優化和抽象過程中產生。市場需求是在需求規格說明書中描述的,許多項目是對現有產品的變更。市場需求也描述這些變更,而不總是描述從零開始的項目或產品的需求。確定變更首先要對目標用戶群和目標細分市場進行分析,準確把握它們的需要和用途。我們經常實現一些看上去很有趣的功能或變更,但它們的市場太小。所以,要從經濟的角度為它們設定合適的優先級。市場需求是從利益相關者的不同視角開發可行的業務需求,產品需求是從不同用戶的角度看的。產品需求和組件需求是互為條件的,這兩種視角不是互斥的,而是互相依賴的。這三種視角依賴于方案框架。

    3.軟件需求產品的特性

           軟件需求的特性是說明軟件需求內容和形式上應具有的屬性。軟件需求在內容上應具有完整性、正確性、可行性、第一性、前置性、必要性、無二義性、可靠驗證性等特性;軟件需求在形式上應具有規則性、一致性可修改性、可追蹤性等特性。完整性是指每一個軟件需求都必須將所要實現的功能描述清楚,以使開發人員獲得設計和實現這些功能所需的定量信息。正確性是指軟件需求中的每一項需求都必須準確地描述其開發的功能。第一性是指業務分析工作是軟件需求第一重要的工作。前置性是說在軟件需求中應將信息系統的體系架構設計、數據庫設計、安全設計等設計工作前移到軟件需求中,進行初步的宏觀設計和頂層設計。這么做的目的是為了避免信息孤島和重復建設的問題??尚行允钦f軟件需求中的每一項需求都是要在已知系統和環境的月三種全部可以實現。必要性是說軟件需求的每一項需求都應把客戶的真正所需要的和最終系統所需遵從的標準記錄下來。等級性是說要對軟件需求進行優先級排序。無二義性是說對需求文檔中重復出現的名稱上相同的詞匯只能有一個明確統一的解釋??沈炞C性是說,對于每一條需求,都應該有可測量的驗收標準。規則性是說軟件需求內容應按照格式化文檔進行填寫。一致性是說一個需求和另一個需求、一個文檔和另一個文檔中不能存在同名不同義的矛盾??尚薷男允侵笇π枨蠓治鑫臋n進行修改時應對每一需求變更進行歷史記錄??勺粉櫺允侵笐撃茉诿宽椳浖枨笈c它的根源、設計元素、源代碼、測試用例之間建立鏈接關系。以上特性是良好需求所應有的必要屬性。不良定義的需求會導致軟件項目的延期或取消。

           第三方機構Standish Group發布的1994年度CHAOS Report報告中給出了軟件項目成敗因素分析的報表。從表中數據可以看出:在項目十大成功保證中有3個是直接與需求相關的,累計權重達到37.1%;而十大敗因中與需求直接相關的有5個,累計權重高達51.6%,需求問題對項目影響程度之高可見一斑。Ebert等人的最新研究結果顯示,大多數軟件項目的取消是因為沒有足夠清楚的需求和沒有很好的控制變更,在失敗的項目中,和不良需求相關聯的典型問題需求包括:(1)隱含的需求;(2)缺少的需求;(3)后期才明確的需求;(4)從一開始就有錯誤或不完整的需求基線;(5)膚淺和有歧義的需求;(6)不確定和不明確的需求;(7)不良的變更管理;(8)對于基線和變更缺少文檔;(9)員工轉向新領域等。

    4.需求工程的產生與發展

           在20世紀60年代計算機發展的初期,相對于硬件的通用性來說,軟件是為每個具體的應用而專門設計的。由于軟件規模普遍較小,程序的編寫者和使用者往往是相同的。在這種個體化的軟件環境中,軟件的設計通常是在人們的頭腦中進行的一個隱含的過程,除了程序清單外,沒有保留其他的文檔資料。

           隨著計算機系統的迅速發展,在20實際60年代中期到70年代中期,出現了制造軟件的“軟件作坊”,形成了廣泛使用的軟件產品。各種“軟件作坊”沿用早期形成的個體化軟件開發方法。隨著計算機應用的普及,軟件數量急劇膨脹,程序的個性化特征導致了一系列的問題,出現了所謂的“軟件危機”。軟件危機的出現推動了軟件工程概念的形成,人們借鑒傳統工業的成功做法,通過工程化的方法來開發軟件。軟件工程意味著在軟件開發的過程中引入軟件生命周期的思想和結構化的軟件開發方法,增強軟件開發過程中的管理機制,保障軟件開發技術的嚴格落實。

           在軟件開發的過程,最初要做的工作是問題定義,也就是確定要解決的問題是什么;然后進行可行性研究,決定該問題是否存在一個可行的解決辦法;接下來進行需求分析,也就是深入、具體地了解用戶的要求,在所要開發的系統必須做什么的問題上和用戶取得完全一致。經過上述軟件定義時期的準備工作才能進入軟件開發時期。

           和“軟件危機”出現的原因類似,由于缺乏需求開發經驗的積累,需求開發的過程沒有統一的、公認的方法論和規范指導,缺乏有力的工具支持,做好充分驗證等原因,導致后續的軟件開發階段沒有切實可行的依據,軟件質量得不到保證。因此,人們借鑒軟件危機的解決思路,提出了需求工程的設想,即按照工程化的原則和方法來開發、維護需求,提高需求質量和開發效率。在20世紀80年代中期形成了軟件工程的子領域——需求工程。

           需求工程涉及到軟件系統的目標、軟件系統提供的服務、軟件系統的約束和軟件系統運行的環境。此外,它還涉及這些因素和系統精確規格說明以及系統進化之間的關系,并提供現實需要和軟件能力之間的橋梁。進入20世紀90年代以來,需求工程成為研究的熱點之一。需求工程技術的應用范圍不斷擴大,一般的信息系統建設、復雜系統分析等都開始將需求分析作為系統開發的重要階段。與此同時,關于需求工程技術的研究也逐漸發展起來。從1993年起每兩年舉辦一次需求工程國際研討會(ISRE),自1994年起每兩年舉辦一次需求工程國際會議(ICRE),在1996年Springer-Verlag發行了一本新的刊物Requirements Engineering。與此同時,一些關于需求工程的工作小組也相繼成立,如歐洲的RENOIR等。

    5.需求工程的定義

          德國學者Ebert對需求工程給出的定義是:需求工程是系統性地、規范地進行需求獲取、編寫、分析、協商、核實和管理,使期望和目標在一個產品中實現。

          這個定義的內涵是:(1)需求工程是一個工學學科,它是系統工程和軟件工程的交叉學科,它的方法和技術來源于多個學科領域。(2)需求工程的生命周期伴隨產品的生命周期。需求工程不僅發生在新產品的開發過程中,也發生在對已有產品的改造過程中。(3)需求工程與項目密切相關,需求只存在于開發這個需求的項目的上下文中。(4)需求工程作為規范也是項目管理規范的一部分,它優先遵循項目管理的規范。需求工程的目標不是編寫完美的需求,而是作為功能在一個產品或方案中具體應用。(5)需求工程是提出問題并解答問題的過程。它提出并解答軟件系統的目標和如何達標的問題。

           德國學者Phol提出了將需求工程劃分為3個維度的觀點。Phol認為需求工程具有3個維度,它們是內容維度、共識維度和文檔化維度。內容維度被用來理解所獲取的系統需求。在需求工程過程開始時,除了系統愿景,僅有少量系統需求是已知的,而需求工程過程結束時,需求工程師已理解了所有的需求。共識維度與相關涉眾就已知需求的理解取得共識的程度有關。文檔化維度采用各種文檔化或規格說明的格式對系統需求進行文檔化和規約描述。文檔化維度意味著將需求活動中抽取的以非正式的方式記錄的信息進行重新的整理和描述。由此導出的需求工程的基本目標定義為:需求工程是一個協作式的、不斷迭代以及增量的過程,旨在確保:(1)所有相關的需求都在所需要的細節層次上得到了清晰的了解和理解;(2)在相關涉眾間建立起對系統需求的充分共識;(3)所有需求都依照相關的文檔化/規約格式和規范進行了文檔化和規約描述。

    6.需求工程的研究實例

           如上文所述,需求工程描述軟件工程和系統工程范圍內的規范,需求工程學科的準則是來自實踐的規范性準則。同時,需求的不確定性也使需求工程作為規范受到強烈的不確定性的影響,許多常規的工作也充滿了探索性的因素。正如Ebert所說,需求工程沒有封閉的理論,它的法則是經驗性質的?;谶@個事實,有必要對現有的需求工程理論進行全面的學習和研究,為后續的研究提供符合實際的信息資源材料。

           下面將介紹德國學者Pho提出的需求工程框架,中國學者張維明等人的提出的軍事信息系統需求框架,英國學者Robertson夫婦的Volere需求過程,以及中國學者徐峰提出的SERU需求過程框架和楊巨龍提出的基于信息資源規劃的需求工程。

          6.1 Phol需求工程框架

           在Phol需求工程框架中,需求工程的問題域被劃分為5類對象,它們分別是:系統上下文、需求工程的核心活動、需求制品、需求確認和需求管理。

           系統上下文是系統所處的環境中與定義、理解和解釋系統需求相關的那些部分。系統上下文由4個上下文刻面組成:主體刻面、使用刻面、IT系統刻面、開發刻面。

           主體刻面包含了系統上下文中與系統相關的對象和事件。使用刻面包含了與人或其他系統對本系統使用相關的所有方面。IT系統刻面由運行與技術環境的所有方面組成,包括那些定義了如何使用各種技術與運行環境的約束或指南的仿真與策略。所有這些技術和運行環境以及由它們所導致的各種約束影響著系統的需求定義。開發刻面包含了與系統開發過程相關的上下文方面,包括過程準則與約束等確保軟件系統質量的手段或技術。

           目標、場景和面向方案的需求是需求工程中的三種需求制品。

           目標是關于系統的目的、屬性或者使用的意圖。每一個需求工程都開始于一個致力于改變當前狀態的目標。目標導向是需求工程成功的關鍵。系統愿景是系統高層目標的定義。其他所有目標都是對系統愿景的精化。目標模型適合用來顯示記錄不同涉眾的期望及目標之間的依賴關系。

           場景記錄了滿足或不滿足某些目標的一組系統交互序列。場景描述了一個目標(或者一組目標)被滿足或者未被滿足的一個具體實例。它提供了一個或多個目標的具體細節。一個場景通常定義了一系列為滿足目標而執行的交互步驟,并將這些交互步驟與系統上下文相聯系。場景是介于抽象模型和現實之間的中間層抽象。場景比目標以及功能、數據和行為的概念更加具體,同時,場景自身也覆蓋了多個不同的抽象層次。涉眾可以根據所預期的在需求工程過程中的場景使用方式,來選擇合適的場景描述抽象層次。場景特別適用記錄關于上下文的信息。場景中記錄的典型上下文信息包括參與者、角色、目標、前置條件、后置條件、資源以及位置。在上下文的主體刻面中,場景可以用來描述系統中所表達的關于上下文對象的信息更新。在上下文的使用刻面中,場景被用于刻畫使用工作流。在IT系統刻面中,場景可以被用來刻畫如維護、備份之類的過程。在開發刻面中,場景可以被用來描述修改該系統的工程師與系統之間的交互序列。

          面向方案的需求定義了系統需要實現的屬性和特征。面向方案的需求定義了系統的數據視圖、功能視圖和行為視圖。數據視圖描述了數據方面的實體以及實體關系和屬性。功能視圖通過使用功能性模型描述面向方案的需求。系統的功能模型按照功能以及功能與數據存儲之間的數據流來描述系統需求。行為模型通常用來描述系統的反映性行為,主要通過(1)狀態;(2)事件;(3)狀態轉換來定義系統的動態行為。

           需求工程的核心活動是文檔化、抽取和協商。

           文檔化活動旨在記錄執行需求工程核心活動或橫向活動時所抽取或開發的重要信息。

           需求抽取是需求工程的3個核心活動之一。需求抽取活動的目標是:(1)識別相關的需求來源;(2)從所識別的來源中抽取現有的需求;(3)開發新的創新性需求。

           需求協商是需求工程中3個核心活動之一。協商活動的目標是:(1)識別沖突;(2)分析每個沖突的原因;(3)通過適當的策略解決沖突;(4)記錄沖突解決方案和原理。通過需求協商活動可以實現對于所有已知的系統需求在所有涉眾之間達成充分的共識。

           確認活動的目標是:(1)確認對系統上下文的考慮;(2)確認需求工程活動的執行;(3)確認所創建的需求制品。當確認對系統上下文的考慮時,需要檢查與所有4個上下文刻面相關的上下文是否已經被充分考慮到,同時被正確地文檔化。當確認需求工程活動的執行時,應遵循過程標準、指導和活動描述來進行確認。當確認所創建的需求制品時,需要確(1)確認內容;(2)確認文檔化;(3)確認共識。這三個確認方面與需求工程的內容維度、文檔化維度和共識維度相關。

           管理活動必須考慮以下3個主要方面:(1)上下文變更的識別和管理;(2)需求工程活動的管理;(3)需求制品的管理。對于上下文變更的管理,主要通過觀察的技術進行。對于需求工程過程及其活動的管理,主要通過順序的基于階段的管理方法或迭代的基于需求制品的管理方法。對于需求制品的管理,包括三種必不可少的管理活動:(1)建立需求的可追蹤性;(2)需求的優先級排序;(3)管理需求制品的變更。

           這五類對象的內在聯系是:需求工程師立足于系統上下文,從事需求工程的核心活動,得到需求制品。橫切活動用來支撐核心活動,并確保需求工程的結果。

          6.2軍事信息系統的需求工程

           軍事信息系統需求工程框架由需求工程的內容模型、需求工程的過程模型、需求工程的方法模型和需求工程的工具這四類對象構成。

           內容模型定義了系統需求的范圍、層次以及類型等方面的信息,對需求內容進行系統的、合理的分類。建立內容模型著眼于需求的理解和組織以及需求的獲取、描述、驗證及管理。

           過程模型主要定義信息系統需求論證人員在需求論證過程中所采取的步驟和程序,從過程上規范方法使用的順序、要求交付的文檔資料以及各個階段完成的標識等。過程模型的定義與控制是為了保證需求論證活動的基本質量。方法模型主要定義信息系統需求論證的各個階段所采用的各種技術手段或算法,方法模型是與過程相關聯的方法體系。方法模型為各種需求內容的論證提供了基本思路和步驟。方法模型的定義是為了提高需求論證的質量和效率。

           輔助工具以計算機軟件的方式實現了方法模型中所定義的各種方法,并且通過數據之間的約束關系體現了過程模型所定義的流程,為需求論證人員提供了自動或半自動的支撐手段,提高了需求論證的效率、科學性和正確性。需求工程的內容模型基于多視圖的需求分類方法對需求進行了分類。圖展示了基于Zachman多視圖框架對需求內容的分類,一共包含15個需求產品。根據視圖主體,需求的內容又分為四個層次,分別是:業務需求、信息需求、系統需求和技術需求。這四種需求之間的關系如圖所示。

          過程是有組織地將輸入轉變為輸出的一系列的活動集合。要開發高質量的需求模型與成果,必須按照一個系統化和嚴格化和嚴格有序的過程來管理和控制需求開發進程。需求工程過程框架如圖所示。需求過程的每個階段都有適合于當前階段的方法。

          需求獲取是一個確定和理解不同用戶類的需要和限制的信息收集過程。在需求獲取的過程中,常采用下列方法和技術:(1)會談;(2)調查問卷;(3)觀察記錄;(4)組織文檔;(5)使用用例;(6)快速原型法;(7)聯合會議記錄等。在這些傳統的需求獲取方法之外,軍事信息系統需求工程方法的研究者還提出了(1)基于綜合微觀分析機制的需求獲取方法;(2)基于場景的需求獲取方法;(3)三維互動采掘方法等。

          需求建模的重要目的是要理解系統將處理的問題,準確地獲取用戶的需求;同時,也是為了讓相關人員能理解和評審需求。需求建模包括結構建模、行為建模、數據和內容相關的需求建模和其他需求建模。行為建模方法包括:(1)IDEF0圖;(2)基于事件模型;(3)數據流圖;(4)IDEF0/UCM集成等。數據/內容建模方法包括(1)基于本體的需求建模方法(E-R)圖;(2)IDEF1X方法;(3)面向對象的需求建模方法等。

           需求驗證是通過對需求進行審查、確認、測試、建模、執行、分析和評價,確定需求文檔中的需求在邏輯上是否一致,在性能上是否達到最優或滿足用戶要求。需求驗證的過程如圖所示。需求驗證的方法包括結構化文本、決策表和決策樹、數理邏輯和IDEF3方法等。對于業務時序需求的驗證,亦可采用消息時序圖和對象Petri網的方法。

           需求管理的著眼點在于管理策略和規則的制定以及需求管理工具的開發。在進行需求管理時,主要是借鑒現有的管理方法和技術。常用的參考模型包括ISO9000,CMMI,RUP統一過程和REPEAT模型等。需求變更可界定為信息系統需求描述文檔被確定后,在執行過程中,在滿足用戶期望以及相關約束條件的前提下,對需求要素進行調整與修改。需求變更的主要原因分類如圖所示。需求變更影響結果如圖所示。

           從需求數據存儲形式來劃分,需求工程工具通常分為兩類:一類是以數據庫為核心;另一類是以文檔為核心。以數據庫為核心的需求工程工具把所有的需求、屬性和跟蹤能力信息存儲在數據庫中。以文檔為核心的需求工程工具通常使用字處理程序制作和存儲需求數據。

          6.3.Volere需求過程

           Volere需求過程是一種旨在指導需求工程師成功地發現正確完整的需求,收集、驗證需求,并編寫需求文檔的過程,這是針對得到提交產物的一個指南,是一種提交產物驅動的工作集合。

           項目啟動工作為需求發現工作奠定基礎,并確保項目成功所需要的資源都已經到位。在項目啟動的工作中,主要的涉眾聚在一起,對關鍵的項目問題達成一致意見。項目啟動工作確定項目業務問題的范圍、涉眾和項目目標,同時對項目需求部分所涉及的成本進行需求預估。

           如果項目啟動工作達到了預期的目標,就可以開始網羅需求的活動。在網羅需求的過程中,需求工程師對業務問題范圍內的工作進行研究,學習和理解業務的功能,并在此基礎上劃分業務用例。業務用例代表了響應業務事件所需要的功能。對系統本質的理解建立在對業務事件的理解和分析基礎之上。系統存在的根本理由來自于擁有這個產品之后底層業務的改變。通過界定發生改變的業務的范圍就可以界定產品的范圍,從而確定合適的產品用例場景,并寫下需求和用戶故事。

           場景展示了業務過程的功能性,將業務過程分解為一系列容易識別的步驟,用自然語言寫成,以便于所有的涉眾都可以參與討論。當涉眾達成一致之后,場景就成為需求的基礎。

           編寫需求的目的是為了以一種無二義的、可測試的方式寫下需求,以確保參與開發的各方面涉眾對需要做的事達成一致理解。需求理由和驗收標準使項目涉眾更容易理解需求,而對需求的測量是為了判斷構建的產品是否是涉眾真正需要的。編寫需求的活動是與網羅需求、制作原型和質量關等其他活動集成在一起的。

           質量關對需求的正確性進行檢查,通過質量關的需求才能成為需求規格說明的一部分。質量關檢查需求的完整性、相關性、可測試性、一致性、可追蹤性和其他一些質量屬性。當質量關是需求傳遞給開發者的唯一通道時,項目團隊就能控制需求。

           復查需求檢查是否存在遺漏的需求,保證所有的需求相互一致,需求與需求之間沒有懸而未決的沖突。復查工作確保規格說明書是完整的和恰當的,這樣就可以轉向下一個開發階段。需求過程是一個從愿景到系統規格說明書的演化過程。理解工作的過程伴隨著從愿景到業務用例再到場景的演化過程,在此基礎上理解產品的過程伴隨著從從業務用例到功能需求、非功能需求和限制條件的過程,最后產出了代表著技術需求的軟件規格說明書。在需求過程中,一份結構良好的需求模板既是一種強大的需求過程工具,也是一份完整需求過程的檢查清單。

          6.4 SERU需求過程框架

           SERU需求工程過程框架覆蓋了需求獲取、需求分析、需求管理中的主要活動,明確定義了工作任務、介紹了工作方法、指出了工作產物,說明了產物之間的連接方法,可以幫助軟件開發團隊快速應用到工作中,有效提高需求工程的質量。

           在SERU需求過程框架中,S代表著子問題域,核心思想是根據業務區劃來分解系統,使系統的各個部分在業務上保持相對獨立,降低耦合性;U代表著用例,用例是封裝需求的手段,是需求組織的最小單位,由一個業務活動(B類用例)、一個具體報表項(R類用例)和一個具體接口(I類用例)。E和R是聯接業務和用例之間的線索。E表示事件,是流程的起點,通過業務事件的標識找到流程,通過流程將不同的場景串接在一起。R表示查詢、分析、統計,通過尋找管控點確定報表類型,然后細化到具體的報表項。

           SERU需求過程框架將需求過程從邏輯上分為三個階段。第1個階段是需求定義階段,這個階段定義為項目的立項階段。其核心工作是:(1)根據業務特點劃分主題域;(2)確定每個主題域范圍,用上下文關系圖表示;(3)針對每個主題域,列出業務事件、報表類型列表。本階段主要的產物是:(1)構件圖,用來表示主題域之間的關系;(2)上下文關系圖,用來表示主題域的范圍;(3)業務事件列表,報表類型列表。第2個階段是理清需求框架和脈絡階段。這個階段對應于需求捕獲、分析這一階段,結束的標志是“標識出絕大多數的用例”。本階段的核心工作是:(1)針對每個業務事件進行流程、業務實體、使用場景分析;(2)針對每類報表進行業務實體、使用場景分析;(3)將場景抽象,得到用例模型;(4)將業務實體分析獲得的領域模型片段進行合并與抽象。(5)對設計約束與質量屬性進行分析。本階段的主要產物是:(1)活動圖,用來表示業務流程;(2)領域類圖片段,表示每個業務流程、報表類型涉及的業務實體;(3)用例模型片段,表示每個業務流程中的業務活動、具體報表項;(4)領域模型,按主題域對領域類圖片段進行合并與抽象;(5)用例模型:按主題域對用例模型片段進行合并與抽象;(6)部署圖:用來描述軟、硬件環境方面的設計約束。第3個階段是填充細節階段。這個階段對應于需求捕獲和分析的深化階段,結束標志是“已標識用例、領域類的細節均填充完畢”。本階段的核心工作是:(1)針對每個用例類進行捕獲和分析;(2)對流程圖上標識的相關文檔進行分析,完成領域類的細節填充;(3)在架構師的支持下,完成技術類用例的描述。本階段主要產物是:(1)業務類用例描述,包括事件流、相關需求、UI原型、規則約束;(2)報表類用例描述,包括報表概述、報表內容和輸入/輸出格式;(3)接口類用例描述,包括使用者概述、內容與格式、實現約束;(4)領域類描述:包括數據窗口分析、組成與格式、計算規則等。

           需求工程師在項目中應用此過程框架時,可以根據需要對框架進行剪裁、定制和修改。

          6.5基于業務及信息化規劃說明的需求工程

           基于業務及信息化規劃說明的需求工程在需求開發和需求管理的過程之前增加了需求規劃的階段。需求規劃階段的核心工作由業務研究、應用建模、系統規劃、分析計算、報告編制和規劃評審組成。需求規劃階段的工作產物是業務及信息化規劃說明。

           業務及信息化規劃說明是業務和信息化規劃工作的成果。業務及信息化規劃工作由業務分析、系統分析等部分組成,業務分析反映的是組織機構或客戶以問題和目標為核心的業務組織、業務域、業務過程、業務活動、業務規則、業務單證、業務量的物理世界的現狀的不失真反映;系統分析反映的是系統域、系統過程、系統活動、系統規則、系統單證、系統數據、系統流程、系統架構等,是對組織機構或客戶要建系統和待建系統站在總體角度的一種系統的宏觀設計。

           業務及信息化規劃說明的重點是站在組織角度依據客戶的問題和目標來確定需求的范圍和要達到的深度,范圍包括業務組織、業務域、業務過程、業務活動、業務單證、業務數據、業務規則、業務流程等,而目標說的是關于時間的效率、空間上的覆蓋程度、使用的簡便性等。業務需求規劃說明還包括系統分析和安全分析,是站在宏觀角度對信息系統的期望描述,業務需求規劃將指導軟件開發的各個環節。在闡述了基于業務及信息化規劃說明的內容之外,楊巨龍還介紹了需求工程的知識體系和方法體系。

    7.小結

           本文介紹了軟件需求和需求工程的基本概念,以及5個關于需求工程的研究實例,或者說是關于需求工程的知識體系。時至今日,需求工程的知識發展面貌日新月異,本文所介紹的內容亦是粗枝大葉,掛一漏萬。但是,從整體上看,略可管窺需求工程作為一門學科的發展脈絡,那就是:與系統工程全方位結合的需求工程。Paul在其專著《需求工程:原理、方法和實踐》一書中問道:“真的還需要另外一本需求工程的教科書嗎?”他的同胞Ebert就立刻以一本《需求工程實踐者之路》回答了他。Paul的自信是有道理的,他在書中精辟的總結道:“需求工程就是在上下文中建立愿景?!卑凑障到y方法論,上下文更多的呈現出硬系統問題的特性,這個系統是建立在人類科學技術尤其是電子信息技術發展的基礎之上的,這也就意味著即使遇到了一時說不清楚的問題,只要回退到技術的層面,一定能夠為對問題的認識尋找到一個相對堅實的立足點。那么,建立愿景呢?我們勉強可以把這個問題歸結為一個軟系統問題,因為“建立愿景”這四個字其內涵是弄明白人的愿望,把它們表達成可見的景,然后像栽花一樣種在計算機系統中,還要能夠確保其正常演化發展。Paul在知識工程和系統工程基礎上發展起來的需求工程框架本身就是一個嚴密的系統,在他的手中需求工程的知識已經被整合形成了一個硬系統,從這一點出發加入合適的計算機技術應該立刻能夠整合出一種用于處理軟件需求的軟件工具,但這種軟件工具的自動化程度再高,也只能不斷的提升軟件需求知識對軟件項目現實的轉化率,而不能也不可能實現完全的知識自動化。在軍事信息系統需求工程一書中,作者把基于系統的需求工程方法、基于企業應用框架的需求工程方法和基于能力的需求工程方法作為三種并列的需求工程方法。但是,張維明以及他周圍的學術團隊實際上用他們不斷推陳出新的學術成果指明了需求工程發展的方向。要素、能力、結構,三者統一于體系,體系是什么?系統之系統。再看薛惠峰等人以航天工程實踐為研究對象形成的現代信息化知識體系,開宗明義就提出要用現代系統工程支撐現代信息化建設。從知識系統發展的歷程看,可以說張維明等人的研究是從實踐出發自底向上的,薛惠峰等人的研究是自上而下的,顯而易見,在需求工程的研究領域,這兩種路線已經交會在一起,正經歷著自組織的整合,即將或者已經體現出了涌現性,將要向更高的層次發展演化了。再想想錢學森等人提出的綜合集成的系統方法!我們現在無法知道這分處南北東西的幾個學術團隊是否在按照某種方法的指導從事著研究,我們現在能夠看到的事實是,出現了這么一種宏觀現象,可以使用這種思想合乎實踐的詮釋。這還僅僅是從軟件需求工程的角度出發自然而然的呈現出的一個現象。如果上升到軟件工程這個系統層面,戴汝為院士等人在專著中提到的“社會智能與綜合集成系統”與陸汝鈐院士等人在文章中提到的“天馬”系統以及“知件”的概念,這又是處于什么層次的待開發的信息資源呢?對比身邊種種現象,我不禁產生這樣一個疑惑:錢學森之問真的沒有答案嗎?桃李不言,下自成蹊。這也從側面印證了上文介紹的另一個觀點,那就是“系統工程建立的歷史條件是:生產和技術大大發展了,已經發展到需要系統工程的階段,而且也有可能體現系統工程的階段。其深層次因素是人類的科學技術和生產能力已經到了重點要從解決硬技術轉向重點解決軟技術的階段?!憋@而易見,需求工程及軟件工程已經走在了這個點上。

    极速快三 <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>