1、1.涉眾分析涉眾是與要建設的業務系統相關的一切人和事?？赡馨ǎ簶I主、業務提出者、業務管理者、業務執行者、第三方、承建方、相關的法律法規、用戶。最終的系統使用者將從當中產生，但用戶不等于涉眾，僅是涉眾的一部分。在此階段應產生涉眾分析報告。包括以下幾部分：涉眾概要、涉眾簡檔、用戶概要、用戶簡檔、消費者統計、以及業務角色的組織結構圖。表樣如下：1.1. 涉眾分析表1涉眾概要編R涉眾名稱涉眾說明期望1.表2涉眾簡檔涉眾涉眾代表特點職責1.成功標準1.參與口父付工件意見/問題1.2. 用戶分析表3用戶概要編P用戶名稱用戶概況和特點使用系統方式代表涉眾1.表4用戶簡檔用戶用戶代表說明特點職責1.成功標準

2、1.可交付工件意見/問題1.3. 消費者統計表5消費者統計名稱消費者概況和特點應用環境使用頻率特殊要求1.4. 用戶組織結構圖給出系統主要用戶的組織結構圖，如存在多個用戶組織，請分別給出1.2.1.1.2, .業務需求分析業務需求分析的目的是輸出業務模型，業務模型是我們需求分析階段最主要的工作成果，完整的業務模型包括以下內容：業務用例視圖、業務用例場景、業務用例規約、業務對象模型和業務規則。要注意理解業務模型中各制品的意義及關系，業務用例視圖是業務整體情況的完整展現，既要涵蓋完全，又要以不同的視角對其進行展現，以保證項目需求單位與實施單位對現有業務能夠具備統一的理解；業務用例場景是對業務用例視

3、圖中每一個具體的用例執行情況的圖形化描述，一般采用活動圖（泳道）表示；業務用例規約是對業務用例的全面解釋，既包含了業務用例的總體情況說明、執行者、執行過程（包括主流、分支和異常）、執行條件和約束，又包含了執行過程中涉及的業務對象；業務對象模型對業務用例中所涉及的業務實體之間的關系進行的描述；而業務規則是對業務過程中約束的描述。1 業務目標定義業務目標是對要建設系統的展望，業務系統的邊界將基于業務目標來定義。在此階段應提供明確的系統目標。1 系統范圍確定根據項目周期、成本、可行性分析等因素，衡量項目可以容納的項目范圍，調整已獲得的業務目標和涉眾期望，使后續的需求調研工作被局限在這些范圍內。但這個

4、范圍并不一定是系統的建設范圍，如交費如果可作為一個涉眾希望被規劃在項目范圍內，而不同的交費方式是否均在系統內實現才是真正的系統建設范圍。該階段應得到涉眾的確認，明確范圍后，應為每一個涉眾及其期望定義優先級，并通過優先級矩陣確認實現涉眾期望的順序，這將是系統迭代的依據。該階段應輸出全部涉眾期望及其優先級以及業務詞匯表。優先級定義標準：涉眾：最高3,業務核心人員，其工作構成最核心的業務流程，或核心業務的制定和監管者；普通2,主要業務的參與者，其工作是核心業務的重要輔助；最低1,邊緣業務的參與者，其工作對核心業務流程不產生重要影響。期望：最高3,核心業務的組成部分，如缺少該期望，核心業務流程不能運轉

5、；普通2,核心業務的重要輔助，如缺少該期望，核心業務流程將無法完成某些特定目標或無法順暢運轉；最低1,邊緣業務，缺少該期望也不會影響核心業務流程的順利運轉。1.4. 涉眾期望整理表6涉眾期望列表涉從編P涉眾名稱涉眾優先級期望編號期望期望優先級1.4. 期望優先級分析優先級分析可以使用優先級矩陣方法進行。優先級矩陣以涉眾優先級作為橫軸，期望優先級作為縱軸，單元格內的數值為涉眾優先級與期望優先級的乘積。優先級矩陣可以給出兩個結論：第一是確定期望的最終優先級，相乘結果大于等于6的為最高優先級，用紅色表示；相乘結果大于等于4的為普通優先級，用黃色表示；剩余為最低優先級，用綠色表示；對于多個涉眾具有同一

