如何對(duì)電子商務(wù)系統(tǒng)進(jìn)行需求分析

1、如何對(duì)電子商務(wù)系統(tǒng)進(jìn)行需求分析一、需求分析在具體的研究需求分析之前， 我們先了解一下軟件工程這個(gè)概念。 軟件工程分為三個(gè)層次，過(guò)程層、方法層、工具層。在最基礎(chǔ)的過(guò)程層，最重要的就是一組被稱為關(guān)鍵過(guò)程區(qū)域（kpas）的框架（kpa的概念在討論cmm的書中有詳細(xì)的概念說(shuō)明） 。 關(guān)鍵過(guò)程區(qū)域構(gòu)成了軟件項(xiàng)目的管理控制的基礎(chǔ)， 并且確立了上下文各區(qū)域的關(guān)系， 其中規(guī)定了技術(shù)方法的采用、 工程產(chǎn)品的， 模型、 文檔、 數(shù)據(jù)、報(bào)告、表格等，等的產(chǎn)生、里程碑的建立、質(zhì)量的保證及變化的適當(dāng)管理。方法層主要是過(guò)程在技術(shù)上的實(shí)現(xiàn)。 它解決的問(wèn)題是如何做。 軟件工程方法涵蓋了一系列的任務(wù)：需求分析、設(shè)計(jì)、編程、測(cè)試

2、、維護(hù)。同時(shí)他還包括了一組基本原則， 控制了每一個(gè)的關(guān)鍵過(guò)程區(qū)域。 工具層就很好理解了， 他對(duì)過(guò)程層和方法層提供了自動(dòng)和半自動(dòng)的支持。這些輔助工具就稱為 case?？梢钥吹叫枨蠓治龅奈恢茫鞘聦?shí)上需求分析是跨越了軟件工程的三個(gè)層次的。 這一點(diǎn)是和其他的過(guò)程是一樣的。 當(dāng)然我們這里比較重點(diǎn)強(qiáng)調(diào)的是在軟件工程的方法層， 同時(shí)也涉及到一些過(guò)程層的思想， 至于工具層則不再我們的討論之列， 但是會(huì)提到一些很適合在需求分析時(shí)應(yīng)用的工具， 諸如 word 、 excel 、 visio等。 方法需求分析都包括了哪些方法呢？這里列舉出在 需求分析 一書中推薦的一些方法。1） 繪制系統(tǒng)關(guān)聯(lián)圖， 這種關(guān)聯(lián)圖是用

3、于定義系統(tǒng)與系統(tǒng)外部實(shí)體間的界限和接口的簡(jiǎn)單模型。同時(shí)它也明確了通過(guò)接口的信息流和物質(zhì)流。2）創(chuàng)建用戶接口原型， 當(dāng)開(kāi)發(fā)人員或用戶不能確定需求時(shí)， 開(kāi)發(fā)一個(gè)用戶接口原型一個(gè)可能的局部實(shí)現(xiàn)這樣使得許多概念和可能發(fā)生的事更為直觀明了。用戶通過(guò)評(píng)價(jià)原型將使項(xiàng)目參與者能更好地相互理解所要解決的問(wèn)題。 注意要找出需求文檔與原型之間所有的沖突之處。3）分析需求可行性，在允許的成本、性能要求下，分析每項(xiàng)需求實(shí)施的可行性，明確與每項(xiàng)需求實(shí)現(xiàn)相聯(lián)系的風(fēng)險(xiǎn)， 包括與其它需求的沖突， 對(duì)外界因素的依賴和技術(shù)障礙。4） 確定需求的優(yōu)先級(jí)別， 應(yīng)用分析方法來(lái)確定使用實(shí)例、 產(chǎn)品特性或單項(xiàng)需求實(shí)現(xiàn)的優(yōu)先級(jí)別。 以優(yōu)先級(jí)為

