1、UI層和邏輯層大家的討論使我明白在設(shè)計(jì)多層結(jié)構(gòu)的程序時(shí)，層與層之間需要多用接口少用繼承，但為什么要用接口呢？比如邏輯層直接實(shí)例化一個(gè)數(shù)據(jù)訪問(wèn)層的類，然后調(diào)用數(shù)據(jù)訪問(wèn)層中相應(yīng)的方法返回一個(gè)數(shù)據(jù)源不就可以了嗎？這樣做也不關(guān)接口什么事呀在企業(yè)級(jí)程序開(kāi)發(fā)中，一般出于并發(fā)的考慮，可能需要較好的可伸縮性(就是可以把一套程序的不同結(jié)構(gòu)層放在不同的服務(wù)器上，我是這樣理解的)，這樣的話以的最簡(jiǎn)單的三層結(jié)構(gòu)舉例子，UI層和邏輯層應(yīng)該是放在同一臺(tái)服務(wù)器上(我不知道能不能把它們分到兩臺(tái)服務(wù)器中去)，我把它叫做UI&邏輯服務(wù)器，而數(shù)據(jù)訪問(wèn)層放在另一臺(tái)服務(wù)器中，我把它叫做數(shù)據(jù)訪問(wèn)服務(wù)器，還有一臺(tái)是存放數(shù)據(jù)庫(kù)

2、的服務(wù)器，這樣 UI&邏輯服務(wù)器 與 數(shù)據(jù)訪問(wèn)服務(wù)器 中的程序可能就是2(或以上)個(gè)人開(kāi)發(fā)的，兩臺(tái)服務(wù)器間的通訊一般是用WebService，這個(gè)我就不說(shuō)了。按我上面說(shuō)的，UI&邏輯服務(wù)器 中的程序應(yīng)該是可以直接調(diào)用 數(shù)據(jù)訪問(wèn)服務(wù)器 中的類，這本身沒(méi)什么問(wèn)題，但到具體開(kāi)發(fā)上時(shí)可能就會(huì)出問(wèn)題了，比如 UI&邏輯服務(wù)器 中的程序開(kāi)發(fā)人員甲在開(kāi)始設(shè)計(jì)的時(shí)候需要調(diào)用一個(gè) 數(shù)據(jù)訪問(wèn)服務(wù)器 中的GetData()的方法，但這個(gè)時(shí)候 數(shù)據(jù)訪問(wèn)服務(wù)器 中程序的開(kāi)發(fā)人員乙并不知道需要增加這個(gè)方法，那么甲的工作就繼續(xù)不下去了，因?yàn)樗某绦蚓幾g不了，假如這個(gè)時(shí)候甲定義了一個(gè)接口，然后在接口的定義中定義一個(gè)方法Get

3、Data()，當(dāng)然這個(gè)方法里什么代碼都不用寫(xiě)(具體的實(shí)現(xiàn)是由乙來(lái)做的)，然后乙寫(xiě)的程序都需要繼承甲定義的這個(gè)接口，當(dāng)乙的程序在編譯的時(shí)候就會(huì)被提示哪些方法是必須被實(shí)現(xiàn)的，這樣一來(lái)乙就隨時(shí)都可以知道甲需要哪些方法來(lái)返回?cái)?shù)據(jù)了，這樣做最起碼的好處是不用甲總需要告訴乙需要加哪些方法，而且也不會(huì)因?yàn)橐覍?duì)數(shù)據(jù)訪問(wèn)層程序的誤修改(比如誤刪除了GetData()這個(gè)方法)導(dǎo)致 UI&邏輯層的程序運(yùn)行不正常，因?yàn)槿绻麆h除了GetData()的話，乙的程序是編譯不了的。所以我的結(jié)論就是接口在層與層之間的作用主要是上層(比如UI&邏輯層)對(duì)下層(比如數(shù)據(jù)訪問(wèn)層)的一些限定，方便了開(kāi)發(fā)，減少了不必要的溝通，也防止了

4、一些出錯(cuò)的可能。不知道這種理解是否正確，還請(qǐng)大蝦指教需求分析的20條法則2009年08月27日 星期四 下午 11:272009-08-11 16:00需求分析的20條法則 邢學(xué)慧 -對(duì)商業(yè)用戶來(lái)說(shuō)，他們后面是成百上千個(gè)供應(yīng)商，前面是成千上萬(wàn)個(gè)消費(fèi)顧客。怎樣利用軟件管理錯(cuò)綜復(fù)雜的供應(yīng)商和消費(fèi)顧客，如何做好精細(xì)到一個(gè)小小調(diào)料包的進(jìn)、銷、調(diào)、存的商品流通工作，這些都是商業(yè)企業(yè)需要信息管理系統(tǒng)的理由。軟件開(kāi)發(fā)的意義也就在于此。而弄清商業(yè)用戶如此復(fù)雜需求的真面目，正是軟件開(kāi)發(fā)成功的關(guān)鍵所在。 -經(jīng)理：“我們要建立一套完整的商業(yè)管理軟件系統(tǒng)，包括商品的進(jìn)、銷、調(diào)、存管理，是總部-門(mén)店的連鎖經(jīng)營(yíng)模式。通過(guò)

5、通信手段門(mén)店自動(dòng)訂貨，供應(yīng)商自動(dòng)結(jié)算，賣場(chǎng)通過(guò)掃條碼實(shí)現(xiàn)銷售，管理人員能夠隨時(shí)查詢門(mén)店商品銷售和庫(kù)存情況。另外，我們也得為政府部門(mén)提供關(guān)于商品營(yíng)運(yùn)的報(bào)告?！?-分析員：“我已經(jīng)明白這個(gè)項(xiàng)目的大體結(jié)構(gòu)框架，這非常重要，但在制定計(jì)劃之前，我們必須收集一些需求。” -經(jīng)理覺(jué)得奇怪：“我不是剛告訴你我的需求了嗎？” -分析員：“實(shí)際上，您只說(shuō)明了整個(gè)項(xiàng)目的概念和目標(biāo)。這些高層次的業(yè)務(wù)需求不足以提供開(kāi)發(fā)的內(nèi)容和時(shí)間。我需要與實(shí)際將要使用系統(tǒng)的業(yè)務(wù)人員進(jìn)行討論，然后才能真正明白達(dá)到業(yè)務(wù)目標(biāo)所需功能和用戶要求，了解清楚后，才可以發(fā)現(xiàn)哪些是現(xiàn)有組件即可實(shí)現(xiàn)的，哪些是需要開(kāi)發(fā)的，這樣可節(jié)省很多時(shí)間?！?-經(jīng)理：