6、個期望的情況，該期望的優先級最終取值為最高優先級涉眾的優先級因子與該期望的乘積。第二是明確下一步對某一期望的調研對象表7優先級矩陣WR_SZ001(3)WR_SZ002(2)WR_SZ003(2)WR_SZ004(1)WR_EQS01(3)WR_EQS12(2)WR_EQS13(1)1 關鍵業務詞匯說明該部分將需求分析過程中出現的重要詞匯進行簡要說明，有常用英文詞匯的，填在備注欄內。表8業務詞匯表序號業務詞匯說明備注（常用英文名）1 業務邊界及主角定義根據整理出的業務目標定義系統邊界，在此過程中我們可以根據系統目標定義多個邊界；對于每個定義出的邊界，我們只關注該業務目標所服務的涉眾對于系統的期

7、望，而忽略其他位于該邊界范圍內的各涉眾的期望。只有直接與系統交互的涉眾才被稱為業務主角，我們應該按照所確定的業務邊界從涉眾概要中尋找站在邊界外的涉眾，并以主角的定義發現哪些涉眾會成為業務主角。此過程應提供業務邊界定義圖和邊界內主角關系圖，以明確定義的每個邊界的服務對象，和邊界范圍內的涉眾以及任務。1 邊界1業務用例分析按照已定義的邊界，根據業務主角所代表的涉眾的針對該邊界的期望或通過與客戶訪談或其他溝通方式或缺業務用例，獲取業務用例的過程中可以通過以下幾個問題得到正確的用例：業務主角對系統的期望業務主角打算在這個系統里做些什么事情業務主角做這件事情的目的是什么業務主角做完這件事希望有一個什么樣

8、的結果？該過程結束后，應針對該業務邊界范圍內的業務主角與相關用例的業務用例視圖、業務用例場景及業務用例規約1.7. 業務用例視圖給出業務用例視圖，簡要說明業務用例視圖中每個業務用例的含義。業務用例視圖應完整，覆蓋該邊界內全部的業務主角和業務用例，在必要的情況下，還應以不同的視角展現業務用例。1.7. 業務用例11.7.3. 業務用例場景用來描述業務用例在該業務的實際過程中是如何做的，是與用戶就業務達成共識的重要制品。要求至少用活動圖進行描述；如果該用例中主角間傳遞的信息很重要，要求同時用時序圖表現該業務用例的執行過程。業務用例場景圖應以業務用例名命名。一個業務用例可能對應多個業務用例場景（正常

9、執行、分支流程、異常流程等）。1.7.3. 業務用例規約以文字的形式表述了業務用例的情況，包括用例名稱、用例描述、執行者、前置條件、后置條件、主事件流描述、分支事件流描述、異常事件流描述、業務規則（交互規則）、涉及的業務實體等信息。業務用例規約一般以表格形式展現，要求每個用例必須提供業務用例規約。對于具有特別的非功能性需求的用例，應在業務用例規約表中添加一行說明非功能性需求；對于整個系統適用的非功能性需求應單獨列出非功能性需求列表。表9XX業務用例規約業務用例名稱用例描述執彳前置條件1.印條件1.主過程描述1.分支過程描述異常過程描述業務規則涉及的業務實體1.7. 業務用例21.7.4. 業務

10、用例場景用來描述業務用例在該業務的實際過程中是如何做的，是與用戶就業務達成共識的重要制品。要求至少用活動圖進行描述；如果該用例中主角間傳遞的信息很重要，要求同時用時序圖表現該業務用例的執行過程。業務用例場景圖應以業務用例名命名。一個業務用例可能對應多個業務用例場景（正常執行、分支流程、異常流程等）。1.7.4. 業務用例規約以文字的形式表述了業務用例的情況，包括用例名稱、用例描述、執行者、前置條件、后置條件、主事件流描述、分支事件流描述、異常事件流描述、業務規則（交互規則）、涉及的業務實體等信息。業務用例規約一般以表格形式展現，要求每個用例必須提供業務用例規約。對于具有特別的非功能性需求的用例

