定。在項目的早期階段，你必須決定誰是需求問題的決策者。如果不清楚誰有權(quán)并且有責任來作出決策，或者授權(quán)的個人不愿意或不能作出決策，那么決策者的角色將自然而然地落在開發(fā)者身上。這是一個非常糟糕的選擇，因為開發(fā)者通常沒有足夠多的信息和觀點來作出業(yè)務(wù)上的決策?！?BR> 在軟件項目中，誰將對需求作出決策的問題并沒有統(tǒng)一的正確答案。分析員有時聽從呼聲高的或來自最高層人物的最大的需求。即便使用用戶代表這一手段，必須解決來自不同用戶類的相沖突的需求。通常，應(yīng)盡可能由處于公司底層的人作出決策，因為他們與題密切相關(guān)，并能得到關(guān)于這些問題的廣泛信息。
如果不同的用戶類有不一致的需求，那么必須決策出滿足哪一類用戶的需求更為重要。了解可能使用產(chǎn)品的客戶種類的信息和他們的用法與產(chǎn)品的業(yè)務(wù)目標的關(guān)系如何，將有助于你決定哪一個用戶類所占份額最大。
當開發(fā)者想象中的產(chǎn)品與客戶需求沖突時，通常應(yīng)該由客戶作出決策。然而，不要陷到“客戶總是對的”的陷阱中去，對他們百依百順。現(xiàn)實中，客戶并不總是對的?？蛻艨偸浅钟凶约旱挠^點，開發(fā)者必須理解并尊重這一觀點。人員有一系列的交互，在系統(tǒng)內(nèi)部也往往存在著復(fù)雜的交互。因此，在系統(tǒng)建模時，除了描述系統(tǒng)與外界的交互，同時還要描述系統(tǒng)內(nèi)部的交互。傳統(tǒng)的MIS系統(tǒng)中，系統(tǒng)與外界的交互較多。典型的，如ATM取款機：存在著大量的用戶與ATM，ATM與其它系統(tǒng)的交互。而電信領(lǐng)域的系統(tǒng)，與外界的交互較少。例如，系統(tǒng)的輸入可能僅僅是從交換機上采集信息，然后由系統(tǒng)進行處理。系統(tǒng)的復(fù)雜邏輯包含在系統(tǒng)內(nèi)部處理的流程上，而非與外部系統(tǒng)的交互。建模主要任務(wù)是表達系統(tǒng)內(nèi)部的交互。
用例圖適于表達交互，之所以上面使用了電信系統(tǒng)，是因為用例最早來自于Ericsson的交換機系統(tǒng)。當時，還是Ericsson雇員的Jacobson 初步建立了用例圖的概念，并于1994 年提出了 OOSE方法，其最大特點是面向用例（Use-Case），并在用例的描述中引入了外部角色的概念。用例的概念是精確描述需求的重要武器，比較適合支持商業(yè)工程和需求分析。隨著用例的發(fā)展，用例被大量的用于對功能進行描述。每個用例代表了系統(tǒng)與外部ACTOR的交互?？梢圆扇№樞驁D來表達用例的具體操作程序。ACTOR用于確定系統(tǒng)的邊界。
ACTOR、用例可以從不同的層次來描述信息。采用該原則的原因有：
1. 需求并不是在項目一開始就很明確，往往是隨著項目的推進，逐漸細化。
2. 人的認知往往具有層次的特性。從粗到細、從一般到特殊。采用不同的層次來描述，適于認知的過程。使用用例開發(fā)系統(tǒng)的一般過程。在開發(fā)過程的初始階段，可以根據(jù)具體的項目特點，制訂開發(fā)各個視圖之間的關(guān)聯(lián)原則，指導(dǎo)規(guī)范。在開發(fā)的過程中，視圖的組織原則應(yīng)不斷進行維護、更新?！?BR> 識別ACTOR來識別系統(tǒng)與外界交互的實體。ACTOR具有特定領(lǐng)域的特征，例如：交換機（采集系統(tǒng)）、97信息系統(tǒng)等。在系統(tǒng)層次的ACTOR確定了系統(tǒng)的邊界。
識別用例。同ACTOR一樣，用例具有不同層次。對較為概括的USECASE，需要細化。注：系統(tǒng)開發(fā)需要一定的規(guī)則來確定，如何來分解用例；可能基于原有系統(tǒng)的經(jīng)驗，或是參考現(xiàn)有資料?！?BR> 當用例細化到可以被理解的層次。需要基于用例進行下一步的開發(fā)。如前面提到的，用例主要用來描述交互。因此，存在交互的實體和交互的細節(jié)。交互的實體采用類圖來描述；而交互的細節(jié)，采用順序圖來描述。
當系統(tǒng)復(fù)雜到一定層次時，類圖和順序圖可能不能足以描述其復(fù)雜程度。在該情況下，需要使用狀態(tài)圖來輔助闡述。狀態(tài)圖和順序圖之間使用事件聯(lián)結(jié)在一起。它們之間的一致性問題，目前UML和ROSE沒有提供
項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~
http://opto-elec.com.cn/pmqhd/index.html