6、“業(yè)務(wù)人員都在招商。他們非常忙，沒(méi)有時(shí)間與你們?cè)敿?xì)討論各種細(xì)節(jié)。你能不能說(shuō)明一下你們現(xiàn)有的系統(tǒng)？” -分析員盡量解釋從用戶處收集需求的合理性：“如果我們只是憑空猜想用戶的要求，結(jié)果不會(huì)令人滿意。我們只是軟件開(kāi)發(fā)人員，而不是采購(gòu)專家、營(yíng)運(yùn)專家或是財(cái)務(wù)專家，我們并不真正明白您這個(gè)企業(yè)內(nèi)部運(yùn)營(yíng)需要做些什么。我曾經(jīng)嘗試過(guò)，未真正明白這些問(wèn)題就開(kāi)始編碼，結(jié)果沒(méi)有人對(duì)產(chǎn)品滿意?！?-經(jīng)理堅(jiān)持道：“行了，行了，我們沒(méi)有那么多的時(shí)間。讓我來(lái)告訴您我們的需求。實(shí)際上我也很忙。請(qǐng)馬上開(kāi)始開(kāi)發(fā)，并隨時(shí)將你們的進(jìn)展情況告訴我?！?-風(fēng)險(xiǎn)躲在需求的迷霧之后 -以上我們看到的是某客戶項(xiàng)目經(jīng)理與系統(tǒng)開(kāi)發(fā)小組的分析人員討論業(yè)

7、務(wù)需求。在項(xiàng)目開(kāi)發(fā)中，所有的項(xiàng)目風(fēng)險(xiǎn)承擔(dān)者都對(duì)需求分析階段備感興趣。這里所指的風(fēng)險(xiǎn)承擔(dān)者包括客戶方面的項(xiàng)目負(fù)責(zé)人和用戶，開(kāi)發(fā)方面的需求分析人員和項(xiàng)目管理者。這部分工作做得到位，能開(kāi)發(fā)出很優(yōu)秀的軟件產(chǎn)品，同時(shí)也會(huì)令客戶滿意。若處理不好，則會(huì)導(dǎo)致誤解、挫折、障礙以及潛在的質(zhì)量和業(yè)務(wù)價(jià)值上的威脅。因此可見(jiàn)需求分析奠定了軟件工程和項(xiàng)目管理的基礎(chǔ)。 -撥開(kāi)需求分析的迷霧 -像這樣的對(duì)話經(jīng)常出現(xiàn)在軟件開(kāi)發(fā)的過(guò)程中?？蛻繇?xiàng)目經(jīng)理的需求對(duì)分析人員來(lái)講，像“霧里看花”般模糊并令開(kāi)發(fā)者感到困惑。那么，我們就撥開(kāi)霧影，分析一下需求的具體內(nèi)容： -業(yè)務(wù)需求反映了組織機(jī)構(gòu)或客戶對(duì)系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，通常在項(xiàng)目定

8、義與范圍文檔中予以說(shuō)明。 -用戶需求描述了用戶使用產(chǎn)品必須要完成的任務(wù)，這在使用實(shí)例或方案腳本中予以說(shuō)明。 -功能需求定義了開(kāi)發(fā)人員必須實(shí)現(xiàn)的軟件功能，使用戶利用系統(tǒng)能夠完成他們的任務(wù)，從而滿足了業(yè)務(wù)需求。 -非功能性的需求描述了系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等，它包括產(chǎn)品必須遵從的標(biāo)準(zhǔn)、規(guī)范和約束，操作界面的具體細(xì)節(jié)和構(gòu)造上的限制。 -需求分析報(bào)告報(bào)告所說(shuō)明的功能需求充分描述了軟件系統(tǒng)所應(yīng)具有的外部行為?！靶枨蠓治鰣?bào)告”在開(kāi)發(fā)、測(cè)試、質(zhì)量保證、項(xiàng)目管理以及相關(guān)項(xiàng)目功能中起著重要作用。 -前面提到的客戶項(xiàng)目經(jīng)理通常闡明產(chǎn)品的高層次概念和主要業(yè)務(wù)內(nèi)容，為后繼工作建立了一個(gè)指導(dǎo)性的框架。其他任何

9、說(shuō)明都應(yīng)遵循“業(yè)務(wù)需求”的規(guī)定，然而“業(yè)務(wù)需求”并不能為開(kāi)發(fā)人員提供開(kāi)發(fā)所需的許多細(xì)節(jié)說(shuō)明。 -下一層次需求用戶需求，必須從使用產(chǎn)品的用戶處收集。因此，這些用戶構(gòu)成了另一種軟件客戶，他們清楚要使用該產(chǎn)品完成什么任務(wù)和一些非功能性的特性需求。例如：程序的易用性、健壯性和可靠性，而這些特性將會(huì)使用戶很好地接受具有該特點(diǎn)的軟件產(chǎn)品。 -經(jīng)理層有時(shí)試圖代替實(shí)際用戶說(shuō)話，但通常他們無(wú)法準(zhǔn)確說(shuō)明“用戶需求”。用戶需求來(lái)自產(chǎn)品的真正使用者，必須讓實(shí)際用戶參與到收集需求的過(guò)程中。如果不這樣做，產(chǎn)品很可能會(huì)因缺乏足夠的信息而遺留不少隱患。 -在實(shí)際需求分析過(guò)程中，以上兩種客戶可能都覺(jué)得沒(méi)有時(shí)間與需求分析人員討論

10、，有時(shí)客戶還希望分析人員無(wú)須討論和編寫(xiě)需求說(shuō)明就能說(shuō)出用戶的需求。除非遇到的需求極為簡(jiǎn)單；否則不能這樣做。如果您的組織希望軟件成功，那么必須要花上數(shù)天時(shí)間來(lái)消除需求中模糊不清的地方和一些使開(kāi)發(fā)者感到困惑的方面。 -優(yōu)秀的軟件產(chǎn)品建立在優(yōu)秀的需求基礎(chǔ)之上，而優(yōu)秀的需求源于客戶與開(kāi)發(fā)人員之間有效的交流和合作。只有雙方參與者都明白自己需要什么、成功的合作需要什么時(shí)，才能建立起一種良好的合作關(guān)系。 -由于項(xiàng)目的壓力與日俱增，所有項(xiàng)目風(fēng)險(xiǎn)承擔(dān)者有著一個(gè)共同目標(biāo)，那就是大家都想開(kāi)發(fā)出一個(gè)既能實(shí)現(xiàn)商業(yè)價(jià)值又能滿足用戶要求，還能使開(kāi)發(fā)者感到滿足的優(yōu)秀軟件產(chǎn)品。 -客戶的需求觀 -客戶與開(kāi)發(fā)人員交流需要好的方法