11、，應在業務用例規約表中添加一行說明非功能性需求；對于整個系統適用的非功能性需求應單獨列出非功能性需求列表。表10XX業務用例規約業務用例名稱用例描述執行者前置條件2.后置條件2.主過程描述2.分支過程描述異常過程描述業務規則涉及的業務實體1 邊界2業務用例分析按照已定義的邊界，根據業務主角所代表的涉眾的針對該邊界的期望或通過與客戶訪談或其他溝通方式或缺業務用例，獲取業務用例的過程中可以通過以下幾個問題得到正確的用例：業務主角對系統的期望業務主角打算在這個系統里做些什么事情業務主角做這件事情的目的是什么業務主角做完這件事希望有一個什么樣的結果？該過程結束后，應針對該業務邊界范圍內的業務主角與相關

12、用例的業務用例視圖、業務用例場景及業務用例規約。1.8. 業務用例視圖給出業務用例視圖，簡要說明業務用例視圖中每個業務用例的含義。業務用例視圖應完整，覆蓋該邊界內全部的業務主角和業務用例，在必要的情況下，還應以不同的視角展現業務用例。1.8. 業務用例11.8.3. 業務用例場景用來描述業務用例在該業務的實際過程中是如何做的，是與用戶就業務達成共識的重要制品。要求至少用活動圖進行描述；如果該用例中主角間傳遞的信息很重要，要求同時用時序圖表現該業務用例的執行過程。業務用例場景圖應以業務用例名命名。一個業務用例可能對應多個業務用例場景（正常執行、分支流程、異常流程等）。1.8.3. 業務用例規約以

13、文字的形式表述了業務用例的情況，包括用例名稱、用例描述、執行者、前置條件、后置條件、主事件流描述、分支事件流描述、異常事件流描述、業務規則（交互規則）、涉及的業務實體等信息。業務用例規約一般以表格形式展現，要求每個用例必須提供業務用例規約。對于具有特別的非功能性需求的用例，應在業務用例規約表中添加一行說明非功能性需求；對于整個系統適用的非功能性需求應單獨列出非功能性需求列表。表11XX業務用例規約業務用例名稱用例描述執行者前置條件3.后置條件3.主過程描述3.分支過程描述異常過程描述業務規則涉及的業務實體1.8. 業務用例21.8.4. 業務用例場景用來描述業務用例在該業務的實際過程中是如何做

14、的，是與用戶就業務達成共識的重要制品。要求至少用活動圖進行描述；如果該用例中主角間傳遞的信息很重要，要求同時用時序圖表現該業務用例的執行過程。業務用例場景圖應以業務用例名命名。一個業務用例可能對應多個業務用例場景（正常執行、分支流程、異常流程等）。1.8.4. 業務用例規約以文字的形式表述了業務用例的情況，包括用例名稱、用例描述、執行者、前置條件、后置條件、主事件流描述、分支事件流描述、異常事件流描述、業務規則（交互規則）、涉及的業務實體等信息。業務用例規約一般以表格形式展現，要求每個用例必須提供業務用例規約。對于具有特別的非功能性需求的用例，應在業務用例規約表中添加一行說明非功能性需求；對于

15、整個系統適用的非功能性需求應單獨列出非功能性需求列表。表12XX業務用例規約業務用例名稱用例描述執彳后置條件4.主過程描述4.4.前置條件分支過程描述異常過程描述業務規則涉及的業務實體1 業務對象分析業務對象分析的目的是建立業務對象模型，業務對象模型用于描述業務用例中涉及業務實體的基本信息及相互之間的關系。建立業務對象模型是通過分析業務用例，找出其中涉及的業務實體，來確定業務用例中各業務實體間關系的過程。此過程結束后應提供業務對象關系圖及業務對象屬性表。1.9. 業務對象關系圖業務對象關系圖一般按業務用例繪制，對于關鍵業務領域中跨多個用例的業務對象也應提供該業務領域內全局的業務對象關系圖。1.

