軟件測試之怎么做需求分析[4]

軟件測試之怎么做需求分析[4]    軟件需求管理

關鍵字：需求分析 方法

　　在軟件項目中，誰將對需求作出決策的問題并沒有統一的正確答案。分析員有時聽從呼聲高的或來自最高層人物的最大的需求。即便使用用戶代表這一手段，必須解決來自不同用戶類的相沖突的需求。通常，應盡可能由處于公司底層的人作出決策，因為他們與問題密切相關，并能得到關于這些問題的廣泛信息。

　　如果不同的用戶類有不一致的需求，那么必須決策出滿足哪一類用戶的需求更為重要。了解可能使用產品的客戶種類的信息和他們的用法與產品的業務目標的關系如何，將有助于你決定哪一個用戶類所占份額最大。

　　當開發者想象中的產品與客戶需求沖突時，通常應該由客戶作出決策。然而，不要陷到“客戶總是對的”的陷阱中去，對他們百依百順?，F實中，客戶并不總是對的?？蛻艨偸浅钟凶约旱挠^點，開發者必須理解并尊重這一觀點。

　　用例

　　在具體的需求過程中，有大的用例(業務用例)，也有小的用例。主要是由于用例的范圍決定的。用例像是一個黑盒，它沒有包括任何和實現有關或是內部的一些信息。它很容易就被用戶(也包括開發者)所理解(簡單的謂詞短語)。如果用例不足以表達足夠的信息來支持系統的開發，就有必要把用例黑盒打開，審視其內部的結構，找出黑盒內部的Actor和用例。就這樣通過不斷的打開黑盒，分析黑盒，再打開新的黑盒。直到整個系統可以被清晰的了解為止。

　　為什么要采用這種分析方法呢?計算機系統除了在與外界系統、人員有一系列的交互，在系統內部也往往存在著復雜的交互。因此，在系統建模時，除了描述系統與外界的交互，同時還要描述系統內部的交互。傳統的MIS系統中，系統與外界的交互較多。典型的，如ATM取款機：存在著大量的用戶與ATM，ATM與其它系統的交互。而電信領域的系統，與外界的交互較少。例如，系統的輸入可能僅僅是從交換機上采集信息，然后由系統進行處理。系統的復雜邏輯包含在系統內部處理的流程上，而非與外部系統的交互。建模主要任務是表達系統內部的交互。

　　用例圖適于表達交互，之所以上面使用了電信系統，是因為用例最早來自于Ericsson的交換機系統。當時，還是Ericsson雇員的Jacobson初步建立了用例圖的概念，并于1994年提出了OOSE方法，其最大特點是面向用例(Use-Case)，并在用例的描述中引入了外部角色的概念。用例的概念是精確描述需求的重要武器，比較適合支持商業工程和需求分析。隨著用例的發展，用例被大量的 用于對功能進行描述。每個用例代表了系統與外部ACTOR的交互?？梢圆扇№樞驁D來表達用例的具體操作程序。ACTOR用于確定系統的邊界。

　　ACTOR、用例可以從不同的層次來描述信息。采用該原則的原因有：

　　1. 需求并不是在項目一開始就很明確，往往是隨著項目的推進，逐漸細化。

　　2. 人的認知往往具有層次的特性。從粗到細、從一般到特殊。采用不同的層次來描述，適于認知的過程。 使用用例開發系統的一般過程

　　在開發過程的初始階段，可以根據具體的項目特點，制訂開發各個視圖之間的關聯原則，指導規范。在開發的過程中，視圖的組織原則應不斷進行維護、更新。

　　識別ACTOR來識別系統與外界交互的實體。ACTOR具有特定領域的特征，例如：交換機(采集系統)、97信息系統等。在系統層次的ACTOR確定了系統的邊界。

　　識別用例。同ACTOR一樣，用例具有不同層次。對較為概括的USECASE，需要細化。注：系統開發需要一定的規則來確定，如何來分解用例;可能基于原有系統的經驗，或是參考現有資料。

　　當用例細化到可以被理解的層次。需要基于用例進行下一步的開發。如前面提到的，用例主要用來描述交互。因此，存在交互的實體和交互的細節。交互的實體采用類圖來描述;而交互的細節，采用順序圖來描述。

原文轉自：http://www.anti-gravitydesign.com