11、。下面建議20條法則，客戶和開(kāi)發(fā)人員可以通過(guò)評(píng)審以下內(nèi)容并達(dá)成共識(shí)。如果遇到分歧，將通過(guò)協(xié)商達(dá)成對(duì)各自義務(wù)的相互理解，以便減少以后的磨擦（如一方要求而另一方不愿意或不能夠滿足要求）。 -1、 分析人員要使用符合客戶語(yǔ)言習(xí)慣的表達(dá) -需求討論集中于業(yè)務(wù)需求和任務(wù)，因此要使用術(shù)語(yǔ)?？蛻魬?yīng)將有關(guān)術(shù)語(yǔ)（例如：采價(jià)、印花商品等采購(gòu)術(shù)語(yǔ)）教給分析人員，而客戶不一定要懂得計(jì)算機(jī)行業(yè)的術(shù)語(yǔ)。 -2、分析人員要了解客戶的業(yè)務(wù)及目標(biāo) -只有分析人員更好地了解客戶的業(yè)務(wù)，才能使產(chǎn)品更好地滿足需要。這將有助于開(kāi)發(fā)人員設(shè)計(jì)出真正滿足客戶需要并達(dá)到期望的優(yōu)秀軟件。為幫助開(kāi)發(fā)和分析人員，客戶可以考慮邀請(qǐng)他們觀察自己的工作流

12、程。如果是切換新系統(tǒng)，那么開(kāi)發(fā)和分析人員應(yīng)使用一下目前的舊系統(tǒng)，有利于他們明白目前系統(tǒng)是怎樣工作的，其流程情況以及可供改進(jìn)之處。s -3、 分析人員必須編寫(xiě)軟件需求報(bào)告 -分析人員應(yīng)將從客戶那里獲得的所有信息進(jìn)行整理，以區(qū)分業(yè)務(wù)需求及規(guī)范、功能需求、質(zhì)量目標(biāo)、解決方法和其他信息。通過(guò)這些分析，客戶就能得到一份“需求分析報(bào)告”，此份報(bào)告使開(kāi)發(fā)人員和客戶之間針對(duì)要開(kāi)發(fā)的產(chǎn)品內(nèi)容達(dá)成協(xié)議。報(bào)告應(yīng)以一種客戶認(rèn)為易于翻閱和理解的方式組織編寫(xiě)?？蛻粢u(píng)審此報(bào)告，以確保報(bào)告內(nèi)容準(zhǔn)確完整地表達(dá)其需求。一份高質(zhì)量的“需求分析報(bào)告”有助于開(kāi)發(fā)人員開(kāi)發(fā)出真正需要的產(chǎn)品。 -4、 要求得到需求工作結(jié)果的解釋說(shuō)明 -分

13、析人員可能采用了多種圖表作為文字性“需求分析報(bào)告”的補(bǔ)充說(shuō)明，因?yàn)楣ぷ鲌D表能很清晰地描述出系統(tǒng)行為的某些方面，所以報(bào)告中各種圖表有著極高的價(jià)值；雖然它們不太難于理解，但是客戶可能對(duì)此并不熟悉，因此客戶可以要求分析人員解釋說(shuō)明每個(gè)圖表的作用、符號(hào)的意義和需求開(kāi)發(fā)工作的結(jié)果，以及怎樣檢查圖表有無(wú)錯(cuò)誤及不一致等。 -5、 開(kāi)發(fā)人員要尊重客戶的意見(jiàn) -如果用戶與開(kāi)發(fā)人員之間不能相互理解，那關(guān)于需求的討論將會(huì)有障礙。共同合作能使大家“兼聽(tīng)則明”。參與需求開(kāi)發(fā)過(guò)程的客戶有權(quán)要求開(kāi)發(fā)人員尊重他們并珍惜他們?yōu)轫?xiàng)目成功所付出的時(shí)間，同樣，客戶也應(yīng)對(duì)開(kāi)發(fā)人員為項(xiàng)目成功這一共同目標(biāo)所做出的努力表示尊重。 -6、 開(kāi)

14、發(fā)人員要對(duì)需求及產(chǎn)品實(shí)施提出建議和解決方案 -通?？蛻羲f(shuō)的“需求”已經(jīng)是一種實(shí)際可行的實(shí)施方案，分析人員應(yīng)盡力從這些解決方法中了解真正的業(yè)務(wù)需求，同時(shí)還應(yīng)找出已有系統(tǒng)與當(dāng)前業(yè)務(wù)不符之處，以確保產(chǎn)品不會(huì)無(wú)效或低效；在徹底弄清業(yè)務(wù)領(lǐng)域內(nèi)的事情后，分析人員就能提出相當(dāng)好的改進(jìn)方法，有經(jīng)驗(yàn)且有創(chuàng)造力的分析人員還能提出增加一些用戶沒(méi)有發(fā)現(xiàn)的很有價(jià)值的系統(tǒng)特性。 -7、 描述產(chǎn)品使用特性 -客戶可以要求分析人員在實(shí)現(xiàn)功能需求的同時(shí)還注意軟件的易用性，因?yàn)檫@些易用特性或質(zhì)量屬性能使客戶更準(zhǔn)確、高效地完成任務(wù)。例如：客戶有時(shí)要求產(chǎn)品要“界面友好”或“健壯”或“高效率”，但對(duì)于開(kāi)發(fā)人員來(lái)講，太主觀了并無(wú)實(shí)用價(jià)

15、值。正確的做法是，分析人員通過(guò)詢問(wèn)和調(diào)查了解客戶所要的“友好、健壯、高效所包含的具體特性，具體分析哪些特性對(duì)哪些特性有負(fù)面影響，在性能代價(jià)和所提出解決方案的預(yù)期利益之間做出權(quán)衡，以確保做出合理的取舍。 -8、 允許重用已有的軟件組件 -需求通常有一定靈活性，分析人員可能發(fā)現(xiàn)已有的某個(gè)軟件組件與客戶描述的需求很相符，在這種情況下，分析人員應(yīng)提供一些修改需求的選擇以便開(kāi)發(fā)人員能夠降低新系統(tǒng)的開(kāi)發(fā)成本和節(jié)省時(shí)間，而不必嚴(yán)格按原有的需求說(shuō)明開(kāi)發(fā)。所以說(shuō)，如果想在產(chǎn)品中使用一些已有的商業(yè)常用組件，而它們并不完全適合您所需的特性，這時(shí)一定程度上的需求靈活性就顯得極為重要了。 -9、 要求對(duì)變更的代價(jià)提供真