16、9. 對象屬性表業務對象屬性表中應體現業務對象屬性及內稟規則業務對象名稱業務對象描述表13XX對象屬性表屬性名稱類型精度業務含義說明業務規則1 業務規則整理業務規則可以分為交互規則、內稟規則和全局規則。此過程結束后應提供全局規則列表，更新業務對象屬性表中的業務規則欄，更新業務用例規約中前置條件、后置條件及業務規則欄。其中：全局規則是指那些對于系統大部分業務或系統設計都起約束作用的那些規則，一般是與所有用例都相關，是跨用例的規則。一般我們將全局規則以表格形式單獨編制，放入業務模型中，作為業務模型的一個組成部分。全局規則應統一編碼，故如需求分析由多人合作進行，應現在各自文檔中采用臨時編碼進行引用，

17、匯總全局規則后統一為其編碼，再更新需求文檔。全局規則列表表樣如下：交互規則一般產生于業務用例場景中，在業務用例場景中，活動的轉移、狀態的變遷或是業務實體的交互都可能有一些限制條件，這些限制條件就是交互規則。由于交互規則依賴于業務用例場景，所以一般我們將交互規則寫到用例規約中（包括入口條件、出口條件及業務規則三部分），如該規約中的交互規則可作用于多個業務用例，建議定義為全局規則，為其統一編號后，在業務用例規約中直接引用該業務規則的編號。內稟規則是指那些業務實體本身具備的，并且不因為外部的交互而變化的規則。一般我們將內稟規則寫到業務對象屬性表中，可以不為其編號。表14全局規則列表編P名稱描述標志日

18、期備注注：編號格式應按要求，編號.后的數字表示該規則的版本，每次變更+1,在需要引用全局規則的文檔中，直接引用主編號即可，默認將最大版本號的規則視為當前規則；名稱的定義應具備唯一性，并容易理解；備注用于記錄該規則發生變更的原因。1 非功能性需求整理非功能性需求是系統在滿足客戶工作所需要的各種功能的基礎上，必須達到的系統目標，獲取非功能性需求時應完整記錄客戶需求，以及系統是否對其進行相應和具體的響應方式，以便后續工作中對其進行確認和跟蹤。此過程結束后得到更新的非功能性需求列表。非功能性需求一般包括以下4個主要方面：可靠性（安全性、事務性和穩定性）、可用性（界面、操作習慣、效率、容錯、幫助）、有效

19、性（性能、可伸縮性、可擴展性）、可移植性。非功能性的需求獲取可對照非功能性需求調研表中的說明（大象P267-P269）進行逐一收集，表樣如下：表15非功能性需求列表需求描述是否響應不響應原因口問應方式可靠性安全性系統數據的敏感程度系統運行于何種環境客戶組織中的信息保密制度使用人員情況事務性系統業務交叉程度數據精確度要求業務是否在線系統集成情況系統是分布式還是集比穩定性系統的服務能力要求用戶的操作頻率業務的及時性要求數據的重要程度可用性界面客戶的行業性質客戶的企業文化客戶的業務復雜程度使用人員的情況操作習慣客戶常用/喜愛的系統風格效率客戶對系統反應時間的要求容錯被打斷的工作是否要被記憶故障出現后

