14.3.2 需求分析的任務

　　1、需求分析的目的

　　完整、準確地描述用戶對系統的需求，跟蹤用戶需求的變化，準確地反映到系統架構和設計中，設計和用戶的需求保持一致。

　　具有決策性、方向性、策略性的作用。

　　2、需求分析的特點

　　追求系統需求的完整性、一致性、驗證性。

　　保持和用戶要求同步，

　　保持需求分析各側面之間的一致，

　　保持需求和系統設計間的同步。

　　14.3.3 需求文檔與架構

　　每個用例都有一個相關需求的文字描述，定義用例應該和領域專家一起進行，如果沒有領域專家的長期參與，只能是一種“偽分析”。

　　用例為定義架構提供了一個系統的領域行為模型。

　　界面的外觀、功能、導航同用例緊密相連，有效定義屏幕的方法叫低保真度原型(Low-fidelity Prototyping)，領域專家也始終參與到屏幕定義中去。

　　需求分析的項目詞匯表，也將在架構規劃中被擴展。

　　14.4 系統架構設計

　　系統架構溝通了需求和軟件之間巨大的語義上的鴻溝。

　　系統架構的第一個任務就是定義這兩個極端之間的映射。

　　開放分布式處理(Open Distributed Processing，ODP)包括企業、邏輯信息、計算接口、分布式工程、技術選擇。

　　對每個觀點，確認架構需求的一致性是非常重要的。

　　14.4.1 企業業務架構

　　企業業務架構從IT角度，對企業的業務結構、企業機構、業務的關系、內部的關系、與外部機構的關系進行整理定義。

　　包含如下內容：

　　1、企業的業務和戰略目標，近期、中期、長遠 目標。

　　2、企業的組織結構。

　　3、業務的分類。

　　4、各類業務之間的關系。

　　5、組織機構與業務的關系。

　　6、企業與外部機構的關系。

　　這些業務對象模型標識出系統的關鍵性約束，包括系統目標和重要的系統策略。

　　策略包含如下三類明確的表達方式：

　　責任：業務對象必須做什么。

　　許可：業務對象可以做什么。

　　禁止：業務對象不可以做什么。

　　對業務問題進行分析時，要考慮企業業務的發展，如新的服務或產品推出、考慮組織機構的改變等。

　　所有這些可能的變化(易變場景)都應該提現在企業業務架構中。

　　通過對企業業務架構的定義，很清楚地知道由于企業業務特點、業務的流程特點、企業的組織機構等原因對IT系統所帶來的自然分塊和各個分塊之間的邊界關系。

　　企業業務架構的維護是一個長期而反復的工作。

　　測試結果報告系統(Test Results Reporting System，TRRS)。

　　對象約束語言(Object Constraint Language，OCL)來定義企業活動者的這些策略(如 許可、禁止、義務等)。

　　2010年下半年軟考試題及答案解析匯總

　　2010年下半年軟件水平考試答案

　　2011年軟考系統架構設計師學習筆記匯總