4、基礎(chǔ)確定產(chǎn)品版本將包括哪些特性或哪類需求。 當(dāng)允許需求變更時(shí)， 在特定的版本中加入每一項(xiàng)變更， 并在那個(gè)版本計(jì)劃中作出需要的變更。5）為需求建立模型，需求的圖形分析模型是軟件需求規(guī)格說(shuō)明極好的補(bǔ)充說(shuō)明。它們能提供不同的信息與關(guān)系以有助于找到不正確的、 不一致的、 遺漏的和冗余的需求。這樣的模型包括數(shù)據(jù)流圖、實(shí)體關(guān)系圖、狀態(tài)變換圖、對(duì)話框圖、對(duì)象類及交互作用圖。6）創(chuàng)建數(shù)據(jù)字典， 數(shù)據(jù)字典是對(duì)系統(tǒng)用到的所有數(shù)據(jù)項(xiàng)和結(jié)構(gòu)的定義， 以確保開(kāi)發(fā)人員使用統(tǒng)一的數(shù)據(jù)定義。 在需求階段， 數(shù)據(jù)字典至少應(yīng)定義客戶數(shù)據(jù)項(xiàng)以確?？蛻襞c開(kāi)發(fā)小組是使用一致的定義和術(shù)語(yǔ)。 分析和設(shè)計(jì)工具通常包括數(shù)據(jù)字典組件。7）使用質(zhì)

5、量功能調(diào)配， （qfd ）是一種高級(jí)系統(tǒng)技術(shù)，它將產(chǎn)品特性、屬性與對(duì)客戶的重要性聯(lián)系起來(lái)。 該技術(shù)提供了一種分析方法以明確那些是客戶最為關(guān)注的特性。 qfd 將需求分為三類：期望需求，即客戶或許并未提及，但如若缺少會(huì)讓他們感到不滿意；普通需求；興奮需求，即實(shí)現(xiàn)了會(huì)給客戶帶去驚喜，但若未實(shí)現(xiàn)也不會(huì)受到責(zé)備（ zultner1993;pardee1996 ）。記住一點(diǎn)， 不要試圖在你的項(xiàng)目中把這些方法都用上去， 四個(gè)現(xiàn)代化并不是一夜就可以實(shí)現(xiàn)的。 同樣， 嘗試著使用你認(rèn)為對(duì)你很有幫助的方法， 確實(shí)收到效果之后，在考慮繼續(xù)學(xué)習(xí)方法。因?yàn)樯厦嫣岬降亩际切枨蠓治龅拇蠓椒ǎ聦?shí)號(hào)、記錄業(yè)務(wù)規(guī)范、 創(chuàng)建需求

6、跟蹤能力矩陣、 審查需求文檔、 以需求為依據(jù)編寫測(cè)試用例、編寫用戶手冊(cè)、確定合格的標(biāo)準(zhǔn)。二、業(yè)務(wù)建模很多人都沒(méi)有意識(shí)到業(yè)務(wù)需求階段應(yīng)該做些什么事情， 實(shí)際上業(yè)務(wù)建模是最重要的一件事情。 不要覺(jué)得業(yè)務(wù)建模這個(gè)詞很深?yuàn)W， 讓人模不著頭腦。 其實(shí)所有做過(guò)需求分析的人都做過(guò)業(yè)務(wù)建模，比如你了解企業(yè)的運(yùn)作模式就?是一種你腦海中的業(yè)務(wù)建模。但是大多數(shù)人都沒(méi)有科學(xué)的、系統(tǒng)的、文檔化的做過(guò)業(yè)務(wù)建模。業(yè)務(wù)建模的目的在于：了解目標(biāo)組織（將要在其中部署系統(tǒng)的組織）的結(jié)構(gòu)及機(jī)制。了解目標(biāo)組織中當(dāng)前存在的問(wèn)題并確定改進(jìn)的可能性。確保客戶、最終用戶和開(kāi)發(fā)人員就目標(biāo)組織達(dá)成共識(shí)。導(dǎo)出支持目標(biāo)組織所需的業(yè)務(wù)需求。上面的話是不

7、是很抽象呢， 其實(shí)沒(méi)有什么復(fù)雜的： 人和電腦是完全不同的思想 （思維方式）。所以，原先適合人的業(yè)務(wù)流程對(duì)于計(jì)算機(jī)來(lái)說(shuō)可不一定合適的，為了最大限度的利用計(jì)算機(jī)， 必須要了解原先的業(yè)務(wù)流程并對(duì)此加易改造 （流程自動(dòng)化），當(dāng)然這些動(dòng)作需要得到用戶的許可。有些人認(rèn)為說(shuō)只有erp這種大系統(tǒng)才需要對(duì)業(yè)務(wù)流程進(jìn)行重組，但是實(shí)際，不論是部門級(jí)的 mis 系統(tǒng)，還是社會(huì)級(jí)的電子商務(wù)系統(tǒng)，都需要對(duì)業(yè)務(wù)流程進(jìn)行改造，所不同的只是改造的程度。業(yè)務(wù)建模很重要的一點(diǎn)是在分析企業(yè)流程的同時(shí)分析出基礎(chǔ)企業(yè)對(duì)象（ commonbusinessobject ） （這個(gè)詞我翻譯的不好， 如果大家有更好的翻譯，請(qǐng)告訴我）。任何企業(yè)都