16、實(shí)可靠的評(píng)估 -有時(shí)，人們面臨更好、也更昂貴的方案時(shí)，會(huì)做出不同的選擇。而這時(shí)，對(duì)需求變更的影響進(jìn)行評(píng)估從而對(duì)業(yè)務(wù)決策提供幫助，是十分必要的。所以，客戶有權(quán)利要求開(kāi)發(fā)人員通過(guò)分析給出一個(gè)真實(shí)可信的評(píng)估，包括影響、成本和得失等。開(kāi)發(fā)人員不能由于不想實(shí)施變更而隨意夸大評(píng)估成本。 -10、 獲得滿足客戶功能和質(zhì)量要求的系統(tǒng) -每個(gè)人都希望項(xiàng)目成功，但這不僅要求客戶要清晰地告知開(kāi)發(fā)人員關(guān)于系統(tǒng)“做什么”所需的所有信息，而且還要求開(kāi)發(fā)人員能通過(guò)交流了解清楚取舍與限制，一定要明確說(shuō)明您的假設(shè)和潛在的期望，否則，開(kāi)發(fā)人員開(kāi)發(fā)出的產(chǎn)品很可能無(wú)法讓您滿意。-11、 給分析人員講解您的業(yè)務(wù) -分析人員要依靠客戶講

17、解業(yè)務(wù)概念及術(shù)語(yǔ)，但客戶不能指望分析人員會(huì)成為該領(lǐng)域的專家，而只能讓他們明白您的問(wèn)題和目標(biāo)；不要期望分析人員能把握客戶業(yè)務(wù)的細(xì)微潛在之處，他們可能不知道那些對(duì)于客戶來(lái)說(shuō)理所當(dāng)然的“常識(shí)”。 -12、 抽出時(shí)間清楚地說(shuō)明并完善需求 -客戶很忙，但無(wú)論如何客戶有必要抽出時(shí)間參與“頭腦高峰會(huì)議”的討論，接受采訪或其他獲取需求的活動(dòng)。有些分析人員可能先明白了您的觀點(diǎn)，而過(guò)后發(fā)現(xiàn)還需要您的講解，這時(shí)請(qǐng)耐心對(duì)待一些需求和需求的精化工作過(guò)程中的反復(fù)，因?yàn)樗侨藗兘涣髦泻茏匀坏默F(xiàn)象，何況這對(duì)軟件產(chǎn)品的成功極為重要。 -13、 準(zhǔn)確而詳細(xì)地說(shuō)明需求 -編寫(xiě)一份清晰、準(zhǔn)確的需求文檔是很困難的。由于處理細(xì)節(jié)問(wèn)題不但

18、煩人而且耗時(shí)，因此很容易留下模糊不清的需求。但是在開(kāi)發(fā)過(guò)程中，必須解決這種模糊性和不準(zhǔn)確性，而客戶恰恰是為解決這些問(wèn)題作出決定的最佳人選，否則，就只好靠開(kāi)發(fā)人員去正確猜測(cè)了。 -在需求分析中暫時(shí)加上“待定”標(biāo)志是個(gè)方法。用該標(biāo)志可指明哪些是需要進(jìn)一步討論、分析或增加信息的地方，有時(shí)也可能因?yàn)槟硞€(gè)特殊需求難以解決或沒(méi)有人愿意處理它而標(biāo)注上“待定”?？蛻粢M量將每項(xiàng)需求的內(nèi)容都闡述清楚，以便分析人員能準(zhǔn)確地將它們寫(xiě)進(jìn)“軟件需求報(bào)告”中去。如果客戶一時(shí)不能準(zhǔn)確表達(dá)，通常就要求用原型技術(shù)，通過(guò)原型開(kāi)發(fā)，客戶可以同開(kāi)發(fā)人員一起反復(fù)修改，不斷完善需求定義。 -14、 及時(shí)作出決定 -分析人員會(huì)要求客戶作出

19、一些選擇和決定，這些決定包括來(lái)自多個(gè)用戶提出的處理方法或在質(zhì)量特性沖突和信息準(zhǔn)確度中選擇折衷方案等。有權(quán)作出決定的客戶必須積極地對(duì)待這一切，盡快做處理，做決定，因?yàn)殚_(kāi)發(fā)人員通常只有等客戶做出決定才能行動(dòng)，而這種等待會(huì)延誤項(xiàng)目的進(jìn)展。 -15、 尊重開(kāi)發(fā)人員的需求可行性及成本評(píng)估 -所有的軟件功能都有其成本。客戶所希望的某些產(chǎn)品特性可能在技術(shù)上行不通，或者實(shí)現(xiàn)它要付出極高的代價(jià)，而某些需求試圖達(dá)到在操作環(huán)境中不可能達(dá)到的性能，或試圖得到一些根本得不到的數(shù)據(jù)。開(kāi)發(fā)人員會(huì)對(duì)此作出負(fù)面的評(píng)價(jià)，客戶應(yīng)該尊重他們的意見(jiàn)。 -16、 劃分需求的優(yōu)先級(jí) -絕大多數(shù)項(xiàng)目沒(méi)有足夠的時(shí)間或資源實(shí)現(xiàn)功能性的每個(gè)細(xì)節(jié)。

20、決定哪些特性是必要的，哪些是重要的，是需求開(kāi)發(fā)的主要部分，這只能由客戶負(fù)責(zé)設(shè)定需求優(yōu)先級(jí)，因?yàn)殚_(kāi)發(fā)者不可能按照客戶的觀點(diǎn)決定需求優(yōu)先級(jí)；開(kāi)發(fā)人員將為您確定優(yōu)先級(jí)提供有關(guān)每個(gè)需求的花費(fèi)和風(fēng)險(xiǎn)的信息。 -在時(shí)間和資源限制下，關(guān)于所需特性能否完成或完成多少應(yīng)尊重開(kāi)發(fā)人員的意見(jiàn)。盡管沒(méi)有人愿意看到自己所希望的需求在項(xiàng)目中未被實(shí)現(xiàn)，但畢竟是要面對(duì)現(xiàn)實(shí)，業(yè)務(wù)決策有時(shí)不得不依據(jù)優(yōu)先級(jí)來(lái)縮小項(xiàng)目范圍或延長(zhǎng)工期，或增加資源，或在質(zhì)量上尋找折衷。 -17、 評(píng)審需求文檔和原型 -客戶評(píng)審需求文檔，是給分析人員帶來(lái)反饋信息的一個(gè)機(jī)會(huì)。如果客戶認(rèn)為編寫(xiě)的“需求分析報(bào)告”不夠準(zhǔn)確，就有必要盡早告知分析人員并為改進(jìn)提供建

