解決方案。相對折衷的方法是使用事件的命名規(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)思有助于描述你對需求的理解,但是你必須細(xì)化用戶界面設(shè)計。建立用例文檔。在每一次的需求獲取之后,都會生成很多未整理的需求,你必須將它們組織成用例文檔。使用諸如模板的技術(shù)能夠提高你的速度和需求的復(fù)用性。一個用例文檔可以使用表格來組織,主要的要素包括了用例標(biāo)識號、用例名稱、父用例標(biāo)志號、創(chuàng)建者、創(chuàng)建時間、審核者、修訂記錄、角色、說、先決條件、請求結(jié)果、優(yōu)先級、普通過程、可選過程、例外、非功能需求、假設(shè)、注釋和問題。雖然列舉出了這么多的屬性,但是實際中使用的屬性這要看你的團體而定,看項目的大小而定。把大量的時間花在用例的描述上是沒有意義的。用戶需要的是一個軟件系統(tǒng),并不是一大堆的用例說明。
項目經(jīng)理勝任力免費測評PMQ上線啦!快來測測你排多少名吧~
http://m.opto-elec.com.cn/pmqhd/index.html