8、有最基礎(chǔ)的一些元素，例如銀行的 cbo 就有帳戶，制造業(yè)的 cb 對(duì)多，訂單和產(chǎn)品之間又是一對(duì)多，這樣一個(gè)多對(duì)多的關(guān)系就拆分成兩個(gè)一對(duì)多的關(guān)系， 而新的訂單類也就順理成章的產(chǎn)生了。 在訂單類產(chǎn)生時(shí)， 你可能還會(huì)加入一個(gè)關(guān)聯(lián)類： 業(yè)務(wù)員類。 而業(yè)務(wù)員類又是從員工類繼承下來(lái)的。 所以呢，企業(yè)的四種cbo 通過(guò)不同的組合，不同的關(guān)系，能夠形成企業(yè)運(yùn)作的許許多多的 cbo 。cbo 是做業(yè)務(wù)建模的基礎(chǔ)，在此基礎(chǔ)上，通過(guò)評(píng)估業(yè)務(wù)狀態(tài)，說(shuō)明當(dāng)前業(yè)務(wù)， 確定業(yè)務(wù)流程，改進(jìn)業(yè)務(wù)流程的定義，設(shè)計(jì)業(yè)務(wù)流程實(shí)現(xiàn)，改進(jìn)角色和職責(zé)，研究流程自動(dòng)化，開(kāi)發(fā)領(lǐng)域模型等一系列在rup 中定義的工作流程實(shí)現(xiàn)業(yè)務(wù)建模的目標(biāo)。三、需

9、求獲取需求獲取 (requirementelicitation) 是需求工程的主體。 對(duì)于所建議的軟件產(chǎn)品，獲取需求是一個(gè)確定和理解不同用戶類的需要和限制的過(guò)程。 獲取用戶需求位于軟件需求三個(gè)層次的中間一層。 業(yè)務(wù)需求決定用戶需求， 它描述了用戶利用系統(tǒng)需要完成的任務(wù)。 從這些任務(wù)中， 分析者能獲得用于描述系統(tǒng)活動(dòng)的特定的軟件功能需求， 這些系統(tǒng)活動(dòng)有助于用戶執(zhí)行他們的任務(wù)。 需求獲取是在問(wèn)題及其最終解決方案之間架設(shè)橋梁的第一步。 獲取需求的一個(gè)必不可少的結(jié)果是對(duì)項(xiàng)目中描述的客戶需求的普遍理解。 一旦理解了需求， 分析者、 開(kāi)發(fā)者和客戶就能探索出描述這些需求的多種解決方案。 參與需求獲取者只有

10、在他們理解了問(wèn)題之后才能開(kāi)始設(shè)計(jì)系統(tǒng)，否則，對(duì)需求定義的任何改進(jìn)，設(shè)計(jì)上都必須大量的返工。把需求獲取集中在用戶任務(wù)上而不是集中在用戶接口上有助于防止開(kāi)發(fā)組由于草率處理設(shè)計(jì)問(wèn)題而造成的失誤。 需求獲取、 分析、 編寫需求規(guī)格說(shuō)明和驗(yàn)證并不遵循線性的順序， 這些活動(dòng)是相互隔開(kāi)、 增量和反復(fù)的。 當(dāng)你和客戶合作時(shí)，你就將會(huì)問(wèn)一些問(wèn)題，并且取得他們所提供的信息(需求獲取)。同時(shí)，你將處理這些信息以理解它們， 并把它們分成不同的類別， 要交流的方面。 需求獲取只有通過(guò)有效的客戶開(kāi)發(fā)者的合作才能成功。 分析者必須建立一個(gè)對(duì)問(wèn)題進(jìn)行徹底探討的環(huán)境， 而這些問(wèn)題與產(chǎn)品有關(guān)。 為了方便清晰地進(jìn)行交流， 就要列出