20、，系統能否恢復已完成的工作幫助客戶需要操作向導嗎客戶需要聯機文檔嗎客戶需要在線幫助嗎客戶的計算機操作水平后效性性能系統的平均訪問量系統的峰值訪問量系統的數據流量系統的并發要求硬件環境可伸縮性客戶業務預期的擴張速度客戶數據量的擴張速度使用人數的擴張速度系統規模會持續擴大嗎可擴展性客戶是否有長期系統建設的計劃客戶是否有升級系統的長期計劃可移植性客戶當前的硬件環境硬客戶是否件有長期的環硬件1商境合作伙伴客戶的業務是否在快速增長系統運行環境:客戶是否軟有長期的件軟件提供環商境自己是否有長期明確的技術路線1 業務包定義此過程應按實際業務情況使用包圖為業務用例分包，使整個業務模型完整清晰。其中的包圖在建模

21、過程中主要用于信息分類，一般可以按業務領域、業務部門等進行分類，我們建議采用按業務領域對業務進行分類。2.2.1.1.2, .系統分析系統模型是我們系統分析階段最主要的工作成果，完整的系統模型包括以下內容：用例視圖、用例場景、用例規約、用例實現視圖、用例實現場景、業務規則實現規劃和非功能性需求列表。要注意理解該階段各制品間的關系，以及用例和業務用例間的關系。用例一般由業務用例的單個活動抽象出來，表現一次完整的人機交互過程；用例場景和用例規約分別以圖形和文字的形式表現了該過程；對于具有不同實現方式的用例，我們應給出用例實現視圖，以及解釋該用例實現視圖的用例場景；業務規則和非功能性需求則是在用例之

22、外對系統需求描述的有效補充。2 邊界12.3. 業務用例1系統分析對業務用例進行系統分析的目的是得到系統用例。系統用例就是我們常說的用例，以后均用用例簡稱系統用例。用例主要是通過映射、抽象、合并、拆分、演繹等方式從業務用例中細化而來的。業務用例確定了需求范圍，也就是舊世界有哪些東西；而用例則確定了系統范圍，也就是新世界有哪些東西；需求范圍不等于系統范圍，對于那些不適合在計算機系統里運行的任務，就不能定義在系統范圍之內；系統范圍也不是全部都從需求范圍中來，比如那些系統管理類的任務。我們要找到用例，一般要先分析業務用例場景，從中抽取出那些可以在計算機系統中實現的單元來，對于原來業務用例場景中的某某

23、做什么，可能就是用例的來源。在此過程中我們應記錄每一個活動單元推導成用例的主要過程（包括方法與思路），以便在將來能夠更好的追溯系統用例所來源的業務用例，也就是真正的業務目的。我們應注意了解注意業務用例與用例在粒度上的區別，業務用例一般表現一個完整的業務目的，而用例一般表現一次完整的人機交互過程。該過程完成后，應提供用例視圖、用例場景、用例規約，有必要的情況下提供用例實現視圖和用例實現場景。2.3.2. 演化過程2.3.2. 系統用例視圖給出系統用例視圖，簡要說明系統用例視圖中每個用例的含義。系統用例視圖應完整,覆蓋該邊界內全部的主角和系統用例，在必要的情況下，還應以不同的視角展現系統用例。2.

24、3.2. 系統用例1如系統用例有不同實現，應以用例實現視圖表達用例的一種或多種實現方式，如和某人溝通可以通過見面、電話等各種方式，故一個用例可能對應多個用例實現。用例實現視圖對于整個項目過程中的需求追溯和系統實現對需求覆蓋的完整性驗證具有重要的作用具有重要的作用。得到用例實現試圖后，按照系統實現需求，分別對每個待實現的用例實現以用例實現場景和用例實現規約全面說明該用例。用例實現場景用于說明該用例是如何通過人機交互來完成的，是與用戶就如何操作達成的共識，也是制作系統原型的依據。用例實現規約與用例規約相同。2.3.2.4, 用例場景描述主角是如何操作計算機來完成用例的。是與用戶就系統如何做達成共識

