軟體工程需求分析之七種武器（上）

   背景介紹 

    人物：“我” 

    角色：IT部門系統分析師 

    公司介紹：勤緣電子貿易公司(化名), 年營業額達2億,主要由銷售部門、資材部和IT部門等組成。其中，銷售部門負責業務, 資材部負責供應商的開發和採購電子元器件產品,IT部門則負責公司的訂單管理系統的開發與實施。 

    系統目的: 該公司本年度把商機管理納入議程。所謂“商機”是指能為公司帶來業績和利潤的客戶需求資訊。商機一旦提交,公司的銷售部、資材部等會就需求完成一些針對該商機而 進行業務的任務。本系統的目的是管理追綜該商機及其任務。 

    現狀描述: 前段時間經過業務訪談，已經完成了系統的需求捕獲工作，確定了商機管理的範圍和目標。 

    任務描述：商機追蹤系統需求分析。 

    第一種武器： 長生劍——建模法 

    需求分析常常從建立模型開始,建模的原因主要在於:通過抽象降低複雜度,有助於回憶所有細節,有協助於與開發人員以及系統相關者交流，正所謂一圖勝千言。同時，模型本身還可作為系統維護文檔。 

    圖形模型是圖表和系統某些方面的示意性表示,多用一些符號表示較抽象的東西,諸如實體、處理過程、資料、對象、資訊和串連等。需求分析階段的重點是集中在系統需求高度抽象的問題上。 

    在建立模型之前,我們必須搞清楚兩個關鍵概念,即事件和事物。“事件”指可以描述的、值得記錄的，在某一特定時間和地點發生的事情。“事物”類似與系統互動的外部實體或參與者,同時,事物構成了系統儲存資訊的相關資料。 

    參照前面所描述的任務，在分析階段我們為商機管理建立了事件列表、實體—聯絡圖以及類圖等模型資料流圖等。而在設計階段,我們建立的模型有介面設計、流程圖、資料庫設計、結構圖等。 

    商機追蹤系統的事件如下:

• 收到商機資訊時
• 發布商機時
• 收到任務資訊時
• 任務跟進時
• 任務處理完畢時
• 商機結案時
• 商機達成時

    我們對現實世界中事件的認識有助於理解現代程式設計語言中的事件概念,更讓我們認識到程式設計語言在發展過程中產生了諸多思想和種類,其目的都是為了更好地解決現實問題。 

    讓我們列出商機追蹤系統基於名詞的事物的部分清單，其中包括：商機任務、BOM表、責任人、主題、內容、執行人、任務詢價、議價、特價申請、評估、索樣，等等。還有嗎？也許還有,如果沒有了,那麼恭喜,你的需求已經提煉完畢。 

    我們把事物列出來本身已經構成需求分析的符號系統。我們可以看到事物之間自然發生的的關係是很清楚的。商機和任務是一對多關聯性, 即一個商機至少引發一個任務,也可以引發多個任務。 

    我們看到,準確地定義系統的概念、事件、事物、流程是建立模型的基石。甚至可以說是一切需求分析方法的基礎。 

    我們需要重點關注的模型圖有實體類圖和實體關聯圖(Entity Relation Diagram，ERD)。實體類圖描述了實體和實體之間關係的一種圖解方式。它可以通過多種Case工具製作,如Visio或Rose。它本身也是UML適用於需求分析的抽象層中的一種模型。實體關聯圖是一種資料模型,可以協助我們分析和理解業務或系統的資料群組件。 

    實體用單名稱來命名,在ERD中用矩形框來表示。實體關聯圖用菱形框代表關係,它確定了一對實體之間在邏輯上和數量上的連繫。關係的命名則要能描述關係的本質。例如“BOM商機”和“任務”之間是“被執行”關係,用語言表達為“ BOM商機被任務執行”或“任務執行BOM商機” 。 

    請客戶評審ERD時,要讓他們檢查圖中所顯示的關係是否全部正確、合適和全面。 

    給出商機追蹤的ER圖。