11、重要的小組， 而不是假想所有的參與者都持有相同的看法。 對(duì)需求問(wèn)題的全面考察需要一種技術(shù)， 利用這種技術(shù)不但考慮了問(wèn)題的功能需求方面， 還可討論項(xiàng)目的 非功能需求。 確定用戶已經(jīng)理解： 對(duì)于某些功能的討論并不意味著即將在產(chǎn)品中實(shí)現(xiàn)它。對(duì)于想到的需求必須集中處理并設(shè)定優(yōu)先級(jí)?，以避免一個(gè)不能帶來(lái)任何益處的無(wú)限大的項(xiàng)目。 需求獲取是一個(gè)需要高度合作的活動(dòng)， 而并不是客戶所說(shuō)的需求的簡(jiǎn)單謄本。 作為一個(gè)分析者， 你必須透過(guò)客戶所提出的表面需求理解他們的真正需求。詢問(wèn)一個(gè)可擴(kuò)充( open-ended )的問(wèn)題有助于你更好地理解用戶目前的業(yè)務(wù)過(guò)程并且知道新系統(tǒng)如何幫助或改進(jìn)他們的工作。 調(diào)查用戶任務(wù)可

12、能遇到的變更， 或者用戶需要使用系統(tǒng)其它可能的方式。 想像你自己在學(xué)習(xí)用戶的工作， 你需要完成什么任務(wù)？你有什么問(wèn)題？從這一角度來(lái)指導(dǎo)需求的開(kāi)發(fā)和利用。還有， 探討例外的情況： 什么會(huì)妨礙用戶順利完成任務(wù)？對(duì)系統(tǒng)錯(cuò)誤情況的反映，用戶是如何想的？詢問(wèn)問(wèn)題時(shí)，以“還有什么能” ?時(shí)，將會(huì)發(fā)生什 , ”當(dāng)么”“你有沒(méi)有曾經(jīng)想過(guò)” , “有沒(méi)有人曾經(jīng)”為開(kāi)頭。 記下每一個(gè)需求的來(lái)源，這樣向下跟蹤直到發(fā)現(xiàn)特定的客戶。需求討論會(huì)上必須要使用筆記本電腦， 還要指定一個(gè)打字熟練的人把所有的討論記錄下來(lái)， 記錄的同時(shí)還要做一定的整理。 如果不這樣做， 那么你結(jié)束會(huì)議的時(shí)候就會(huì)發(fā)現(xiàn)， 所有的討論只剩下一個(gè)模糊的印

13、象， 需求對(duì)你來(lái)說(shuō)仍然是一件遙遠(yuǎn)的事情。在座談?dòng)懻撝?，記下所討論的條目 (item) ，并請(qǐng)參與討論的用戶評(píng)論并更正。 及早并經(jīng)常進(jìn)行座談?dòng)懻撌切枨螳@取成功的一個(gè)關(guān)鍵途徑， 因?yàn)橹挥刑峁┬枨蟮娜瞬拍艽_定是否真正獲取需求。 進(jìn)行深入收集和分析以消除任何沖突或不一致性。盡量把客戶所持的假設(shè)解釋清楚， 特別是那些發(fā)生沖突的部分。 從字里行間去理解以明確客戶沒(méi)有表達(dá)清楚但又想加入的特性或特征。 gause 和 weinberg1989 ）提出使用“上下文無(wú)關(guān)問(wèn)題”這是一個(gè)高層次的問(wèn)題，它可以獲取 業(yè)務(wù)問(wèn)題和可能的解決方案的全部信息。 客戶對(duì)這些問(wèn)題的回答諸如“產(chǎn)品要求怎樣的精確度”或“你能幫我解釋一

14、下你為什么不同意某人的回答嗎？”這些回答可以更直接地認(rèn)識(shí)問(wèn)題，而這是封閉（ close-end ）問(wèn)題所不能做到的。需求獲取利用了所有可用的信息來(lái)源， 這些信息描述了問(wèn)題域或在軟件解決方案中合理的特性。 一個(gè)研究表明： 比起不成功的項(xiàng)目， 一個(gè)成功的項(xiàng)目在開(kāi)發(fā)者和客戶之間采用了更多的交流方式（ kielandcarmel1995 ）。與單個(gè)客戶或潛在的用戶組一起座談，對(duì)于業(yè)務(wù)軟件包或信息管理系統(tǒng)（ mis ）的應(yīng)用來(lái)說(shuō)是一種傳統(tǒng)的需求來(lái)源。直接聘請(qǐng)用戶進(jìn)行獲取需求的過(guò)程是為項(xiàng)目獲得支持和買入（ buy-in ）的一種方式。盡量理解用戶用于表述他們需求的思維過(guò)程。 充分研究用戶執(zhí)行任務(wù)時(shí)作出決策

