解決方案。相對折衷的方法是使用事件的命名規(guī)范強制一致性?！?BR> 可以說，之前說的所有的東西都是為了能夠?qū)С鲇美谛枨笾械淖饔?。用例是從用戶的角度看待系統(tǒng)，而不是基于程序員的角度。這樣的話，用例驅(qū)動的系統(tǒng)能夠真正做到以用戶為中心，用戶的任何需求都能夠在系統(tǒng)開發(fā)鏈中完整的體現(xiàn)。用戶和程序員間通過用例溝通，避免了牛頭馬嘴的尷尬局面。從前，系統(tǒng)開發(fā)者總是用于開發(fā)的流程。當(dāng)系統(tǒng)的開發(fā)過程都是基于用例的，用用例獲取需求，用用例設(shè)計，用用例編碼，用用例測試的時候。這個開發(fā)過程就是用例驅(qū)動的。用例和用例文檔《軟件需求》一書中提到了幾種方法來確定用例：
首先明確執(zhí)行者和他們的角色，然后確定業(yè)務(wù)過程，在這一過程中每一個參與者都在為確定用例而努力。確定系統(tǒng)所能反映的外部事件，然后把這些事件與參與的執(zhí)行者和特定的用例聯(lián)系起來。能需求，這些功能需求可以使用戶完成其任務(wù)，也可以把它們描述成非功能需求，這些非功能需求描述了系統(tǒng)的限制和用戶對質(zhì)量的期望。雖然最初的屏幕構(gòu)思有助于描述你對需求的理解，但是你必須細化用戶界面設(shè)計。建立用例文檔。在每一次的需求獲取之后，都會生成很多未整理的需求，你必須將它們組織成用例文檔。使用諸如模板的技術(shù)能夠提高你的速度和需求的復(fù)用性。一個用例文檔可以使用表格來組織，主要的要素包括了用例標(biāo)識號、用例名稱、父用例標(biāo)志號、創(chuàng)建者、創(chuàng)建時間、審核者、修訂記錄、角色、說、先決條件、請求結(jié)果、優(yōu)先級、普通過程、可選過程、例外、非功能需求、假設(shè)、注釋和問題。雖然列舉出了這么多的屬性，但是實際中使用的屬性這要看你的團體而定，看項目的大小而定。把大量的時間花在用例的描述上是沒有意義的。用戶需要的是一個軟件系統(tǒng)，并不是一大堆的用例說明。
項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~
http://opto-elec.com.cn/pmqhd/index.html