21、議。 -更好的辦法是先為產(chǎn)品開(kāi)發(fā)一個(gè)原型。這樣客戶就能提供更有價(jià)值的反饋信息給開(kāi)發(fā)人員，使他們更好地理解您的需求；原型并非是一個(gè)實(shí)際應(yīng)用產(chǎn)品，但開(kāi)發(fā)人員能將其轉(zhuǎn)化、擴(kuò)充成功能齊全的系統(tǒng)。 -18、 需求變更要立即聯(lián)系 -不斷的需求變更，會(huì)給在預(yù)定計(jì)劃內(nèi)完成的質(zhì)量產(chǎn)品帶來(lái)嚴(yán)重的不利影響。變更是不可避免的，但在開(kāi)發(fā)周期中，變更越在晚期出現(xiàn)，其影響越大；變更不僅會(huì)導(dǎo)致代價(jià)極高的返工，而且工期將被延誤，特別是在大體結(jié)構(gòu)已完成后又需要增加新特性時(shí)。所以，一旦客戶發(fā)現(xiàn)需要變更需求時(shí)，請(qǐng)立即通知分析人員。 -19、 遵照開(kāi)發(fā)小組處理需求變更的過(guò)程 -為將變更帶來(lái)的負(fù)面影響減少到最低限度，所有參與者必須遵照項(xiàng)

22、目變更控制過(guò)程。這要求不放棄所有提出的變更，對(duì)每項(xiàng)要求的變更進(jìn)行分析、綜合考慮，最后做出合適的決策，以確定應(yīng)將哪些變更引入項(xiàng)目中。 -20、 尊重開(kāi)發(fā)人員采用的需求分析過(guò)程 -軟件開(kāi)發(fā)中最具挑戰(zhàn)性的莫過(guò)于收集需求并確定其正確性，分析人員采用的方法有其合理性。也許客戶認(rèn)為收集需求的過(guò)程不太劃算，但請(qǐng)相信花在需求開(kāi)發(fā)上的時(shí)間是非常有價(jià)值的；如果您理解并支持分析人員為收集、編寫(xiě)需求文檔和確保其質(zhì)量所采用的技術(shù)，那么整個(gè)過(guò)程將會(huì)更為順利。 -“需求確認(rèn)”意味著什么 -在“需求分析報(bào)告”上簽字確認(rèn)，通常被認(rèn)為是客戶同意需求分析的標(biāo)志行為，然而實(shí)際操作中，客戶往往把“簽字”看作是毫無(wú)意義的事情?！八麄円?/p>

23、在需求文檔的最后一行下面簽名，于是我就簽了，否則這些開(kāi)發(fā)人員不開(kāi)始編碼?！?-這種態(tài)度將帶來(lái)麻煩，譬如客戶想更改需求或?qū)Ξa(chǎn)品不滿時(shí)就會(huì)說(shuō)：“不錯(cuò)，我是在需求分析報(bào)告上簽了字，但我并沒(méi)有時(shí)間去讀完所有的內(nèi)容，我是相信你們的，是你們非讓我簽字的?！?-同樣問(wèn)題也會(huì)發(fā)生在僅把“簽字確認(rèn)”看作是完成任務(wù)的分析人員身上，一旦有需求變更出現(xiàn)，他便指著“需求分析報(bào)告”說(shuō)：“您已經(jīng)在需求上簽字了，所以這些就是我們所開(kāi)發(fā)的，如果您想要?jiǎng)e的什么，您應(yīng)早些告訴我們。” -這兩種態(tài)度都是不對(duì)的。因?yàn)椴豢赡茉陧?xiàng)目的早期就了解所有的需求，而且毫無(wú)疑問(wèn)地需求將會(huì)出現(xiàn)變更，在“需求分析報(bào)告”上簽字確認(rèn)是終止需求分析過(guò)程的正確

24、方法，所以我們必須明白簽字意味著什么。 -對(duì)“需求分析報(bào)告”的簽名是建立在一個(gè)需求協(xié)議的基線上，因此我們對(duì)簽名應(yīng)該這樣理解：“我同意這份需求文檔表述了我們對(duì)項(xiàng)目軟件需求的了解，進(jìn)一步的變更可在此基線上通過(guò)項(xiàng)目定義的變更過(guò)程來(lái)進(jìn)行。我知道變更可能會(huì)使我們重新協(xié)商成本、資源和項(xiàng)目階段任務(wù)等事宜?！睂?duì)需求分析達(dá)成一定的共識(shí)會(huì)使雙方易于忍受將來(lái)的摩擦，這些摩擦來(lái)源于項(xiàng)目的改進(jìn)和需求的誤差或市場(chǎng)和業(yè)務(wù)的新要求等。 -需求確認(rèn)將迷霧撥散，顯現(xiàn)需求的真面目，給初步的需求開(kāi)發(fā)工作畫(huà)上了雙方都明確的句號(hào)，并有助于形成一個(gè)持續(xù)良好的客戶與開(kāi)發(fā)人員的關(guān)系，為項(xiàng)目的成功奠定了堅(jiān)實(shí)的基礎(chǔ)。描述信息結(jié)構(gòu)和交互設(shè)計(jì)的圖示詞

25、匯表 版本 1.1a (2001年9月17日) Jesse James Garrett (contact) 翻譯于 2002年2月 Arky Tan 英語(yǔ)原版 目錄：1. 摘要 2. 版本信息 3. 先決條件 4. 設(shè)計(jì)概念 5. 基本元素：頁(yè)面、文件和相關(guān)文件組 6. 創(chuàng)建關(guān)系：連接和箭頭 7. 同時(shí)發(fā)生：并發(fā)事件組 8. 分解：鏈接點(diǎn) 9. 元素集合：區(qū)域和區(qū)域疊代 10. 可再用模塊：流程和流程引用 11. 基本的條件元素 12. 作出選擇：決策點(diǎn) 13. 嘗試：條件連接和條件箭頭 14. 單項(xiàng)選擇：條件分支 15. 多項(xiàng)選擇：條件選擇器 16. 一個(gè)決策，多條

26、路徑：群組 17. 可能會(huì)涉及的限制：條件區(qū)域 18. 備注 19. 可以下載的圖形庫(kù) 摘要圖表是網(wǎng)絡(luò)應(yīng)用開(kāi)發(fā)團(tuán)隊(duì)（Web development teams）在溝通信息架構(gòu)和交互設(shè)計(jì)方面最基本的工具。本文所討論的是使用圖表來(lái)描述系統(tǒng)時(shí)所要考慮的事宜、信息架構(gòu)和用戶交互設(shè)計(jì)時(shí)使用這些基本元素的要點(diǎn)，并且介紹這些元素的使用方法。 版本信息1.1aSC （2002年2月6日） 簡(jiǎn)體中文譯本 1.1a （2001年9月17日） Macromedia FreeHand 新圖形庫(kù) 添加PDF的圖形模板 1.1 （2001年1月31日） 增加文件組元素 增加條件選擇器元素 修改箭頭元素，增加多箭頭說(shuō)明路徑