25、的重要制品。要求至少用活動圖進行描述；如果該用例中主角間傳遞的信息很重要，要求同時用時序圖表現該用例的執行過程。用例場景圖應以用例名命名。一個用例可能對應多個用例場景。2.3.2.4, 用例規約用例規約以文字的形式表述了用例的情況包括用例名稱、用例描述、執行者、前置條件、后置條件、主事件流描述、分支事件流描述、異常事件流描述、業務規則（交互規則）、涉及的實體。用例規約一般以表格形式展現，要求每個用例必須提供用例規約。對于具有特別的非功能性需求的用例，應在用例規約表中添加一行說明非功能性需求；對于整個系統適用的非功能性需求應單獨列出非功能性需求列表。2.3.2. 系統用例2如系統用例有不同實現，

26、應以用例實現視圖表達用例的一種或多種實現方式，如和某人溝通可以通過見面、電話等各種方式，故一個用例可能對應多個用例實現。用例實現視圖對于整個項目過程中的需求追溯和系統實現對需求覆蓋的完整性驗證具有重要的作用具有重要的作用。得到用例實現試圖后，按照系統實現需求，分別對每個待實現的用例實現以用例實現場景和用例實現規約全面說明該用例。用例實現場景用于說明該用例是如何通過人機交互來完成的，是與用戶就如何操作達成的共識，也是制作系統原型的依據。用例實現規約與用例規約相同。2.3.2.5, 用例實現視圖3.1.1.4.2,用例實現1場景3.1.1.4.3,用例實現1規約3.1.1.4.4,用例實現2場景3

27、.1.1.4.5,用例實現2規約2.3. 業務用例2系統分析對業務用例進行系統分析的目的是得到系統用例。系統用例就是我們常說的用例，以后均用用例簡稱系統用例。用例主要是通過映射、抽象、合并、拆分、演繹等方式從業務用例中細化而來的。業務用例確定了需求范圍，也就是舊世界有哪些東西；而用例則確定了系統范圍，也就是新世界有哪些東西；需求范圍不等于系統范圍，對于那些不適合在計算機系統里運行的任務，就不能定義在系統范圍之內；系統范圍也不是全部都從需求范圍中來，比如那些系統管理類的任務。我們要找到用例，一般要先分析業務用例場景，從中抽取出那些可以在計算機系統中實現的單元來，對于原來業務用例場景中的某某做什么

28、，可能就是用例的來源。在此過程中我們應記錄每一個活動單元推導成用例的主要過程（包括方法與思路），以便在將來能夠更好的追溯系統用例所來源的業務用例，也就是真正的業務目的。我們應注意了解注意業務用例與用例在粒度上的區別，業務用例一般表現一個完整的業務目的，而用例一般表現一次完整的人機交互過程。該過程完成后，應提供用例視圖、用例場景、用例規約，有必要的情況下提供用例實現視圖和用例實現場景。2.3.3. 系統用例視圖給出系統用例視圖，簡要說明系統用例視圖中每個用例的含義。系統用例視圖應完整,覆蓋該邊界內全部的主角和系統用例，在必要的情況下，還應以不同的視角展現系統用例。2.3.3. 系統用例1如系統用

29、例有不同實現，應以用例實現視圖表達用例的一種或多種實現方式，如和某人溝通可以通過見面、電話等各種方式，故一個用例可能對應多個用例實現。用例實現視圖對于整個項目過程中的需求追溯和系統實現對需求覆蓋的完整性驗證具有重要的作用具有重要的作用。得到用例實現試圖后，按照系統實現需求，分別對每個待實現的用例實現以用例實現場景和用例實現規約全面說明該用例。用例實現場景用于說明該用例是如何通過人機交互來完成的，是與用戶就如何操作達成的共識，也是制作系統原型的依據。用例實現規約與用例規約相同。2.3.3.3, 用例場景描述主角是如何操作計算機來完成用例的。是與用戶就系統如何做達成共識的重要制品。要求至少用活動圖