15、的過(guò)程， 并提取出潛在的邏輯關(guān)系。 流程圖和決策樹(shù)是描述這些邏輯決策途徑的好方法。在需求獲取的過(guò)程中， 你可能會(huì)發(fā)現(xiàn)對(duì)項(xiàng)目范圍的定義存在誤差， 不是太大就是太小。 如果范圍太大， 你將要收集比真正需要更多的需求， 以傳遞足夠的業(yè)務(wù)和客戶的值， 此時(shí)獲取過(guò)程將會(huì)拖延。 如果項(xiàng)目范圍太小， 那么客戶將會(huì)提出很重要的但又在當(dāng)前產(chǎn)品范圍之外的需求。 當(dāng)前的范圍太小， 以致不能提供一個(gè)令人滿意的產(chǎn)品。 需求的獲取將導(dǎo)致修改項(xiàng)目的范圍和任務(wù)， 但作出這樣具有深遠(yuǎn)影響的改變，一定要小心謹(jǐn)慎。正如經(jīng)常所說(shuō)的，需求主要是關(guān)于系統(tǒng)做什么，而解決方案如何實(shí)現(xiàn)是屬于設(shè)計(jì)的范圍。這樣說(shuō)雖然很簡(jiǎn)潔，但似乎過(guò)于簡(jiǎn)單化。需求

16、的獲取應(yīng)該把重點(diǎn)放在“做什么”上， 但在分析和設(shè)計(jì)之間還是存在一定的在需求的距離。 你可以使用假設(shè)“怎么做”來(lái)分類并改善你對(duì)用戶需求的理解。獲取過(guò)程中， 分析模型、 屏幕圖形和原型可以使概念表達(dá)得更加清楚， 然后提供一個(gè)尋找錯(cuò)誤和遺漏的辦法。 把你在需求開(kāi)發(fā)階段所形成的模型和屏幕效果看成是方便高效交流的概念性建議， 而不應(yīng)該看成是對(duì)設(shè)計(jì)者選擇的一種限制。 需求獲取討論會(huì)中如果參與者過(guò)多，就會(huì)減慢進(jìn)度。人數(shù)大致控制在5 到 7 人是最好的。這些人包括客戶、系統(tǒng)設(shè)計(jì)者、開(kāi)發(fā)者和可視化設(shè)計(jì)者等主要工程角色。相反地， 從極少的代表那里收集信息或者只聽(tīng)到呼聲最高、 最有輿論影響的用戶的聲音， 也會(huì)造成問(wèn)

17、題。 這將導(dǎo)致忽視特定用戶類的重要的需求， 或者其需求不能代表絕大多數(shù)用戶的需要。最?好的權(quán)衡在于選擇一些授權(quán)為他們的用戶類發(fā)言的產(chǎn)品代表者， 他們也被同組用戶類的其它代表所支持。 沒(méi)有一個(gè)簡(jiǎn)單、 清楚的信號(hào)暗示你什么時(shí)候已完成需求獲取。 當(dāng)客戶和開(kāi)發(fā)者與他們的同事聊天、 閱讀工業(yè)和商業(yè)上的文獻(xiàn)及在早上沐浴時(shí)思考時(shí)， 他們都將對(duì)潛在產(chǎn)品產(chǎn)生新的構(gòu)思。 你不可能全面收集需求， 但是下列的提示將會(huì)暗示你在需求獲取的過(guò)程中的返回點(diǎn)。1 .如果用戶不能想出更多的使用實(shí)例，也許你就完成了收集需求的工作。用戶總是按其重要性的順序來(lái)確定使用實(shí)例的。2 .如果用戶提出新的使用實(shí)例， 但你可以從其它使用實(shí)例的相