27、方向 修改群組元素，說(shuō)明其可作為條件分支或條件選擇器的下游元素 修改條件分支元素，增加其可能出現(xiàn)空結(jié)構(gòu)的情況 修改圖形庫(kù)中的一些元素 增加Adobe InDesign 的圖形庫(kù) 1.0 （2000年10月17日） 首次發(fā)布 先決條件 圖示詞匯表是一套用于描繪某些事物（通?？赡苁且粋€(gè)系統(tǒng)、結(jié)構(gòu)或過(guò)程）的符號(hào)庫(kù)。本詞匯表可能在信息結(jié)構(gòu)和交互設(shè)計(jì)方面，在一個(gè)宏觀程度上描述網(wǎng)站中用戶體驗(yàn)的結(jié)構(gòu)抑或過(guò)程。 本文中的描述、圖表適用于以下五點(diǎn)主要角色： 項(xiàng)目主持人和項(xiàng)目經(jīng)理 通過(guò)本文所描述的工具能夠?qū)?xiàng)目的范圍和形態(tài)有所了解。 內(nèi)容制作人 以獲得系統(tǒng)中的內(nèi)容需求。 視覺(jué)傳達(dá)和界面設(shè)計(jì)師 使用本工具能夠計(jì)算出

28、設(shè)計(jì)工作量，并且初步了解系統(tǒng)的導(dǎo)航結(jié)構(gòu)和界面設(shè)計(jì)的需求。 技術(shù)專家 以了解系統(tǒng)在技術(shù)方面的需求 信息結(jié)構(gòu)和交互設(shè)計(jì)師 通過(guò)本工具能夠?qū)ο到y(tǒng)中的每個(gè)具體界面設(shè)計(jì)詳細(xì)的導(dǎo)航和界面設(shè)計(jì)要求。 除項(xiàng)目主持人以外，其他四種角色的人員在進(jìn)行自己的工作中多需要獲得大量的詳細(xì)信息，但問(wèn)題在于每種角色所需要了解的信息都各不相同，而且差異很大。并且各個(gè)角色所需要的信息的數(shù)量與該角色的需求并不成正比。因此對(duì)于每個(gè)對(duì)象確實(shí)有效的功用是限定本圖表的詳細(xì)程度。從而能夠使得采用本方法所描述的系統(tǒng)結(jié)構(gòu)能夠成功項(xiàng)目開(kāi)發(fā)中每個(gè)角色所涉及的更詳細(xì)的描述的基石。 此外，在信息架構(gòu)和交互設(shè)計(jì)中對(duì)于本圖示詞匯表還有其他幾個(gè)重要的要求，包

29、括： 易于書(shū)寫(xiě) 圖表要足夠的簡(jiǎn)單以便于用戶能夠快速手繪草圖，同時(shí)每個(gè)圖表元素之間需要有明確的區(qū)別，這樣即便制圖破損污染了也不會(huì)影響圖表被清晰識(shí)別。 工具無(wú)關(guān)性 圖示詞匯表需要設(shè)計(jì)成為不需要特殊的軟件工具來(lái)繪制圖表。而雖然使用圖示詞匯表不需要用戶使用特殊的軟件工具但需要能夠在各種用戶的常用軟件中能夠方便繪制。 精練而系統(tǒng)完整 由于使用本方法的每位用戶未必都很深入了解本方法（甚至未必有很大的興趣），因此本圖示詞匯表應(yīng)當(dāng)不要求客戶需要那樣專業(yè)的知識(shí)和興趣。所以整套元素必須盡可能的精練，嚴(yán)格地將概念和符號(hào)一一對(duì)應(yīng)起來(lái)，以使圖示詞匯表能夠快速地被用戶學(xué)會(huì)和使用。無(wú)論所要描述的系統(tǒng)如何負(fù)責(zé)，每個(gè)表達(dá)符號(hào)作

30、為基本元素都必須具有自己簡(jiǎn)單明確的含義。 設(shè)計(jì)概念信息結(jié)構(gòu)和交互設(shè)計(jì)好比是硬幣的兩面（在本文中所定義的條款請(qǐng)參見(jiàn)用戶體驗(yàn)的原理（The Elements of User Experience） 。目前大多數(shù)網(wǎng)站和基于Web的應(yīng)用系統(tǒng)都會(huì)涉及這兩方面，而對(duì)任何一面來(lái)說(shuō)，流程圖表的目標(biāo)是顯然和另一方面所不同的。在這兩方面，流程圖表都從宏觀結(jié)構(gòu)上以一個(gè)適當(dāng)?shù)脑敿?xì)程度，讓團(tuán)隊(duì)成員能夠了解項(xiàng)目的大致描述。而系統(tǒng)構(gòu)架師的職責(zé)就是決定流程圖表 所說(shuō)明項(xiàng)目目的適當(dāng)詳細(xì)程度。而詳細(xì)到頁(yè)面的內(nèi)容，或微觀結(jié)構(gòu)將在以后的開(kāi)發(fā)過(guò)程的文檔中體現(xiàn)出來(lái)。 在描述信息結(jié)構(gòu)時(shí)，圖表應(yīng)當(dāng)著重于項(xiàng)目概念的結(jié)構(gòu)和內(nèi)容的組織。值得主意的

31、是項(xiàng)目概念的結(jié)構(gòu)不同于導(dǎo)航性的結(jié)構(gòu)，設(shè)計(jì)信息結(jié)構(gòu)的流程圖表的目的不是為了說(shuō)明詳細(xì)的導(dǎo)航性結(jié)構(gòu)，因而最好 使用其他相關(guān)的文檔來(lái)描述導(dǎo)航性結(jié)構(gòu)的詳細(xì)信息。 在描述交互設(shè)計(jì)時(shí)，需要注重于描述用戶在系統(tǒng)定義好的任務(wù)和任務(wù)的每個(gè)過(guò)程中的行動(dòng)流程，因此導(dǎo)航條、界面元素等詳細(xì)信息將不會(huì)出現(xiàn)在流程圖表中如果您發(fā)現(xiàn)自己在繪制按鈕、文字域等元素的時(shí)候，可能您已經(jīng)涉足過(guò)分細(xì)節(jié)的內(nèi)容了。 因此本圖示詞匯表同時(shí)包含信息構(gòu)架和交互設(shè)計(jì)的簡(jiǎn)單的概念模型為基礎(chǔ)，用來(lái)描述： 系統(tǒng)提供給用戶的可行路徑； 用戶在所有路徑中的行為； 用戶行為在系統(tǒng)產(chǎn)生的結(jié)果； 基本元素: 頁(yè)面, 文件和相關(guān)文件組網(wǎng)絡(luò)中用戶交互的最基本單元是頁(yè)面，因