30、進行描述；如果該用例中主角間傳遞的信息很重要，要求同時用時序圖表現該用例的執行過程。用例場景圖應以用例名命名。一個用例可能對應多個用例場景。2.3.3.3, 用例規約用例規約以文字的形式表述了用例的情況包括用例名稱、用例描述、執行者、前置條件、后置條件、主事件流描述、分支事件流描述、異常事件流描述、業務規則（交互規則）、涉及的實體。用例規約一般以表格形式展現，要求每個用例必須提供用例規約。對于具有特別的非功能性需求的用例，應在用例規約表中添加一行說明非功能性需求；對于整個系統適用的非功能性需求應單獨列出非功能性需求列表。2 邊界22.4. 業務用例1系統分析對業務用例進行系統分析的目的是得到系

31、統用例。系統用例就是我們常說的用例，以后均用用例簡稱系統用例。用例主要是通過映射、抽象、合并、拆分、演繹等方式從業務用例中細化而來的。業務用例確定了需求范圍，也就是舊世界有哪些東西；而用例則確定了系統范圍，也就是新世界有哪些東西；需求范圍不等于系統范圍，對于那些不適合在計算機系統里運行的任務，就不能定義在系統范圍之內；系統范圍也不是全部都從需求范圍中來，比如那些系統管理類的任務。我們要找到用例，一般要先分析業務用例場景，從中抽取出那些可以在計算機系統中實現的單元來，對于原來業務用例場景中的某某做什么，可能就是用例的來源。在此過程中我們應記錄每一個活動單元推導成用例的主要過程（包括方法與思路），

32、以便在將來能夠更好的追溯系統用例所來源的業務用例，也就是真正的業務目的。我們應注意了解注意業務用例與用例在粒度上的區別，業務用例一般表現一個完整的業務目的，而用例一般表現一次完整的人機交互過程。該過程完成后，應提供用例視圖、用例場景、用例規約，有必要的情況下提供用例實現視圖和用例實現場景。2.4.2. 演化過程2.4.2. 系統用例視圖給出系統用例視圖，簡要說明系統用例視圖中每個用例的含義。系統用例視圖應完整,覆蓋該邊界內全部的主角和系統用例，在必要的情況下，還應以不同的視角展現系統用例。2.4.2. 系統用例1如系統用例有不同實現，應以用例實現視圖表達用例的一種或多種實現方式，如和某人溝通可

33、以通過見面、電話等各種方式，故一個用例可能對應多個用例實現。用例實現視圖對于整個項目過程中的需求追溯和系統實現對需求覆蓋的完整性驗證具有重要的作用具有重要的作用。得到用例實現試圖后，按照系統實現需求，分別對每個待實現的用例實現以用例實現場景和用例實現規約全面說明該用例。用例實現場景用于說明該用例是如何通過人機交互來完成的，是與用戶就如何操作達成的共識，也是制作系統原型的依據。用例實現規約與用例規約相同。2.4.2.4, 用例場景描述主角是如何操作計算機來完成用例的。是與用戶就系統如何做達成共識的重要制品。要求至少用活動圖進行描述；如果該用例中主角間傳遞的信息很重要，要求同時用時序圖表現該用例的

34、執行過程。用例場景圖應以用例名命名。一個用例可能對應多個用例場景。2.4.2.4, 用例規約用例規約以文字的形式表述了用例的情況包括用例名稱、用例描述、執行者、前置條件、后置條件、主事件流描述、分支事件流描述、異常事件流描述、業務規則（交互規則）、涉及的實體。用例規約一般以表格形式展現，要求每個用例必須提供用例規約。對于具有特別的非功能性需求的用例，應在用例規約表中添加一行說明非功能性需求；對于整個系統適用的非功能性需求應單獨列出非功能性需求列表。2.4.2. 系統用例2如系統用例有不同實現，應以用例實現視圖表達用例的一種或多種實現方式，如和某人溝通可以通過見面、電話等各種方式，故一個用例可能

