需求分析讀書筆記（一）

標籤：blog   http   os   io   使用   2014   cti   sp   log   

一.用例（usecase）：

  1.定義：某個參與者（actor）要做的一件事。

  2.特徵：

    2.1 這件事是相對獨立的。這意味著它不需要與其它用例互動而獨自完成參與者的目的。

    2.2 這件事的執行結果對參與者來說是可觀測的和有意義的。

    2.3  這件事必須由一個參與者發起。不存在沒有參與者的用例，用例不應該自動啟動，也不應該主動啟動另一個用例。

    2.4 這件事必然是以動賓短語形式出現的。即，這件事必須有一個動作和動作的受體。

 3.用例的類型：業務用例（business usecase） ，業務用例實現（business usecase realization），用例實現（use case
realization），若不指定類型，則它就是通常意義上的use case。

  4.用例的粒度：，一個系統的業務用例定義在多於10個，少於50個之間。不論粒度如何選擇，必須把握的原則是在同一個需求階段，所有用例的粒度應該是同一個量級的。

二. 需求分析的階段

    一般來說，需求分析要經過業務建模，用例分析和系統建模三個階段才能完成需求工作。

    1、業務建模的目標是通過用例模型的建立來描述使用者需求，需求規格說明書通常在這個階段產生。這個階段通常使用業務用例和業務用例實現兩種類型；
    2、用例分析是系統分析員採用OO方法來分析業務用例的過程，這個階段又稱為概念性模型階段。這個階段通常使用無類型的用例。用例分析是一個過渡過程，但筆者認為其非常重要，業務架構通常在這個階段產生。
    3、系統建模是將使用者的業務需求轉化為電腦實現的過程。這個階段通常使用無類型的用例和用例實現兩種類型。系統範圍，專案計劃，系統架構通常在這個階段形成雛形（在系統分析階段確定）。

三 涉眾分析

一般來說，只有當以下工作都完成，才能說業務模型建立完成，它們是：
   a 發現和定義涉眾
   b 畫定業務邊界
   c 擷取用例
   d 繪製用例情境圖
   e 繪製業務實體模型（領域模型）
   f 編製詞彙表

   涉眾通過以下大類去尋找：

  1.業主 ： 業主是系統建設的出資方，投資者，它不一定是業務方。

  2.業務提出者：業務提出者是商務規則的制定者，一般是指業務方的高層人物，比如CEO，資深經理等。他們制定商務規則，圈定業務範圍，規劃營運目標。

  3.業務管理者：業務管理者是指實際管理和監督業務執行的人員，一般是指中層幹部，起到將業務提出者的意志付諸實施，並監督底層員工工作的作用。他們的期望也很重要，一般也是系統的主要使用者之一。

  4.業務執行者：業務執行者是指底層的操作人員，是與將來的電腦直接互動最多的人員。他們最關心的內容是系統會給他們帶來什麼樣的方便，會怎樣的改變他們的工作模式。

  5.第三方：第三方是指與這項業務而關聯的，但並非業務方的其他人或事。

  6.承建方：承建方，也就是你的老闆。老闆的期望也是非常重要的。老闆關心的是通過這個項目，能否賺到錢，是否能積累核心競爭力，是否能樹立品牌，是否能開拓市場。

  7.相關的法律法規：相關的法律法規是一個很重要的，但也最容易被忽視的涉眾。這裡的法律法規，既指國家和地方法律法規，也指行業規範和標準。

四 ，業務建模一般步驟和方法

    第一步：從涉眾中找出使用者。在ROSE中，應該使用business actor 類型。

    第二步：找出每個使用者要做的事，即業務用例，在ROSE 中應使用Business use case類型。

    第三步：利用業務情境圖協助分析商務程序，在ROSE 中，這個階段最好使用活動圖表Activity diagram。

    第四步：繪製用例情境圖。與業務情境圖不同的是，用例情境圖只針對一個用例繪製該用例的執行過程。強烈推薦使用activity diagram。

    第五步：從第三步或第四步中繪製的活動圖表中找到每一步活動將使用到的或產生的結果。這是找到物的過程。找到後，應當建立這些物之間的關係。在ROSE中，這稱為業務實體模型。應該使用business entity 類型。

     圖例：

       1.使用者：

2.業務用例

 

3.業務情境

  

4.業務用例實現視圖

5.業務用例情境

6.程業務實體視圖：

 五，用例規約的編寫

    分類：全域規則，互動規則，內稟規則，補充規則

 

本文是網路ID為coffeewoo的作者原創編寫，原始出處為http://coffeewoo.itpub.net

 

需求分析讀書筆記（一）