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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

19、rawandharbison1997 ）。 ivarjacobson （ 1992 ）把這種看法系統(tǒng)地闡述成用例 （用例） 的方法進(jìn)行需求獲取和建模。 雖然用例來源于面向?qū)ο蟮拈_發(fā)環(huán)境， 但是它也能應(yīng)用在具有許多開發(fā)方法的項(xiàng)目中， 因?yàn)橛脩舨⒉魂P(guān)心你是怎樣開發(fā)你的件。 而最重要的， 用例的觀點(diǎn)和思維過程帶給需求開發(fā)的改變比起是否畫正式的用例圖顯得更為重要。 注意用戶要利用系統(tǒng)做什么遠(yuǎn)遠(yuǎn)強(qiáng)于詢問用戶希望系統(tǒng)為他們做什么這一傳統(tǒng)方法。 用例的重要功能是用畫用例圖的功能來鑒別和劃分系統(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)特定的刺激時系統(tǒng)的活動。 這些活動被文本描述。 它描述了觸發(fā)用例的刺激的本質(zhì)， 輸入和輸出到其他活動者， 和轉(zhuǎn)換輸入到輸出的活動。 用例文本通常也描述每一個活動在特殊的活動線時可能的錯誤和系統(tǒng)應(yīng)采取的補(bǔ)救措施。 這樣說可能會非常復(fù)雜，其實(shí)一個用例描述了系統(tǒng)和一個角色（ actor ）的交互順序。用例被定義成系統(tǒng)執(zhí)行的一系列動作， 動作執(zhí)行的結(jié)果能被指定角色察覺到。例可以 :用例捕獲某些用戶可見的需求，實(shí)現(xiàn)一個具體

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

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

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

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

25、做市場調(diào)查， 并根據(jù)統(tǒng)計(jì)學(xué)的理論建立你的數(shù)學(xué)模型。 這部分的工作效果最好， 其性質(zhì)有些象一些游戲公司會發(fā)布一些demo 版的游戲。是對于一般的企業(yè)來說，這項(xiàng)工作費(fèi)時費(fèi)力，高昂的成本往往使大家知難而退。 我的意見是， 方法是非常好的， 但是可以軟件技術(shù)并不熟悉；第二種是開發(fā)過同類軟件的軟件專家， 這種人在開發(fā)同類軟件過程中已經(jīng)積累了大量的項(xiàng)目經(jīng)驗(yàn)， 并且具有軟件開發(fā)的知識。 這種方式是獲取需求的最好的方式。分析對比同類軟件， 微軟在開發(fā)office 、 visualstudio 的時候， 也是參照了 lotus和 borland 的成熟產(chǎn)品。這種方式的特點(diǎn)在于成本很低，比較適合和其他的方 式配合

26、使用。但是，要注意自己有沒有觸犯專利法。有的時候，雖然已經(jīng)將用戶分類并選出了用戶代表。 但是需求的來源眾多， 往往會發(fā)生需求之間自相矛盾的事情。 需求從四面八方收集來后， 人們難以解決沖突， 澄清模糊之處以及協(xié)調(diào)不一致之處。 某些人還要對不可避免要發(fā)生的范圍問題單獨(dú)作出決定。 在項(xiàng)目的早期階段， 你必須決定誰是需求問題的決策者。 如果不清楚誰有權(quán)并且有責(zé)任來作出決策， 或者授權(quán)的個人不愿意或不能作出決策， 那么決策者的角色將自然而然地落在開發(fā)者身上。 這是一個非常糟糕的選擇， 因?yàn)殚_發(fā)者通常沒有足夠多的信息和觀點(diǎn)來作出業(yè)務(wù)上的決策。在軟件項(xiàng)目中， 誰將對需求作出決策的問題并沒有統(tǒng)一的正確答案。

27、 分析員有時聽從呼聲高的或來自最高層人物的最大的需求。 即便使用用戶代表這一手段， 必須解決來自不同用戶類的相沖突的需求。 通常， 應(yīng)盡可能由處于公司底層的人作出決策，因?yàn)樗麄兣c題密切相關(guān)，并能得到關(guān)于這些問題的廣泛信息。如果不同的用戶類有不一致的需求， 那么必須決策出滿足哪一類用戶的需求更為重要。 了解可能使用產(chǎn)品的客戶種類的信息和他們的用法與產(chǎn)品的業(yè)務(wù)目標(biāo)的關(guān)系如何，將有助于你決定哪一個用戶類所占份額最大。用例圖適于表達(dá)交互，之所以上面使用了電信系統(tǒng)，是因?yàn)橛美钤鐏碜杂趀ricsson 的交換機(jī)系統(tǒng)。當(dāng)時，還是ericsson 雇員的 jacobson 初步建立了用例圖的概念，并于 19

28、94 年提出了 oose 方法，其最大特點(diǎn)是面向用例( use-case )，并在用例的描述中引入了外部角色的概念。用例的概念是精確描述需求的重要武器， 比較適合支持商業(yè)工程和需求分析。 隨著用例的發(fā)展， 用例被大量的用于對功能進(jìn)行描述。每個用例代表了系統(tǒng)與外部actor 的交互?？梢圆扇№樞驁D來表達(dá)用例的具體操作程序。 actor 用于確定系統(tǒng)的邊界。actor 、用例可以從不同的層次來描述信息。采用該原則的原因有：1 .需求并不是在項(xiàng)目一開始就很明確，往往是隨著項(xiàng)目的推進(jìn)，逐漸細(xì)化。2 .人的認(rèn)知往往具有層次的特性。從粗到細(xì)、從一般到特殊。采用不同的層次來描述， 適于認(rèn)知的過程。 使用用例開發(fā)系統(tǒng)的一般過程。 在開發(fā)過程的初始階段，可以根據(jù)具體的項(xiàng)目特點(diǎn)， 制訂開發(fā)各個視圖之間的關(guān)聯(lián)原則， 指導(dǎo)規(guī)范。 在開發(fā)的過程中，視圖的組織原則應(yīng)不斷進(jìn)行維護(hù)、更新。識別 actor 來識別系統(tǒng)與外界交互的實(shí)體。 actor 具有特定領(lǐng)域的特征，例如：交換機(jī)（采集系統(tǒng)）、 97 信息系統(tǒng)等。在系統(tǒng)層次的 actor 確定了系統(tǒng)的邊界。識別用例。同actor 一樣，用例具有不同層次。對較為概括的 usecase,需要細(xì)化。注：系統(tǒng)開發(fā)需要一定的規(guī)則來確定，如何來分解用例；