做大規(guī)模的市場(chǎng)調(diào)查，針對(duì)你的目標(biāo)市場(chǎng)做市場(chǎng)調(diào)查，并根據(jù)統(tǒng)計(jì)學(xué)的理論建立你的數(shù)學(xué)模型。這部分的工作效果最好，其性質(zhì)有些象一些游戲公司會(huì)發(fā)布一些Demo版的游戲。是對(duì)于一般的企業(yè)來(lái)說(shuō)，這項(xiàng)工作費(fèi)時(shí)費(fèi)力，高昂的成本往往使大家知難而退。我的意見(jiàn)是，方法是非常好的，但是可以軟件技術(shù)并不熟悉；第二種是開(kāi)發(fā)過(guò)同類軟件的軟件專家，這種人在開(kāi)發(fā)同類軟件過(guò)程中已經(jīng)積累了大量的項(xiàng)目經(jīng)驗(yàn)，并且具有軟件開(kāi)發(fā)的知識(shí)。這種方式是獲取需求的最好的方式。分析對(duì)比同類軟件，微軟在開(kāi)發(fā)Office、VisualStudio的時(shí)候，也是參照了Lotus和Borland的成熟產(chǎn)品。這種方式的特點(diǎn)在于成本很低，比較適合和其他的方式配合使用。但是，要注意自己有沒(méi)有觸犯專利法。有的時(shí)候，雖然已經(jīng)將用戶分類并選出了用戶代表。但是需求的來(lái)源眾多，往往會(huì)發(fā)生需求之間自相矛盾的事情。需求從四面八方收集來(lái)后，人們難以解決沖突，澄清模糊之處以及協(xié)調(diào)不一致之處。某些人還要對(duì)不可避免要發(fā)生的范圍問(wèn)題單獨(dú)作出決定。在項(xiàng)目的早期階段，你必須決定誰(shuí)是需求問(wèn)題的決策者。如果不清楚誰(shuí)有權(quán)并且有責(zé)任來(lái)作出決策，或者授權(quán)的個(gè)人不愿意或不能作出決策，那么決策者的角色將自然而然地落在開(kāi)發(fā)者身上。這是一個(gè)非常糟糕的選擇，因?yàn)殚_(kāi)發(fā)者通常沒(méi)有足夠多的信息和觀點(diǎn)來(lái)作出業(yè)務(wù)上的決策?！?/p>

    在軟件項(xiàng)目中，誰(shuí)將對(duì)需求作出決策的問(wèn)題并沒(méi)有統(tǒng)一的正確答案。分析員有時(shí)聽(tīng)從呼聲高的或來(lái)自最高層人物的最大的需求。即便使用用戶代表這一手段，必須解決來(lái)自不同用戶類的相沖突的需求。通常，應(yīng)盡可能由處于公司底層的人作出決策，因?yàn)樗麄兣c題密切相關(guān)，并能得到關(guān)于這些問(wèn)題的廣泛信息。

    如果不同的用戶類有不一致的需求，那么必須決策出滿足哪一類用戶的需求更為重要。了解可能使用產(chǎn)品的客戶種類的信息和他們的用法與產(chǎn)品的業(yè)務(wù)目標(biāo)的關(guān)系如何，將有助于你決定哪一個(gè)用戶類所占份額最大?！?/p>

    當(dāng)開(kāi)發(fā)者想象中的產(chǎn)品與客戶需求沖突時(shí)，通常應(yīng)該由客戶作出決策。然而，不要陷到“客戶總是對(duì)的”的陷阱中去，對(duì)他們百依百順?，F(xiàn)實(shí)中，客戶并不總是對(duì)的?？蛻艨偸浅钟凶约旱挠^點(diǎn)，開(kāi)發(fā)者必須理解并尊重這一觀點(diǎn)。人員有一系列的交互，在系統(tǒng)內(nèi)部也往往存在著復(fù)雜的交互。因此，在系統(tǒng)建模時(shí)，除了描述系統(tǒng)與外界的交互，同時(shí)還要描述系統(tǒng)內(nèi)部的交互。傳統(tǒng)的MIS系統(tǒng)中，系統(tǒng)與外界的交互較多。典型的，如ATM取款機(jī)：存在著大量的用戶與ATM，ATM與其它系統(tǒng)的交互。而電信領(lǐng)域的系統(tǒng)，與外界的交互較少。例如，系統(tǒng)的輸入可能僅僅是從交換機(jī)上采集信息，然后由系統(tǒng)進(jìn)行處理。系統(tǒng)的復(fù)雜邏輯包含在系統(tǒng)內(nèi)部處理的流程上，而非與外部系統(tǒng)的交互。建模主要任務(wù)是表達(dá)系統(tǒng)內(nèi)部的交互。

    用例圖適于表達(dá)交互，之所以上面使用了電信系統(tǒng)，是因?yàn)橛美钤鐏?lái)自于Ericsson的交換機(jī)系統(tǒng)。當(dāng)時(shí)，還是Ericsson雇員的Jacobson 初步建立了用例圖的概念，并于1994 年提出了 OOSE方法，其最大特點(diǎn)是面向用例（Use-Case），并在用例的描述中引入了外部角色的概念。用例的概念是精確描述需求的重要武器，比較適合支持商業(yè)工程和需求分析。隨著用例的發(fā)展，用例被大量的用于對(duì)功能進(jìn)行描述。每個(gè)用例代表了系統(tǒng)與外部ACTOR的交互。可以采取順序圖來(lái)表達(dá)用例的具體操作程序。ACTOR用于確定系統(tǒng)的邊界。

    ACTOR、用例可以從不同的層次來(lái)描述信息。采用該原則的原因有：　

    1. 需求并不是在項(xiàng)目一開(kāi)始就很明確，往往是隨著項(xiàng)目的推進(jìn)，逐漸細(xì)化。

    2. 人的認(rèn)知往往具有層次的特性。從粗到細(xì)、從一般到特殊。采用不同的層次來(lái)描述，適于認(rèn)知的過(guò)程。使用用例開(kāi)發(fā)系統(tǒng)的一般過(guò)程。在開(kāi)發(fā)過(guò)程的初始階段，可以根據(jù)具體的項(xiàng)目特點(diǎn)，制訂開(kāi)發(fā)各個(gè)視圖之間的關(guān)聯(lián)原則，指導(dǎo)規(guī)范。在開(kāi)發(fā)的過(guò)程中，視圖的組織原則應(yīng)不斷進(jìn)行維護(hù)、更新?！?/p>

    識(shí)別ACTOR來(lái)識(shí)別系統(tǒng)與外界交互的實(shí)體。ACTOR具有特定領(lǐng)域的特征，例如：交換機(jī)（采集系統(tǒng)）、97信息系統(tǒng)等。在系統(tǒng)層次的ACTOR確定了系統(tǒng)的邊界。

    識(shí)別用例。同ACTOR一樣，用例具有不同層次。對(duì)較為概括的USECASE，需要細(xì)化。注：系統(tǒng)開(kāi)發(fā)需要一定的規(guī)則來(lái)確定，如何來(lái)分解用例；可能基于原有系統(tǒng)的經(jīng)驗(yàn)，或是參考現(xiàn)有資料。　

    當(dāng)用例細(xì)化到可以被理解的層次。需要基于用例進(jìn)行下一步的開(kāi)發(fā)。如前面提到的，用例主要用來(lái)描述交互。因此，存在交互的實(shí)體和交互的細(xì)節(jié)。交互的實(shí)體采用類圖來(lái)描述；而交互的細(xì)節(jié)，采用順序圖來(lái)描述。

    當(dāng)系統(tǒng)復(fù)雜到一定層次時(shí)，類圖和順序圖可能不能足以描述其復(fù)雜程度。在該情況下，需要使用狀態(tài)圖來(lái)輔助闡述。狀態(tài)圖和順序圖之間使用事件聯(lián)結(jié)在一起。它們之間的一致性問(wèn)題，目前UML和ROSE沒(méi)有提供解決方案。相對(duì)折衷的方法是使用事件的命名規(guī)范強(qiáng)制一致性?！?/p>

    可以說(shuō)，之前說(shuō)的所有的東西都是為了能夠?qū)С鲇美谛枨笾械淖饔?。用例是從用戶的角度看待系統(tǒng)，而不是基于程序員的角度。這樣的話，用例驅(qū)動(dòng)的系統(tǒng)能夠真正做到以用戶為中心，用戶的任何需求都能夠在系統(tǒng)開(kāi)發(fā)鏈中完整的體現(xiàn)。用戶和程序員間通過(guò)用例溝通，避免了牛頭馬嘴的尷尬局面。從前，系統(tǒng)開(kāi)發(fā)者總是用于開(kāi)發(fā)的流程。當(dāng)系統(tǒng)的開(kāi)發(fā)過(guò)程都是基于用例的，用用例獲取需求，用用例設(shè)計(jì)，用用例編碼，用用例測(cè)試的時(shí)候。這個(gè)開(kāi)發(fā)過(guò)程就是用例驅(qū)動(dòng)的。用例和用例文檔《軟件需求》一書(shū)中提到了幾種方法來(lái)確定用例：

    首先明確執(zhí)行者和他們的角色，然后確定業(yè)務(wù)過(guò)程，在這一過(guò)程中每一個(gè)參與者都在為確定用例而努力。確定系統(tǒng)所能反映的外部事件，然后把這些事件與參與的執(zhí)行者和特定的用例聯(lián)系起來(lái)。能需求，這些功能需求可以使用戶完成其任務(wù)，也可以把它們描述成非功能需求，這些非功能需求描述了系統(tǒng)的限制和用戶對(duì)質(zhì)量的期望。雖然最初的屏幕構(gòu)思有助于描述你對(duì)需求的理解，但是你必須細(xì)化用戶界面設(shè)計(jì)。建立用例文檔。在每一次的需求獲取之后，都會(huì)生成很多未整理的需求，你必須將它們組織成用例文檔。使用諸如模板的技術(shù)能夠提高你的速度和需求的復(fù)用性。一個(gè)用例文檔可以使用表格來(lái)組織，主要的要素包括了用例標(biāo)識(shí)號(hào)、用例名稱、父用例標(biāo)志號(hào)、創(chuàng)建者、創(chuàng)建時(shí)間、審核者、修訂記錄、角色、說(shuō)、先決條件、請(qǐng)求結(jié)果、優(yōu)先級(jí)、普通過(guò)程、可選過(guò)程、例外、非功能需求、假設(shè)、注釋和問(wèn)題。雖然列舉出了這么多的屬性，但是實(shí)際中使用的屬性這要看你的團(tuán)體而定，看項(xiàng)目的大小而定。把大量的時(shí)間花在用例的描述上是沒(méi)有意義的。用戶需要的是一個(gè)軟件系統(tǒng)，并不是一大堆的用例說(shuō)明。