軟件需求說明書模板

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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