35、對應多個用例實現。用例實現視圖對于整個項目過程中的需求追溯和系統實現對需求覆蓋的完整性驗證具有重要的作用具有重要的作用。得到用例實現試圖后，按照系統實現需求，分別對每個待實現的用例實現以用例實現場景和用例實現規約全面說明該用例。用例實現場景用于說明該用例是如何通過人機交互來完成的，是與用戶就如何操作達成的共識，也是制作系統原型的依據。用例實現規約與用例規約相同。2.4.2.5, 用例實現視圖3.2.1.4.2,用例實現1場景3.2.1.4.3,用例實現1規約3.2.1.4.4,用例實現2場景3.2.1.4.5,用例實現2規約2.4. 業務用例2系統分析對業務用例進行系統分析的目的是得到系統用例

36、。系統用例就是我們常說的用例，以后均用用例簡稱系統用例。用例主要是通過映射、抽象、合并、拆分、演繹等方式從業務用例中細化而來的。業務用例確定了需求范圍，也就是舊世界有哪些東西；而用例則確定了系統范圍，也就是新世界有哪些東西；需求范圍不等于系統范圍，對于那些不適合在計算機系統里運行的任務，就不能定義在系統范圍之內；系統范圍也不是全部都從需求范圍中來，比如那些系統管理類的任務。我們要找到用例，一般要先分析業務用例場景，從中抽取出那些可以在計算機系統中實現的單元來，對于原來業務用例場景中的某某做什么，可能就是用例的來源。在此過程中我們應記錄每一個活動單元推導成用例的主要過程（包括方法與思路），以便在

37、將來能夠更好的追溯系統用例所來源的業務用例，也就是真正的業務目的。我們應注意了解注意業務用例與用例在粒度上的區別，業務用例一般表現一個完整的業務目的，而用例一般表現一次完整的人機交互過程。該過程完成后，應提供用例視圖、用例場景、用例規約，有必要的情況下提供用例實現視圖和用例實現場景。2.4.3. 演化過程3.2.2,2,系統用例視圖給出系統用例視圖，簡要說明系統用例視圖中每個用例的含義。系統用例視圖應完整,覆蓋該邊界內全部的主角和系統用例，在必要的情況下，還應以不同的視角展現系統用例系統用例1如系統用例有不同實現，應以用例實現視圖表達用例的一種或多種實現方式，如和某人溝通可以通過見面、電話等各

38、種方式，故一個用例可能對應多個用例實現。用例實現視圖對于整個項目過程中的需求追溯和系統實現對需求覆蓋的完整性驗證具有重要的作用具有重要的作用。得到用例實現試圖后，按照系統實現需求，分別對每個待實現的用例實現以用例實現場景和用例實現規約全面說明該用例。用例實現場景用于說明該用例是如何通過人機交互來完成的，是與用戶就如何操作達成的共識，也是制作系統原型的依據。用例實現規約與用例規約相同。用例場景描述主角是如何操作計算機來完成用例的。是與用戶就系統如何做達成共識的重要制品。要求至少用活動圖進行描述；如果該用例中主角間傳遞的信息很重要，要求同時用時序圖表現該用例的執行過程。用例場景圖應以用例名命名。一

39、個用例可能對應多個用例場景。用例規約用例規約以文字的形式表述了用例的情況包括用例名稱、用例描述、執行者、前置條件、后置條件、主事件流描述、分支事件流描述、異常事件流描述、業務規則（交互規則）、涉及的實體。用例規約一般以表格形式展現，要求每個用例必須提供用例規約。對于具有特別的非功能性需求的用例，應在用例規約表中添加一行說明非功能性需求；對于整個系統適用的非功能性需求應單獨列出非功能性需求列表。確定業務規則該階段的任務是確定哪些業務規則可以實現，并規劃各類業務的實現方式，其中：對于全局規則一般根據規則要求從軟件架構角度提出統一的規則解決方案，使需要遵循該規則的系統用例對于該規則的遵守可以通過繼承某個超類、實現某些接口的方法或填寫某些配置文件的這些統一的方式實現。所以這些業務規則