32、此我們采用一個(gè)矩形符號(hào)來(lái)表示頁(yè)面。值得注意的是，在此我們所提到的頁(yè)面是一個(gè)表達(dá)單元，而不僅是網(wǎng)絡(luò)交互過(guò)程中的一個(gè) 實(shí)際元素。因此流程圖中的一個(gè)頁(yè)面符號(hào)可能代表多個(gè)HTML文件（比如在一個(gè)采用幀的頁(yè)面中集合了多個(gè)HTML文件）或多段程序代碼文件（比如在服務(wù)器端調(diào)用的嵌入文件或數(shù)據(jù)庫(kù)存儲(chǔ)執(zhí)行過(guò)程等）。 除頁(yè)面之外，還有不具備網(wǎng)站導(dǎo)航屬性的文件。通常文件都是給用戶用于瀏覽器以外的操作（比如聲音和圖象文件、類似與PDF的獨(dú)立格式的文檔或可執(zhí)行文件等）。對(duì)于文件，我們采用一個(gè)卷角的文檔圖標(biāo)來(lái)表示。 圖1a： 左側(cè) “頁(yè)面”和“文件” 圖1b: 右側(cè) “頁(yè)面組”和“文件組” 我們采用頁(yè)面組的符號(hào)來(lái)表示在宏

33、觀結(jié)構(gòu)上導(dǎo)航屬性一致的一組功能類似的頁(yè)面。同樣的，文件組用來(lái)表示在網(wǎng)站的導(dǎo)航結(jié)構(gòu)中被單一入口指向的一系列文件（ 比如一個(gè)可供下載的游戲集合或一個(gè)PDF說(shuō)明手冊(cè)庫(kù)等等。）我們?cè)陧?yè)面和文件上加以標(biāo)注用來(lái)鑒別他們，這些標(biāo)注不必和實(shí)際名稱（比如HTML中的“”標(biāo)簽）或文件名相互關(guān)聯(lián)，但每個(gè)名稱必須是在整個(gè)信息結(jié)構(gòu)中唯一的。采用唯一的數(shù)字標(biāo)識(shí)和類型名稱是在整個(gè)信息結(jié)構(gòu)中跟蹤頁(yè)面和文件的一個(gè)好方法。 創(chuàng)建相互關(guān)系：連接和箭頭對(duì)于元素之間的關(guān)系，我們采用連接來(lái)描述。這種概念上關(guān)系將不可避免地別描述為導(dǎo)航關(guān)系，但是不是所有的導(dǎo)航關(guān)系都會(huì)出現(xiàn)在信息框架圖表中。 在描述信息結(jié)構(gòu)時(shí)，頁(yè)面之間的層基組織關(guān)系通常被描繪

34、為一個(gè)樹(shù)形的結(jié)構(gòu)，但這種方式?jīng)Q不是唯一的而恰好是推薦使用的。 圖 2a: 左 一個(gè)簡(jiǎn)單的樹(shù)形結(jié)構(gòu) 圖 2b: 右 與2a同樣的結(jié)構(gòu)，但是表述方法不同。 當(dāng)使用流程圖表來(lái)描述交互作用時(shí)，每個(gè)連接都需要具有方向以表述用戶是如何在系統(tǒng)的每個(gè)任務(wù)中移動(dòng)，因此將連接改成箭頭將有助于說(shuō)明。對(duì)于移動(dòng)的過(guò)程，我們采用下游和上游方向條件來(lái)描述元素的相對(duì)位置關(guān)系。值得注意的是這些箭頭不似那些用來(lái)單行道的箭頭，而更象超級(jí)市場(chǎng)里指示食品部的那種箭頭。因?yàn)橹甘炯^的目的不是禁止用戶向別處同行，而是僅僅說(shuō)明用戶想要行動(dòng)的方向。 可能出于某些原因，我們可能要禁止用戶向上游移動(dòng)（比如在進(jìn)行象刪除數(shù)據(jù)庫(kù)記錄之類不可撤銷的操作的

35、時(shí)候），采用一個(gè)在箭頭的反向終點(diǎn)加一個(gè)橫條（一條相垂直的短線）來(lái)描述。 在某些情況下，我們可能需要在上游附近加一個(gè)箭頭以在更復(fù)雜些的結(jié)構(gòu)中說(shuō)明流的方向。（一個(gè)實(shí)用提示：不少制圖程序不允許用戶將箭頭畫(huà)成這樣。為了解決這個(gè)問(wèn)題在圖形庫(kù)中已經(jīng)包含了一個(gè)名為“gluedot”的元素。這是一個(gè)隱藏的單個(gè)錨點(diǎn)元素，使用這個(gè)元素可以將箭頭鏈接在一起。） 圖 3a: 左上 描述任務(wù)過(guò)程中用戶向下游移動(dòng)的箭頭 圖 3b: 左下 橫條說(shuō)明向上游的移動(dòng)是被禁止的 圖 3c: 右 表明方向的多個(gè)箭頭 連接和箭頭同樣也可以加上標(biāo)注，但是最好只有在用戶行為需要被說(shuō)明時(shí)才使用標(biāo)注，否則冗長(zhǎng)和笨拙的標(biāo)注會(huì)使整個(gè)流程框架變得混

36、亂。但必須加以很長(zhǎng)的說(shuō)明時(shí)，我們可以采用腳注或附錄的方式。 在本文給出的示例中，腳注和附錄的參考說(shuō)明可以使用圓括號(hào)中數(shù)字與字母結(jié)合的方法來(lái)說(shuō)明。數(shù)字用于說(shuō)明當(dāng)前注釋在圖表中的出現(xiàn)的頁(yè)面，字母用于說(shuō)明是該頁(yè)中的第幾項(xiàng)。比如在流程圖表的第三頁(yè)中的第一個(gè)的注解可以表示為：(3a)，第二個(gè)可以表示為：(3b)，依此類推。 圖 4a: 左 一個(gè)失敗的標(biāo)注 圖 4b: 中 一個(gè)有用的標(biāo)注 圖 4c: 右 一個(gè)腳注或附錄的標(biāo)注 同時(shí)發(fā)生: 并發(fā)事件組并發(fā)事件組（表示為一個(gè)半圓形符號(hào)）是用于描述一個(gè)同時(shí)產(chǎn)生多個(gè)結(jié)構(gòu)得用戶行為（比如出現(xiàn)一個(gè)彈出窗口得同時(shí)主窗口下載頁(yè)面，或者顯示一個(gè)頁(yè)面的同時(shí)開(kāi)始文件下載。）和箭

37、頭一樣，并發(fā)事件組等元素都是具有方向性的。出于上游的元素鏈接到并發(fā)事件組符號(hào)的曲線邊，而處于下游的元素鏈接到并發(fā)事件組的平邊上。 圖 5: 并發(fā)事件組符號(hào)的使用 分解：鏈接點(diǎn)描述信息結(jié)構(gòu)的圖表通常希望能夠有足夠大幅面的圖紙用來(lái)繪圖。但是即便采用繪圖機(jī)等大型的輸出設(shè)備，一些結(jié)構(gòu)也可能僅因?yàn)樘珡?fù)雜而無(wú)法使用單一的圖表中全部囊括。因此為了鏈接圖表頁(yè)面的間隙，我們采用鏈接點(diǎn)（表示為方括號(hào)）使用戶易于將圖表拆分成容易消化的模塊。 單個(gè)鏈接點(diǎn)可以根據(jù)需要被鏈接至一個(gè)和多個(gè)資源圖表或目的圖表。同時(shí)方括號(hào)的方向（垂直或水平）并沒(méi)有特別的含義，至于采用什么方向的方括號(hào)完全取決于設(shè)計(jì)師的審美。 圖 6a: 左 一