18、關(guān)功能需求中獲得這些新的使用實(shí)例， 這時(shí)也許你就完成了收集需求的工作。 這些新的使用實(shí)例可能是你已獲取的其它使用實(shí)例的可選過(guò)程。3 .如果用戶開(kāi)始重復(fù)原先討論過(guò)的問(wèn)題， 此時(shí)， 也許你就完成了收集需求的工作。4 .如果所提出的新需求比你已確定的需求的優(yōu)先級(jí)都低時(shí)， 也許你就完成了收集 需求的工作。5 .如果用戶提出對(duì)將來(lái)產(chǎn)品的要求，而不是現(xiàn)在我們討論的特定產(chǎn)品，也許你就完成了收集需求的工作。以上知識(shí)大致上討論需求分析應(yīng)該如何做， 實(shí)際上對(duì)于需求分析的方法有很多很多，已經(jīng)形成了一定的用例在需求分析中的使用。多年來(lái)， 分析者總是利用情節(jié)或經(jīng)歷來(lái)描述用戶和軟件系統(tǒng)的交互方式， 從而獲取需求（ mcg

19、rawandharbison1997 ）。 ivarjacobson （ 1992 ）把這種看法系統(tǒng)地闡述成用例 （用例） 的方法進(jìn)行需求獲取和建模。 雖然用例來(lái)源于面向?qū)ο蟮拈_(kāi)發(fā)環(huán)境， 但是它也能應(yīng)用在具有許多開(kāi)發(fā)方法的項(xiàng)目中， 因?yàn)橛脩舨⒉魂P(guān)心你是怎樣開(kāi)發(fā)你的件。 而最重要的， 用例的觀點(diǎn)和思維過(guò)程帶給需求開(kāi)發(fā)的改變比起是否畫正式的用例圖顯得更為重要。 注意用戶要利用系統(tǒng)做什么遠(yuǎn)遠(yuǎn)強(qiáng)于詢問(wèn)用戶希望系統(tǒng)為他們做什么這一傳統(tǒng)方法。 用例的重要功能是用畫用例圖的功能來(lái)鑒別和劃分系統(tǒng)功能。它把系統(tǒng)分成角色（ actor ）和用例（用例）。角色（actor） 表示系統(tǒng)用戶能扮演的角色（ role ）

20、。這些用戶可能是人，可能是其他的計(jì)算機(jī)一些硬件或者甚至是其它軟件系統(tǒng)， 唯一的標(biāo)準(zhǔn)是它們必須要在被劃分進(jìn)用例的系統(tǒng)部分以外。 它們必須能刺激系統(tǒng)部分并接收返回。 用例描述了當(dāng)角色給系統(tǒng)特定的刺激時(shí)系統(tǒng)的活動(dòng)。 這些活動(dòng)被文本描述。 它描述了觸發(fā)用例的刺激的本質(zhì)， 輸入和輸出到其他活動(dòng)者， 和轉(zhuǎn)換輸入到輸出的活動(dòng)。 用例文本通常也描述每一個(gè)活動(dòng)在特殊的活動(dòng)線時(shí)可能的錯(cuò)誤和系統(tǒng)應(yīng)采取的補(bǔ)救措施。 這樣說(shuō)可能會(huì)非常復(fù)雜，其實(shí)一個(gè)用例描述了系統(tǒng)和一個(gè)角色（ actor ）的交互順序。用例被定義成系統(tǒng)執(zhí)行的一系列動(dòng)作， 動(dòng)作執(zhí)行的結(jié)果能被指定角色察覺(jué)到。例可以 :用例捕獲某些用戶可見(jiàn)的需求，實(shí)現(xiàn)一個(gè)具體

21、的用戶目標(biāo)。用例由角色激活， 并提供確切的值給角色。 用例可大可小， 但它必須是對(duì)一個(gè)具體的用戶目標(biāo)實(shí)現(xiàn)的完整描述。在uml 中，用例表示為一個(gè)橢圓。角色是指用戶在系統(tǒng)中所扮演的角色。 其圖形化的表示是一個(gè)小人。 在某些組織中很可能有許多角色實(shí)例(例如有很多個(gè)銷售員)，但就該系統(tǒng)而言，他們均起著同一種作用，扮演著相同的角色， 所以用一個(gè)角色表示。 一個(gè)用戶也可以扮演多種角色。 例如， 交換。單個(gè)角色可與多個(gè)用例聯(lián)系； 反過(guò)來(lái)， 一個(gè)用例可與多個(gè)角色聯(lián)系。 對(duì)同一個(gè)用例而言， 不同角色有著不同的作用： 他們可以從用例中取值， 也可以參與到用例中。 需要注意的是角色在用例圖中是用類似人的圖形來(lái)表示