圖1: 商機追蹤E-R圖

 

   第二種武器： 孔雀翎——用例法 

   用例的重要功能是用畫使用案例圖的功能來鑒別和劃分系統功能。它把系統分成角色（Actor）和用例（Use Cases）。角色表示與系統互動以實現某種目的的人、硬體或軟體系統。 

   判斷角色唯一的標準是它們必須要在被劃分進用例的系統部分以外。它們必須能刺激系統部分並接收返回。用例描述了當角色給系統特定的刺激時系統的活動。這些活動被文本描述，它描述了觸發用例時受到刺激下反映的本質，輸入和輸出到其他活動者和轉換輸入到輸出的活動。用例文本通常也描述每一個活動在特殊的活動線時可能的錯誤和系統應採取的補救措施。 用例也可以用活動圖表來表示。 

   這樣說可能會非常複雜，其實一個用例描述了系統和一個角色的互動順序。用例被定義成系統執行的一系列動作，動作執行的結果能被指定角色察覺到。 

   用例可以完成的目標如下:

• 用例捕獲某些使用者可見的需求，實現一個具體的使用者目標。
• 用例由角色啟用，並提供確切的值給角色。
• 用例可大可小，但它必須是對一個具體的使用者目標實現的完整描述。在UML中，用例表示為一個橢圓。

   用例轉變了需求開發的角度，傳統的需求分析方式是研究使用者需要用系統做什麼，而現在則是討論使用者需要實現什麼。用例法的目的是描述。 

   通常我們是用如下方法確定用例：

• 首先明確執行者和他們的角色，然後確定他們各自參與了哪些業務過程。
• 系統所能反映的外來事件，然後把這些事件與參與的執行者和特定的用例聯絡起來。
• 用特定情境來描述業務過程，將這些情境歸納為用例，並確定每項用例涉及哪些角色。

   商機追蹤系統就採用了第一種方法，我召開了一系列用例擷取和分析討論會，每周一到兩次，每次會前都要請使用者思考他們需要使用新系統執行什麼任務。我發現，用例的名稱應該表明使用者需要達到的目標，而描述用例則需要在名詞中使用動詞。如此一來，才能真正描述使用者的執行任務，即分析員需要描述的用例。 

   經過需求分析, 該電子公司商機管理的角色如下:

• 商機成員：其職責是發布商機。
• 商機管理：其職責是處理和分配商機任務, 常有如下動作:商機分配、驗證、詢價、議價、索樣、確定。

   關於商機追蹤系統“商機發布”用例的完全展開描述如下:

 

    第三種武器： 碧玉刀——原型法 

    原型是模型、樣品的意思，顯然它借鑒了製造業承接大量訂購前先索要樣品的經驗，在系統初始階段以可以運動的原型來說明需求和分析需求，給人以豁然開朗之感。 這裡的思想實際上是以設計來擷取需求,以設計原型的“磚”引出了真正需求的“玉”。我們也應該看到現在軟體工具的可視化也是促成原型法得以快速產生的原因所在。原型實際上也分為幾種：介面原型、概念性模型、資料模型。心理學亦表明人們對活動著的介面原型的理解力遠遠大於對靜態事務的理解，這就好像影像對視覺的衝擊力遠遠大於文本一樣。 

    一個快速實現的原型在整個需求開發過程中具有如下作用：

• 明確並完善需求
• 研究和設計選擇方案
• 可發展為最終產品

    原型的好處有很多, 掌握如下的原則去構建原型相信能獲得更佳的效果：

• 安排在專案計劃中的建立原型的任務和安排資源。
• 建立之前要陳述用途。
• 建立廢棄型原型要盡量快速和經濟,最少投資開發那些用於回答問題和解決需求不確定性原型。
• 對於已經理解的需求不要建立原型,除非是研究設計選擇方案。
• 在螢幕顯示和報告中使用看似真實的資料。
• 不能期望用原型去代替軟體需求規格說明（Software Requirements Specification，SRS）。
• 設計原型可以參考同類型軟體的介面, 但設計不要脫離現實需求和目標。

    好，現在就讓我們來一窺商機追蹤系統原型介面的廬山真面目吧。

圖2 新增商機

圖3任務追蹤

    從上面的原型介面看來，它是HTML的網頁格式, 看上去很真實。但我們也會發現，原型法和敏捷開發(XP)的區別在於功能：原型法側重在於介面和概念的定義，而敏捷開發則重在功能的迭代實現。

 

來源：http://tech.it168.com/m/p/2007-03-22/200703221308636.shtml