確定系統邊界非常重要，是使用用例技術的基礎，小記下！
首先讓我們定義一下經常在專案中用到的術語。系統是指你打算開發的任何事物，他可能是軟體、硬體或者過程；專案是指為了建立乙個系統而做的所有事情，包括指定計畫、安排進度以及歸檔等。
在專案描述以及風險分析後我們需要做的是確定系統邊界，那麼如何才能確定系統邊界？
系統邊界通俗點來說就是將專案分割成系統內的和系統外的，系統內的在以後的專案進展中我們必須為建立他們而投入大量的精力，系統外的我們不需要建立，但是需要我們考慮與他們的介面。若要將系統外的事物進行劃分，那麼系統外部大致可以分為我們產品將要面對的使用者（人），以及為外部別的系統提供的服務（其他的軟體），資料儲存，硬體裝置，以及網路等等，這些都是不需要我們去建立的，但是我們必須考慮到他們甚至以他們為中心來分析我們的系統內部該做些什麼。
通常我們將系統外部與系統內部互動的的事物統稱為執行者，執行者是同系統互動的所有事物，執行者總是在我的系統之外，從來就不是我的系統的一部分，每乙個執行者都對應一種特定的角色，每乙個系統之外的實體對應多種執行者，就好比乙個人在系統中他會有多種角色一樣，又或者幾個人可以用乙個執行者來表示，因為他們對於系統來講屬於同乙個的角色。
如何尋找系統的執行者？只要能回答一下幾個問題，我想系統的執行者大體上也就找到差不多了。
誰使用這個系統？
誰安裝系統？
誰啟動系統？
誰維護系統？
誰關閉系統？
哪些其他的系統使用這個系統？
誰從這個系統獲取資訊？
誰為這個系統提供資訊？
是否有事情自動在預計的時間發生？
1、找出系統有什麼；系統外有什麼；確定專案規模，定義要建立系統那些部分。
2、通過確定執行者和用例來確定系統邊界。
3、確定執行者：誰使用這個系統，誰安裝這個系統,誰啟動這個系統，誰維護這個系統，誰關閉這個系統，那些系統使用這個系統，誰從這個系統獲取資訊，系統為誰提供資訊，是否有事情在預計時間自動發生？.....提問的方式最好針對參與者的目標。因為用例建模的觀點就是尋找特定參與者及其目標。
4、確定執行者使用的用例：
5、用例是一種系統執行的一系列活動，執行者執行它產生一種可估量（量化）的結果。什麼樣子才是可量化？一般指用例執行後的結果是具有永續性，穩定性的資料。
6、確定用例：執行者希望系統提供什麼樣功能？系統儲存，建立，更新或刪除什麼資訊？系統是否需要把自身的狀態變化通知給執行者？系統必須知道哪些外部的事件？執行者怎樣通知系統這些事件？
7、言簡意駭的描述執行者和用例。
8、發現新需求問一些問題：
這些需求是必須的？是系統邏輯上必須完成的嗎？是否會影響到風險分析？需求是否能被現有的執行者處理？是客戶希望的系統能做的嗎？會使產品在市場上變得與眾不同嗎？
9、系統邊界確定後必須確定專案 範圍：劃分系統需求的優先順序，確定預算。
晃到一些感覺：就像找個人幫忙，不僅用例分析時把系統當作乙個樂於助人的人，和他對話，而且我們在**編寫使用設計模式的時候也可以使用找人幫忙。這種心理模擬似乎不錯，哈哈
用例分析技術小結
現在rup 如日中天，需求分析是第一步，可以看作是高階系統分析員的必備知識，那麼，如果用物件導向的分析技術來描述需求呢？在乙個需求分析過程中，主要有專案描述，風險分析，用例圖以及描述，專案建議這幾部分。其中最重要的，也是最需要學習的就是用例的描述。那麼用例的描述關鍵點在 呢？確定清晰的系統邊界，就是...
用例分析技術小記 1
用例被用來描繪乙個系統外在可見的需求情況，常被用在專案的需求分析階段，對專案的測試計畫和使用者指南也有用處。他們被用來建立和驗證被提議的設計，並確保該設計滿足所有的需求。用例也被用來在建立專案計畫時決定在每乙個版本中應該加入什麼內容。在專案中常有的乙個問題就是，已經進入了開發階段了確還要對某些東西進...
用例分析技術閱讀筆記二
如果是做乙個大系統，那麼把大系統劃分為小系統就是乙個非常重要的事情！先選出系統中最重要的部分。主要的體系架構有如下幾種 一 mvc結構，一層用來顯示，一層用來控制，一層用來資料儲存。例如jsp,struct就是這種架構。二 管道和過濾器體系結構。主要思想就是乙個部分輸入資料，處理資料，然後輸出，下乙...