22、， 盡管執(zhí)行的， 但角色未必是人。 例如， 角色也可以是一個(gè)外界系統(tǒng)， 該外界系統(tǒng)可能需要從當(dāng)前系統(tǒng)中獲取信息，與當(dāng)前系統(tǒng)有進(jìn)行交互。一個(gè)用例可能包括完成某項(xiàng)任務(wù)的許多邏輯相關(guān)任務(wù)和交互順序。 因此， 一個(gè)用例是相關(guān)的用法說(shuō)明的集合，并且一個(gè)說(shuō)明( scenario )是用例的實(shí)例。這種關(guān)系就像是類和對(duì)象的關(guān)系。在用例中，一個(gè)說(shuō)明被視為事件的普通過(guò)程(normalcourse) ，也叫作主過(guò)程，基本過(guò)程，普通流，或“滿意之路” (happypath) 在描述普通過(guò)程時(shí)列出執(zhí)行者和系統(tǒng)之間相互交互或?qū)υ挼?。順序。當(dāng)這種交互結(jié)束時(shí)，執(zhí)行者也達(dá)到了預(yù)期的目的。在用例中的其它說(shuō)明可以描述為可選過(guò)程(

23、alternativecoruse) 。 可選過(guò)程也可促進(jìn)成功地完成任務(wù)，但它們代表了任務(wù)的細(xì)節(jié)或用于完成任務(wù)的途徑的變化部分。 在交互序列中， 普通過(guò)程可以在一些決策點(diǎn)上分解成可選過(guò)程， 然后再重新匯成一個(gè)普通過(guò)程。角色類和角色實(shí)例。軟件產(chǎn)品最終是給一些用戶來(lái)使用的，而用戶之間的差異是非常大的。 造成差異的原因包括了對(duì)計(jì)算機(jī)的認(rèn)知程度的不 同，使用習(xí)慣的不同，在軟件目標(biāo)組織中所處的地位不同，地理位置不同，業(yè)務(wù)熟練程度不同。不同的用戶都有自己一系列的功能需求和非功能需求。 對(duì)電腦熟練程度不同的人可能就會(huì)有不同的要求， 熟練程度低的用戶可能希望有一個(gè)友好的界面， 熟練程度高的用戶可能更希望有快捷

24、鍵或宏的操作以提高工作效率。 考慮到用戶的差異性， 將用戶分類并研求。 抓住用戶代表的需求就大致把握住了用戶類的需求。 當(dāng)然， 需求分析還是需要在用戶中做大規(guī)模的調(diào)查的， 只是要把重點(diǎn)放在用戶代表上。確保和用戶直接進(jìn)行溝通！ 大家有沒(méi)有玩過(guò)傳話的游戲， 可能看過(guò)。 一群人排成一列，一句話從排頭挨個(gè)向后傳，到最后，那句話已經(jīng)是面目全非了。所以，一定要保證項(xiàng)目組能夠直接和用戶接觸。 對(duì)于和用戶直接溝通這一點(diǎn)， 一般的針對(duì)特定企業(yè)的應(yīng)用系統(tǒng)當(dāng)然是不成問(wèn)題， 可是如果是開(kāi)發(fā)行業(yè)軟件， 和用戶直接溝通就成為一件幾乎是不可能的事情。在這種情況下，一般有幾種解決的辦法：做大規(guī)模的市場(chǎng)調(diào)查， 針對(duì)你的目標(biāo)市場(chǎng)

25、做市場(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)在于成本很低，比較適合和其他的方 式配合

26、使用。但是，要注意自己有沒(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ù)上的決策。在軟件項(xiàng)目中， 誰(shuí)將對(duì)需求作出決策的問(wèn)題并沒(méi)有統(tǒng)一的正確答案。

27、 分析員有時(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è)用戶類所占份額最大。用例圖適于表達(dá)交互，之所以上面使用了電信系統(tǒng)，是因?yàn)橛美钤鐏?lái)自于ericsson 的交換機(jī)系統(tǒng)。當(dāng)時(shí)，還是ericsson 雇員的 jacobson 初步建立了用例圖的概念，并于 19

28、94 年提出了 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ù)、更新。識(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)分解用例；