38、個(gè)“鏈接至”的鏈接點(diǎn)將讀者引向下一個(gè)圖表 圖 6b: 右 一個(gè)“鏈接自”的鏈接符號(hào)說(shuō)明表6a是從何處離開(kāi)本圖表的。 元素集合：區(qū)域和區(qū)域疊代區(qū)域元素（表示為圓角矩形）用以表示一組共享一個(gè)或多個(gè)基本屬性的頁(yè)面的集合（比如同在一個(gè)彈出窗口中顯示的頁(yè)面或者具有一些獨(dú)特設(shè)計(jì)規(guī)定的系列頁(yè)面等）。在區(qū)域元素上加上標(biāo)注以說(shuō)明這些屬性，同我們?cè)阪溄悠鞯恼f(shuō)明使用方法類似，如果有很多屬性需要說(shuō)明的話可以使用標(biāo)注連接到其他文檔中的其他注釋。 圖 7: 使用一個(gè)區(qū)域元素來(lái)表達(dá)彈出窗口的示例 不少設(shè)計(jì)師常會(huì)反復(fù)使用相同的基本機(jī)構(gòu)來(lái)描述大量功能相同的信息元素，比如您可能遇到一個(gè)產(chǎn)品目錄，其中每個(gè)產(chǎn)品都有若干的頁(yè)面與之相關(guān)

39、聯(lián)。此時(shí)，您當(dāng)然可以使用為每個(gè)產(chǎn)品繪制一個(gè)信息結(jié)構(gòu)的引例，但是這樣做難道不是很浪費(fèi)時(shí)間嗎？因此遇到類似的情況時(shí)，請(qǐng)使用區(qū)域疊代（表示為一堆圓角矩形）。 圖 8: 使用區(qū)域疊代來(lái)表示產(chǎn)品目錄中重復(fù)的結(jié)構(gòu)。 值得注意的是鏈接器和箭頭實(shí)際上并不是指向區(qū)域元素的，區(qū)域元素僅僅用于封裝一些頁(yè)面。因此使用區(qū)域元素時(shí)需要小心使用區(qū)域元素能夠很方便地表述各種用戶體驗(yàn)中無(wú)法表明地細(xì)節(jié)信息（比如哪些文件是存放在哪臺(tái)服務(wù)器上的），但是同時(shí)不當(dāng)?shù)氖褂靡部赡軙?huì)混淆流程圖表在宏觀結(jié)構(gòu)上的說(shuō)明能力。 可再用模塊：流程和流程引用一些用戶交互功能的設(shè)計(jì)師常常需要在不同的過(guò)程中反復(fù)描述一系列相同的步驟（比如用戶登錄過(guò)程）。通常這

40、些步驟是系統(tǒng)的一個(gè)功能模塊或者一個(gè)需要用戶完成的較大的任務(wù)，就這一點(diǎn)與計(jì)算機(jī)程序設(shè)計(jì)中的子程序非常類似。 這樣一個(gè)可以重復(fù)步驟叫做流程，在圖表中我們使用兩個(gè)元素來(lái)表示流程：第一部分是用于說(shuō)明流程本身結(jié)構(gòu)的流程區(qū)域；另一部分是流程引用，作用類似于一個(gè)占位符，在系統(tǒng)結(jié)構(gòu)中每個(gè)出現(xiàn)被引用的流程的地方作為。這兩個(gè)元素都具有相同的基本形狀一個(gè)去角的矩形（如果你愿意，也可以使用變形的八邊形）。流程區(qū)域需要兩個(gè)特殊的鏈接點(diǎn)：進(jìn)入點(diǎn)和退出點(diǎn)，它們都位于流程區(qū)域之外用于說(shuō)明流程的開(kāi)始處和截止處。 圖 9a: 左 流程引用的使用示例 圖 9b: 右 圖9a中引用的流程區(qū)域 流程引用就其本身而言和鏈接點(diǎn)很類似，它們

41、的作用都是讓設(shè)計(jì)師將圖表分散成不同的模塊。它們的區(qū)別在于流程引用是同時(shí)鏈接在兩個(gè)過(guò)程之中，它具有“鏈接自”和“鏈接至”的步驟，而一個(gè)鏈接點(diǎn)僅能具備一個(gè)步驟。因此如果您需要使用模塊但并不同時(shí)具備來(lái)源和去向那么就不必使用流程元素。 基本的條件元素伴隨機(jī)構(gòu)分析問(wèn)題的深入，在信息結(jié)構(gòu)和交互設(shè)計(jì)的構(gòu)成中我們往往需要根據(jù)用戶在系統(tǒng)中行動(dòng)而動(dòng)態(tài)地調(diào)整系統(tǒng)的功能結(jié)構(gòu)。一般這種動(dòng)態(tài)調(diào)整都通過(guò)條件邏輯來(lái)實(shí)現(xiàn)，因此在本文的后半部分我們將討論條件邏輯結(jié)構(gòu)的表達(dá)方法。當(dāng)然我們?cè)诖怂撌龅亩际窍到y(tǒng)應(yīng)用中基本模塊的條件元素： 系統(tǒng)將跟蹤以下一個(gè)或多個(gè)屬性，這些屬性可能是： o 用戶，或用戶類型； o 對(duì)話時(shí)間，比如登陸的狀態(tài)； o 被訪問(wèn)的內(nèi)容，比如主題內(nèi)容； o 日期或時(shí)間； 每個(gè)屬性都具有值（“3p.m.”可能意味著一天中的時(shí)間）。 一個(gè)屬性的特殊值所關(guān)聯(lián)的內(nèi)容被成為條件。 條件將由系統(tǒng)來(lái)判斷是否正確。 在靜態(tài)的結(jié)構(gòu)中，每條系統(tǒng)中的行動(dòng)路徑都被呈現(xiàn)給每種情況下的每個(gè)用戶，而且每條路徑都指向相同的結(jié)構(gòu)。在一個(gè)動(dòng)態(tài)結(jié)構(gòu)中，系統(tǒng)根據(jù)對(duì)一個(gè)或多個(gè)條件的判斷來(lái)決定哪條路徑應(yīng)當(dāng)遞送給用戶。為了精簡(jiǎn)結(jié)構(gòu)的流程圖，這些條件在伴隨整個(gè)文檔的注腳或附錄中說(shuō)