軟件工程課件：項(xiàng)目分析與軟件需求分析

項(xiàng)目分析與軟件需求分析2.1軟件項(xiàng)目的問題定義2.2軟件項(xiàng)目可行性分析2.3軟件系統(tǒng)的需求2.4用戶需求獲取2.5軟件需求文檔與規(guī)格說明2.6系統(tǒng)流程圖2.7數(shù)據(jù)流圖2.8實(shí)體-聯(lián)系圖2.9需求分析中使用的其他圖形工具2.10面向數(shù)據(jù)流的建模2.11需求有效性驗(yàn)證2.12實(shí)例分析—教材征訂業(yè)務(wù)分析2.13小結(jié)習(xí)題２

知識點(diǎn)

軟件項(xiàng)目問題定義，可行性分析，系統(tǒng)流程圖，需求分析過程，數(shù)據(jù)流圖，數(shù)據(jù)字典，實(shí)體-聯(lián)系圖，需求分析其他圖形工具，面向數(shù)據(jù)流建模，需求驗(yàn)證。

難點(diǎn)

領(lǐng)域知識，獲取需求與分析建模，需求規(guī)格說明，數(shù)據(jù)流圖，實(shí)體-聯(lián)系圖(E-R圖)，面向數(shù)據(jù)流建模，常用圖形工具的使用方法。

基于工作過程的教學(xué)任務(wù)

通過本章的學(xué)習(xí)，深刻理解可行性分析的必要性，掌握可行性分析的任務(wù)、過程以及可行性分析的主要內(nèi)容；掌握需求分析的任務(wù)，需求獲取的方法，分析建模與需求規(guī)格說明；掌握系統(tǒng)流程圖使用的基本符號，理解分層繪制系統(tǒng)流程圖的畫法及思想；著重掌握針對某一領(lǐng)域知識利用數(shù)據(jù)流圖、數(shù)據(jù)字典、實(shí)體-聯(lián)系圖、數(shù)據(jù)規(guī)范化等手段進(jìn)行數(shù)據(jù)建模，理解分層繪制數(shù)據(jù)流圖的畫法及思想；掌握狀態(tài)轉(zhuǎn)換圖、層次方框圖、Warnier圖、IPO(HIPO)圖及其繪制；掌握驗(yàn)證軟件需求的必要性、方法。

2.1軟件項(xiàng)目的問題定義

軟件項(xiàng)目的問題定義是軟件開發(fā)過程的第一個階段。系統(tǒng)分析人員需要弄清楚用戶“使用計(jì)算機(jī)解決什么問題”，以報(bào)告的形式描述項(xiàng)目的名稱、性質(zhì)、目標(biāo)、意義、規(guī)模等，以獲得對著手開發(fā)軟件項(xiàng)目的高層描述。盡管對軟件項(xiàng)目定義問題十分必要，但是在實(shí)踐中它卻是最容易被忽視的一個步驟。

1．問題定義的內(nèi)容

軟件項(xiàng)目的問題定義包括以下內(nèi)容：

(1)問題的背景、開發(fā)系統(tǒng)的現(xiàn)狀。弄清楚準(zhǔn)備開發(fā)的軟件的使用背景，開發(fā)系統(tǒng)現(xiàn)處于什么狀態(tài)，為什么要開發(fā)它。

(2)開發(fā)的理由和條件、開發(fā)系統(tǒng)的問題要求。

(3)總體要求、問題的性質(zhì)、類型范圍。

(4)要實(shí)現(xiàn)的目標(biāo)、功能規(guī)模、實(shí)現(xiàn)目標(biāo)的方案。

(5)開發(fā)的條件、環(huán)境要求等。

以上內(nèi)容都寫到問題定義報(bào)告(或稱系統(tǒng)定義報(bào)告)中，以供可行性分析階段使用。

2．問題定義的步驟

在問題定義階段，需要系統(tǒng)分析員對用戶的想法進(jìn)行詳細(xì)地研究，明確軟件系統(tǒng)的規(guī)模和基本要求，還需要用戶負(fù)責(zé)人密切配合系統(tǒng)分析員工作，以便圓滿完成問題定義階段報(bào)告。問題定義的步驟如下：

首先，明確系統(tǒng)目標(biāo)規(guī)模和基本要求。系統(tǒng)分析員針對用戶的要求做出詳細(xì)的調(diào)查研究，認(rèn)真聽取用戶對問題的介紹，閱讀與問題相關(guān)的資料，深入現(xiàn)場，調(diào)查開發(fā)系統(tǒng)的背景，了解用戶對開發(fā)的要求。

其次，分析現(xiàn)有系統(tǒng)，設(shè)計(jì)可能方案。

最后，與用戶反復(fù)討論，寫出雙方認(rèn)可的問題定義報(bào)告。系統(tǒng)分析員要與用戶負(fù)責(zé)人反復(fù)討論，以澄清模糊的地方、改正不正確的地方。最終寫出雙方都滿意的問題定義報(bào)告，并確定雙方是否有繼續(xù)合作的意向。

2.2軟件項(xiàng)目可行性分析

可行性分析是軟件開發(fā)過程的第二個階段。系統(tǒng)分析員要對用戶進(jìn)行詳細(xì)的調(diào)查研究，對開發(fā)系統(tǒng)的目標(biāo)和規(guī)模進(jìn)行判斷，對新系統(tǒng)是否能夠帶來經(jīng)濟(jì)效益進(jìn)行判斷。分析軟件的可行性就是用最小的代價(jià)在盡可能短的時間里確定待開發(fā)的軟件系統(tǒng)是否可行。

1．軟件可行性分析的目的和任務(wù)

軟件可行性分析的目的不是解決軟件問題，而是確定軟件問題是否能解，研究當(dāng)前條件下，新系統(tǒng)是否具備可開發(fā)的資源和條件。也就是說，軟件可行性分析的目的是用最小的代價(jià)在盡可能短的時間內(nèi)確定問題是否值得去解決，以及問題是否能夠被解決。在澄清了問題定義之后，分析員首先應(yīng)該導(dǎo)出系統(tǒng)的邏輯模型，然后從系統(tǒng)邏輯模型出發(fā)，探索出若干種可供選擇的主要解法。最后仔細(xì)分析每種解法的可行性。

經(jīng)過可行性分析以后，如果認(rèn)為問題值得去解，則制訂項(xiàng)目開發(fā)計(jì)劃，進(jìn)入實(shí)際開發(fā)過程；否則直接終止項(xiàng)目。

2．軟件可行性分析的內(nèi)容

軟件可行性分析包括技術(shù)可行性、經(jīng)濟(jì)可行性和社會可行性三個方面的內(nèi)容。

1)技術(shù)可行性

技術(shù)可行性分析是指針對待需要解決的問題，分析目前已有的技術(shù)能否實(shí)現(xiàn)，能否解決系統(tǒng)中的技術(shù)難題，所開發(fā)的系統(tǒng)能否達(dá)到所要求的功能和性能，系統(tǒng)對技術(shù)人員的要求，現(xiàn)有的技術(shù)人員能否勝任，開發(fā)所需要的軟件與硬件能否如期得到等?？偟膩碚f，技術(shù)可行性分析主要考慮以下3個方面：

(1)在給定的時間內(nèi)能否實(shí)現(xiàn)系統(tǒng)定義中的功能。

(2)軟件的質(zhì)量如何。用戶如果對軟件的實(shí)時性要求很高，而開發(fā)的新系統(tǒng)運(yùn)行卻很緩慢，即使功能完備也毫無價(jià)值。用戶如果對軟件的正確性和精確度要求很高，新體系一旦出現(xiàn)差錯，用戶利益將損失嚴(yán)重。

(3)軟件的生產(chǎn)率如何。軟件生產(chǎn)率如果低下，會減少利潤，甚至?xí)饾u喪失競爭力。軟件如果質(zhì)量不好，則會導(dǎo)致軟件的后期維護(hù)成本大大提高。

2)經(jīng)濟(jì)可行性

所謂經(jīng)濟(jì)可行性分析，就是分析開發(fā)該項(xiàng)目能否取得合理的經(jīng)濟(jì)效益，主要是分析成本與收益這兩個方面，要做出投資的估算和系統(tǒng)投入運(yùn)行后可能獲得的經(jīng)濟(jì)效益或可節(jié)約的費(fèi)用估算。

(1)成本分析。經(jīng)濟(jì)可行性的一個重要任務(wù)就是要估算軟件開發(fā)的成本，也就是項(xiàng)目的預(yù)算。如果在軟件開發(fā)的初期階段沒有合理地估算成本，常常會導(dǎo)致實(shí)際的軟件成本遠(yuǎn)遠(yuǎn)超過最初的估算，甚至?xí)?dǎo)致項(xiàng)目最終開發(fā)失敗。一般估算考慮以下幾個方面因素：辦公成本、人員成本、資料成本以及其他成本。

在軟件開發(fā)成本中，最主要的成本是人力消耗。目前已經(jīng)有一些常用的估算方法，如代碼行方法、任務(wù)分解方法、自動估計(jì)成本方法等。

①代碼行方法。代碼行方法是比較簡單的定量估算方法，它把開發(fā)的每個軟件功能成本和實(shí)現(xiàn)功能需要用的源代碼行數(shù)聯(lián)系起來。代碼行數(shù)是指所有可執(zhí)行的源代碼行數(shù)，包括命令語句、數(shù)據(jù)定義、數(shù)據(jù)類型聲明、等價(jià)聲明、輸入/輸出格式聲明等。每行代碼的平均成本主要取決于軟件的復(fù)雜程度和人員工資水平，一般可用歷史的經(jīng)驗(yàn)數(shù)據(jù)作參考。根據(jù)每個人月編寫的代碼行數(shù)與該項(xiàng)目估算的總代碼行數(shù)比較，估算出開發(fā)需要的總工作量，再參考開發(fā)人員的平均月工資水平，即可算出整個項(xiàng)目的人工費(fèi)。

②任務(wù)分解方法。任務(wù)分解方法與代碼行方法不同，它是把軟件開發(fā)工程分解為若干個相對獨(dú)立的任務(wù)，再估計(jì)出每個獨(dú)立開發(fā)的任務(wù)成本，最后累加得到軟件開發(fā)工程的總成本。在估算每個任務(wù)的成本時，通常先估計(jì)完成該任務(wù)需要的人力，再乘以每人每月的平均工資，得出每個任務(wù)的成本。

③自動估計(jì)成本方法。采用自動估計(jì)成本的軟件工具可減輕人的勞動，得出的估計(jì)結(jié)果更加客觀。但采用這種方法必須有長期搜集的大量歷史數(shù)據(jù)為基礎(chǔ)，并且需要有良好的數(shù)據(jù)庫系統(tǒng)支持。

(2)收益分析。在估算投入成本后，要對收益進(jìn)行估算，以確定經(jīng)濟(jì)的可行性。收益是指新系統(tǒng)將增加的收入或可節(jié)約的成本(運(yùn)行費(fèi)用)。需要注意的是，成本是現(xiàn)在進(jìn)行的，效益是將來獲得的，不能簡單地比較成本和效益，應(yīng)該考慮貨幣的時間價(jià)值。

通常用利率的形式表示貨幣的時間價(jià)值。假設(shè)年利率為i，現(xiàn)有貨幣P元，則n年后的價(jià)值F可按如下公式計(jì)算：

反之，若n年后的效益為F元，那么現(xiàn)在的價(jià)值P如下：

例如，某系統(tǒng)投入5萬元，每年可節(jié)省的成本為2.5萬元，若軟件的生命周期為5年，則總節(jié)省12.5萬元。但是在進(jìn)行效益分析時，不能簡單地把5萬元與12.5萬元相比較，因?yàn)榍罢呤乾F(xiàn)在投資的錢，后者是若干年以后節(jié)省的錢。假設(shè)年利率為10%，則每年的效益折算應(yīng)如表2-1所示?？偟男б婕s為9.48萬元。

衡量價(jià)值的另一項(xiàng)經(jīng)濟(jì)指標(biāo)是純收入，就是在整個軟件生命周期內(nèi)系統(tǒng)累計(jì)經(jīng)濟(jì)效益(折合成現(xiàn)在值)與投資之差。上述系統(tǒng)的純收入預(yù)計(jì)為

94,769.67–50,000=44,769.67(元)

從經(jīng)濟(jì)可行性角度分析，如果純收入等于零或小于零，那么這個項(xiàng)目是不值得投資的。只有純收入大于零，才能考慮投資。

3)社會可行性

社會可行性主要是指軟件生產(chǎn)需要考慮的社會因素，具體來說是指市場、政策與法律方面的考慮。

(1)在市場方面，考慮軟件產(chǎn)品所面對的市場性質(zhì)是成熟的、未成熟的或即將消亡的。

(2)在政策方面，考慮的是國家宏觀的經(jīng)濟(jì)政策對軟件開發(fā)及銷售的影響。

(3)在法律方面，應(yīng)該考慮軟件的開發(fā)是否會侵犯他人、集體或國家的利益，是否會違反國家的法律并可能由此承擔(dān)相應(yīng)的法律責(zé)任等。例如，某用戶希望開發(fā)一款能攻擊其競爭對手的數(shù)據(jù)庫軟件，這顯然侵犯了他人的利益，因此屬于不可行的開發(fā)項(xiàng)目。

3．軟件可行性分析步驟

可行性分析的一般步驟是：建立系統(tǒng)模型，進(jìn)行項(xiàng)目可行性評估，撰寫可行性分析報(bào)告?？尚行苑治鏊槍Φ氖且粋€尚未創(chuàng)建的新系統(tǒng)，為了使可行性分析具有研究對象，在進(jìn)行可行性評估之前有必要先建立起該系統(tǒng)的工作模型。軟件項(xiàng)目的可行性分析過程及步驟如圖2-1所示。

圖2-1軟件可行性分析步驟

2.3軟件系統(tǒng)的需求

軟件系統(tǒng)的需求分為用戶需求和系統(tǒng)需求兩類。軟件需求階段的任務(wù)就是要將客戶等提出的用戶需求轉(zhuǎn)換為系統(tǒng)需求。

用戶需求是用自然語言加圖的形式給出的，是關(guān)于系統(tǒng)需要提供哪些服務(wù)以及系統(tǒng)操作受到哪些約束的聲明。用戶需求術(shù)語用來表達(dá)高層的概要需求，通常只描述系統(tǒng)的外部行為，而不涉及系統(tǒng)內(nèi)部的特性。

系統(tǒng)需求詳細(xì)地給出系統(tǒng)將要提供的服務(wù)以及系統(tǒng)所受到的約束，對系統(tǒng)的需求文檔的描述應(yīng)該是精確的。它可能成為系統(tǒng)買方和軟件開發(fā)者之間合同的重要內(nèi)容。系統(tǒng)需求常常分為功能需求和非功能需求。

2.3.1功能需求

功能需求包括對系統(tǒng)應(yīng)該提供的服務(wù)，如何對特殊輸入做出反應(yīng)，以及系統(tǒng)在特定條件下的行為的描述。有時還需要明確聲明系統(tǒng)不應(yīng)該做什么。

功能需求描述了系統(tǒng)所提供的功能和服務(wù)。它取決于開發(fā)的軟件類型、軟件潛在的用戶，以及機(jī)構(gòu)在寫需求時所采用的一般方法。

如果是用戶需求，就要用被系統(tǒng)用戶理解的一種抽象方法來描述功能需求。功能需求有時還需要詳細(xì)描述系統(tǒng)的功能、輸入/輸出、異常等。

例如，一個高校的圖書管理系統(tǒng)，除了提供一般的圖書管理功能外，還能夠?yàn)閷W(xué)生和教工從其他圖書館借閱圖書和文獻(xiàn)資料提供服務(wù)。

基本數(shù)據(jù)維護(hù)功能。提供使用者錄用、修改并維護(hù)基本數(shù)據(jù)的途徑?；緮?shù)據(jù)包括讀者的信息及圖書資料的相關(guān)信息，可以對這些信息進(jìn)行修改、更新；

基本業(yè)務(wù)功能。提供讀者借、還書籍的登記管理功能，隨時根據(jù)讀者借、還書籍的情況更新數(shù)據(jù)庫系統(tǒng)，如果書籍己經(jīng)借出，可以進(jìn)行預(yù)留操作，以及書籍的編目、入庫、更新等操作；

數(shù)據(jù)庫管理功能。對所有圖書信息及讀者信息進(jìn)行統(tǒng)一管理維護(hù)，對書籍的借、還進(jìn)行詳細(xì)的登記，以便協(xié)調(diào)整個圖書館的運(yùn)作；

信息查詢功能。提供對各類信息的查詢功能，如對本圖書館的用戶借書信息、還書信息、書籍源信息、預(yù)留信息等進(jìn)行查詢，對其他圖書館的書籍、資料源信息的查詢功能。

理論上，系統(tǒng)的功能需求描述應(yīng)該是既完備又一致的。完備意味著用戶所需的所有服務(wù)都應(yīng)該給出描述，一致意味著需求描述不能前后矛盾。

在實(shí)際中，對大型而又復(fù)雜的系統(tǒng)而言，要做到需求描述既完備又一致幾乎是不可能的。一方面因?yàn)樵跒閺?fù)雜系統(tǒng)寫需求描述時很容易出現(xiàn)錯誤和遺漏；另一方面因?yàn)樵谝粋€大型系統(tǒng)中有很多信息持有者，一個信息持有者是在一定程度上被系統(tǒng)影響的一個人或一個角色。這些信息持有者經(jīng)常有著不同和不一致的需求。在最初的描述需求的時候，這些矛盾可能不明顯，需求的不一致性潛伏在描述中，當(dāng)深入地分析之后或當(dāng)系統(tǒng)交付客戶使用之后問題就會暴露出來。

2.3.2非功能需求

非功能需求是對系統(tǒng)提供的服務(wù)或功能給出的約束，是指那些不直接關(guān)系到系統(tǒng)向用戶提供的具體服務(wù)的一類需求。它們與系統(tǒng)的總體特性相關(guān)，如可靠性、響應(yīng)時間、存儲空間占用等。換言之，非功能需求是對系統(tǒng)的實(shí)現(xiàn)定義了質(zhì)量目標(biāo)屬性要求和約束性要求。

非功能性系統(tǒng)需求，例如性能、安全性、可用性，通常會從總體上規(guī)范或約束系統(tǒng)的特性。如果一個非功能系統(tǒng)需求沒有滿足則可能使整個系統(tǒng)無法使用。例如，一個飛機(jī)系統(tǒng)不符合可靠性需求，它將不會被批準(zhǔn)飛行；一個實(shí)時控制系統(tǒng)無法滿足其性能需求，控制功能可能根本無法使用。

非功能需求源于用戶的需要。例如，預(yù)算約束、機(jī)構(gòu)政策、以及與其他軟硬件系統(tǒng)的互操作等因素。圖2-2描述了非功能需求的分類，從圖中可以看出非功能需求或是來源于所要求的軟件產(chǎn)品需求，或是來源于開發(fā)軟件的機(jī)構(gòu)需求，或是來源于外部需求。

機(jī)構(gòu)需求是由用戶或開發(fā)者所在的機(jī)構(gòu)對軟件開發(fā)過程提出的一些規(guī)范，例如交付、實(shí)現(xiàn)、標(biāo)準(zhǔn)等方面的需求；

產(chǎn)品需求主要反映了對系統(tǒng)性能的需求，包括可用性、可靠性、可移植性、效率和存儲等的需求，直接影響到軟件系統(tǒng)的質(zhì)量；安全性需求則將關(guān)系到系統(tǒng)是否可用的問題；

圖2-2非功能需求類型

外部需求范圍較廣，包括所有系統(tǒng)的外部因素及開發(fā)、運(yùn)行過程?；ゲ僮餍枨笫侵冈撥浖到y(tǒng)如何與其他系統(tǒng)實(shí)現(xiàn)互操作；法規(guī)需求和道德需求確保系統(tǒng)在法律允許的范圍內(nèi)工作和保證系統(tǒng)能夠被用戶和社會公眾所接受。

還要注意，一般對非功能需求進(jìn)行量化是比較困難的，沒有什么典型的方法。因此，對非功能需求的描述往往是模糊的，對其進(jìn)行驗(yàn)證也是比較困難的。

非功能需求通常并不改變產(chǎn)品的功能。一般來說，不管增加多少的質(zhì)量屬性，功能性需求都會保持不變。也有更復(fù)雜的情況存在，有時候非功能需求的實(shí)現(xiàn)會為產(chǎn)品增加功能(舉例：功能的存在是為了讓產(chǎn)品具有期望的特征)。功能性需求是讓產(chǎn)品工作的需求，非功能需求是為工作賦予特征的需求。所以說，功能性需求和非功能性需求是相輔相成密不可分的。

由于非功能需求和功能需求之間存在著相互作用的關(guān)系，在進(jìn)行需求描述時，有時很難將它們區(qū)分開，這將影響到對功能和非功能指標(biāo)的分析。在具體進(jìn)行軟件需求分析時，要根據(jù)所開發(fā)的軟件系統(tǒng)的類型和具體情況確定。

例如，對“大學(xué)圖書管理系統(tǒng)”可以提出以下非功能需求：

系統(tǒng)安全性需求：為保證系統(tǒng)安全性，對本圖書館的各項(xiàng)功能進(jìn)行分級、分權(quán)限操作，對各類用戶進(jìn)行確認(rèn)。對其他圖書館借閱圖書和文獻(xiàn)資料服務(wù)控制范圍，如限IP、限用戶等；

對系統(tǒng)可用性的需求：為了方便使用者，要求對所有交互操作提供在線幫助功能；

對系統(tǒng)查詢速度的需求：要求系統(tǒng)在20秒內(nèi)響應(yīng)查詢服務(wù)請求；

對系統(tǒng)可靠性的需要：要求系統(tǒng)失敗發(fā)生率小于1%。

用戶總是強(qiáng)調(diào)確定他們的功能、行為或需求——軟件讓他們做的事情。除此之外，用戶對產(chǎn)品如何良好地運(yùn)轉(zhuǎn)抱有許多期望。這些特性包括：產(chǎn)品的易用程度如何，執(zhí)行速度如何，可靠性如何，當(dāng)發(fā)生異常情況時系統(tǒng)如何處理。這些被稱為軟件質(zhì)量屬性(或質(zhì)量因素)的特性是系統(tǒng)非功能(也叫非行為)部分的需求。

雖然，在需求獲取階段客戶所提出的信息中包含提供了一些關(guān)于重要質(zhì)量特性的線索，但客戶通常不能主動提出他們的非功能期望。用戶說軟件必須“健壯”、“可靠”或“高效”時，這是很技巧地指出他們所想要的東西。從多方面考慮，質(zhì)量必須由客戶和那些構(gòu)造測試和維護(hù)軟件的人員來定義。探索用戶隱含期望的問題可以導(dǎo)致對質(zhì)量目標(biāo)的描述，并且制定可以幫助開發(fā)者創(chuàng)建完美產(chǎn)品的標(biāo)準(zhǔn)。

2.3.3軟件需求分析的風(fēng)險(xiǎn)

不重視需求過程的項(xiàng)目隊(duì)伍將自食其果。需求工程中的缺陷將給項(xiàng)目成功帶來極大風(fēng)險(xiǎn)，這里的“成功”是指推出的產(chǎn)品能以合理的價(jià)格、及時地在功能、質(zhì)量上完全滿足用戶的期望。下面將討論一些需求風(fēng)險(xiǎn)。

1.無足夠用戶參與

客戶經(jīng)常不明白為什么收集需求和確保需求質(zhì)量需花費(fèi)那么多功夫，開發(fā)人員可能也不重視用戶的參與。究其原因：一是因?yàn)殚_發(fā)人員感覺與用戶合作不如編寫代碼有意思；二是因?yàn)殚_發(fā)人員覺得已經(jīng)明白用戶的需求了。在某些情況下，與實(shí)際使用產(chǎn)品的用戶直接接觸很困難，而客戶也不太明白自己的真正需求。但還是應(yīng)讓具有代表性的用戶在項(xiàng)目早期直接參與到開發(fā)隊(duì)伍中，并一同經(jīng)歷整個開發(fā)過程。

系統(tǒng)人員在實(shí)踐過程中，也有些感覺，在實(shí)施一家公司的項(xiàng)目時，若無足夠的用戶參與，系統(tǒng)人員獲得的需求是片面的、不完整的，這樣系統(tǒng)在需求之初就埋下風(fēng)險(xiǎn)。

2.用戶需求的不斷增加

在開發(fā)中若不斷地補(bǔ)充需求，項(xiàng)目就越變越龐大以致超過其計(jì)劃及預(yù)算范圍。計(jì)劃并不總是與項(xiàng)目需求規(guī)模與復(fù)雜性、風(fēng)險(xiǎn)、開發(fā)生產(chǎn)率及需求變更實(shí)際情況相一致，這使得問題更難解決。實(shí)際上，問題根源在于用戶需求的改變和開發(fā)者對新需求所做的修改。

3.模棱兩可的需求

模棱兩可是需求規(guī)格說明中最為可怕的問題。它的一層含義是指諸多讀者對需求說明產(chǎn)生了不同的理解；另一層含義是指單個讀者能用不止一個方式來解釋某個需求說明。

處理模棱兩可需求的一種方法是組織好負(fù)責(zé)從不同角度審查需求的隊(duì)伍。僅僅簡單瀏覽一下需求文檔是不能解決模棱兩可問題的。如果不同的評審者從不同的角度對需求說明給予解釋，且每個評審人員都真正了解需求文檔，這樣二義性就不會直到項(xiàng)目后期才被發(fā)現(xiàn)，那時再發(fā)現(xiàn)的話會使得更正代價(jià)很大。

4.不必要的特性

“畫蛇添足”是指開發(fā)人員力圖增加一些“用戶欣賞”但需求規(guī)格說明中并未涉及的新功能。經(jīng)常發(fā)生的情況是用戶并不認(rèn)為這些功能很有用，以致在其上耗費(fèi)的努力白搭了。開發(fā)人員應(yīng)當(dāng)為客戶構(gòu)思方案并為他們提供一些具有創(chuàng)新意識的思路，具體提供哪些功能要在客戶所需與開發(fā)人員在允許時限內(nèi)的技術(shù)可行性之間求得平衡，開發(fā)人員應(yīng)努力使功能簡單易用，而不要未經(jīng)客戶同意，擅自脫離客戶要求，自作主張。

5.過于精簡的規(guī)格說明

有時，客戶并不明白需求分析如此重要，于是只作一份簡略的規(guī)格說明，僅涉及產(chǎn)品概念上的內(nèi)容，然后讓開發(fā)人員在項(xiàng)目進(jìn)展中去完善，結(jié)果很可能出現(xiàn)的是開發(fā)人員先建立產(chǎn)品的結(jié)構(gòu)之后再完成需求說明。這種方法可能適合于尖端研究性的產(chǎn)品或需求本身就十分靈活的情況。但在大多數(shù)情況下，這會給開發(fā)人員帶來挫折，也會給客戶帶來煩惱。

6.忽略了用戶分類

大多數(shù)產(chǎn)品是由不同的人使用其不同的特性，使用頻繁程度也有所差異，使用者受教育程度和經(jīng)驗(yàn)水平也不盡相同。如果你不能在項(xiàng)目早期就針對所有這些主要用戶進(jìn)行分類的話，必然導(dǎo)致有的用戶對產(chǎn)品感到失望。例如，菜單驅(qū)動操作對高級用戶太低效了，但含義不清的命令和快捷鍵又會使不熟練的用戶感到困難。

7.不準(zhǔn)確的計(jì)劃

據(jù)統(tǒng)計(jì)，導(dǎo)致需求過程中軟件成本估計(jì)不準(zhǔn)確的原因主要有以下五點(diǎn)：頻繁的需求變更、遺漏的需求、與用戶交流不夠、質(zhì)量低下的需求規(guī)格說明和不完善的需求分析。

對不準(zhǔn)確的要求所提問題的正確響應(yīng)是等我真正明白你的需求時，我就會來告訴你。基于不充分信息和未經(jīng)深思的對需求不成熟的估計(jì)很容易被一些因素左右。要做出估計(jì)時，最好還是給出一個范圍。未經(jīng)準(zhǔn)備的估計(jì)通常是作為一種猜測給出的，聽者卻認(rèn)為是一種承諾。因此，我們要盡量給出可達(dá)到的目標(biāo)并堅(jiān)持完成它。

2.4用戶需求獲取

優(yōu)秀軟件總是能夠最大限度地滿足用戶需求。因此，有效獲取用戶需求，是實(shí)施軟件開發(fā)時需要完成的第一項(xiàng)工作。

1．軟件需求工程過程

需求工程的目標(biāo)是創(chuàng)建和維護(hù)系統(tǒng)需求文檔?？偟倪^程包括四個高層需求工程子過程。它們是評估系統(tǒng)是否對業(yè)務(wù)有用(系統(tǒng)可行性研究)、需求發(fā)現(xiàn)(需求導(dǎo)出和分析)、將需求轉(zhuǎn)變?yōu)槟撤N標(biāo)準(zhǔn)格式描述(需求描述)以及檢驗(yàn)需求是否正確地定義了客戶所希望的系統(tǒng)(需求有效性驗(yàn)證)。

在實(shí)際中需求工程是一個活動相互交錯的迭代過程。圖2-3說明需求工程過程的交錯性。該圖將需求工程過程分解為三個活動，這些活動是組織在一個螺旋結(jié)構(gòu)中的迭代過程。

圖2-3需求工程過程的螺旋模型

螺旋模型提供了一種開發(fā)方法，準(zhǔn)許我們將需求處理到不同的詳細(xì)程度。迭代的次數(shù)是可以變化的，這樣螺旋就可以在經(jīng)過若干或所有的用戶需求導(dǎo)出后退出。如果圖中需求驗(yàn)證部分的原型活動擴(kuò)展為包括了迭代式開發(fā)，則這個模型允許需求和系統(tǒng)實(shí)現(xiàn)一同進(jìn)行。

有些人認(rèn)為需求工程任務(wù)是要提出一個結(jié)構(gòu)化方法，這包括分析系統(tǒng)和開發(fā)一組基于圖形的系統(tǒng)模型，如用例模型，作為系統(tǒng)的描述。這組模型描述了系統(tǒng)的行為和附加的信息，如對它的性能或可靠性的要求。

盡管結(jié)構(gòu)化方法在需求工程過程中起到重要的作用，但需求工程遠(yuǎn)不止于此。尤其是需求導(dǎo)出，它是一個以人為中心的活動，而人是不情愿受到嚴(yán)格系統(tǒng)模型束縛的。

事實(shí)上，所有的系統(tǒng)和需求都是在不斷變化的。開發(fā)人員都在尋求能夠更好理解軟件需求的方法；客戶的機(jī)構(gòu)也在變化；系統(tǒng)的硬件、軟件和機(jī)構(gòu)環(huán)境也在不斷改變。管理這些不斷變更的需求的過程稱為需求管理。

2．如何獲取需求

在2.3節(jié)中討論了需求的三個層次：業(yè)務(wù)需求，用戶需求和系統(tǒng)需求。在項(xiàng)目中它們在不同的時間來自不同的來源，也有著不同的目標(biāo)和對象，并需以不同的方式編寫成文檔。業(yè)務(wù)需求(或產(chǎn)品視圖和范圍)不應(yīng)包括用戶需求(或使用實(shí)例)，而所有的功能需求都應(yīng)該源于用戶需求。同時也需要獲取非功能需求，如質(zhì)量屬性。

獲取需求的步驟如下：

(1)確定需求開發(fā)過程。確定如何組織需求的收集、分析、細(xì)化并核實(shí)的步驟，并將它編寫成文檔。對重要的步驟要給予一定指導(dǎo)，這將有助于分析人員的工作，而且也使收集需求活動的安排和進(jìn)度計(jì)劃更容易進(jìn)行。

(2)編寫項(xiàng)目視圖和范圍文檔。項(xiàng)目視圖和范圍文檔應(yīng)該包括高層的產(chǎn)品業(yè)務(wù)目標(biāo)，所有的使用實(shí)例和功能需求都必須遵從能達(dá)到的業(yè)務(wù)需求。項(xiàng)目視圖說明使所有項(xiàng)目參與者對項(xiàng)目的目標(biāo)能達(dá)成共識。而范圍則是作為評估需求或潛在特性的參考。

(3)將用戶群分類并歸納各自特點(diǎn)。為避免出現(xiàn)疏忽某一用戶群需求的情況，要將可能使用產(chǎn)品的客戶分成不同組別。他們可能在使用頻率、使用特性、優(yōu)先等級或熟練程度等方面都有所差異。詳細(xì)描述出他們的個性特點(diǎn)及任務(wù)狀況，將有助于產(chǎn)品設(shè)計(jì)。

(4)選擇每類用戶的產(chǎn)品代表。為每類用戶至少選擇一位能真正代表他們需求的人作為那一類用戶的代表并能做出決策。這對于內(nèi)部信息系統(tǒng)的開發(fā)是最易實(shí)現(xiàn)的，因?yàn)榇藭r，用戶就是身邊的職員。而對于商業(yè)開發(fā)，就要在主要的客戶或測試者中建立起良好的合作關(guān)系，并確定合適的產(chǎn)品代表。他們必須一直參與項(xiàng)目的開發(fā)而且有權(quán)做出決策。

(5)建立起典型用戶的核心隊(duì)伍。把同類產(chǎn)品或你的產(chǎn)品的先前版本用戶代表召集起來，從他們那里收集目前產(chǎn)品的功能需求和非功能需求。這樣的核心隊(duì)伍對于商業(yè)開發(fā)尤為有用，因?yàn)槟銚碛幸粋€龐大且多樣的客戶基礎(chǔ)。與產(chǎn)品代表的區(qū)別在于，核心隊(duì)伍成員通常沒有決定權(quán)。

(6)讓用戶代表確定使用實(shí)例。從用戶代表處收集他們使用軟件完成所需任務(wù)的描述，討論用戶與系統(tǒng)間的交互方式和對話要求。在編寫使用實(shí)例的文檔時可采用標(biāo)準(zhǔn)模版，在使用實(shí)例基礎(chǔ)上可得到功能需求。

(7)召開應(yīng)用程序開發(fā)聯(lián)系會議。應(yīng)用程序開發(fā)聯(lián)系(JAD)會議是范圍廣的、簡便的專題討論會(Workshop)，也是分析人員與客戶代表之間一種很好的合作辦法，并能由此擬出需求文檔的底稿。該會議通過緊密而集中的討論得以將客戶與開發(fā)人員之間的合作伙伴關(guān)系付諸于實(shí)踐。

(8)分析用戶工作流程。畫一張簡單的示意圖(最好用數(shù)據(jù)流圖)來描繪出用戶什么時候獲得什么數(shù)據(jù)，并怎樣使用這些數(shù)據(jù)。編制業(yè)務(wù)過程流程的文檔將有助于明確產(chǎn)品的使用實(shí)例和功能需求。你甚至可能發(fā)現(xiàn)客戶并不真的需要一個全新的軟件系統(tǒng)就能達(dá)到他們的業(yè)務(wù)目標(biāo)。

(9)確定質(zhì)量屬性和其他非功能需求。在功能需求之外再考慮一下非功能的質(zhì)量特點(diǎn)，這會使你的產(chǎn)品達(dá)到并超過客戶的期望。這些特點(diǎn)包括性能、有效性、可靠性、可用性等，而在這些質(zhì)量屬性上客戶提供的信息相對來說就非常重要了。

(10)通過檢查當(dāng)前系統(tǒng)的問題報(bào)告來進(jìn)一步完善需求?？蛻舻膯栴}報(bào)告及補(bǔ)充需求為新產(chǎn)品或新版本提供了大量豐富的改進(jìn)及增加特性的想法，負(fù)責(zé)提供用戶支持及幫助的人能為收集需求過程提供極有價(jià)值的信息。

(11)跨項(xiàng)目重用。如果客戶要求的功能與已有的產(chǎn)品很相似，則可查看需求是否有足夠的靈活性以允許重用一些已有的軟件組件。

2.5軟件需求文檔與規(guī)格說明

軟件需求文檔(SoftwareRequirementSpecification，SRS)，又稱軟件規(guī)格說明書，是系統(tǒng)分析人員在需求分析階段必須要完成的文檔，是軟件需求分析的最終結(jié)果。它的主要作用是：作為軟件人員與用戶之間事實(shí)上的技術(shù)合同說明；作為軟件人員下一步進(jìn)行設(shè)計(jì)和編碼的基礎(chǔ)；作為測試和驗(yàn)收的依據(jù)。

2.5.1自然語言描述

自然語言時常用來書寫系統(tǒng)需求描述，如用戶需求那樣。然而，因?yàn)橄到y(tǒng)需求比用戶需求要求有更多的細(xì)節(jié)內(nèi)容，所以用自然語言描述容易造成混亂，難以理解，主要表現(xiàn)為以下幾點(diǎn)：

(1)自然語言存在二義性，會造成語義理解的偏差；

(2)一個自然語言書寫的需求描述隨意性太大；

(3)不存在一個簡單的方法，使自然語言書寫的需求模塊化。

因?yàn)檫@些問題，用自然語言書寫的需求描述容易引起誤會。在使用自然語言書寫需求時，為了盡量減少誤解，推薦下面一些簡單的指導(dǎo)原則。

(1)設(shè)計(jì)一個標(biāo)準(zhǔn)格式，并保證所用的需求定義都遵循此格式書寫。

(2)使用一致性的語言來區(qū)分強(qiáng)制性需求和可選性需求。強(qiáng)制性需求是系統(tǒng)必須支持的。定義時要使用“必須”，可選性需求不是必要的，定義時要使用“應(yīng)該”。

(3)對文本加亮(粗體、斜體、顏色)來突出顯示關(guān)鍵性需求。

(4)不要認(rèn)為讀者會理解技術(shù)性軟件語言。像體系結(jié)構(gòu)、模塊之類的語言很容易被誤解。因此，要避免使用專業(yè)術(shù)語和縮寫詞。

(5)在任何可能的情況下，都應(yīng)該嘗試把需求原理和每一個用戶需求聯(lián)系起來。

2.5.2結(jié)構(gòu)化描述

結(jié)構(gòu)化語言是書寫系統(tǒng)需求時對自然語言所做的嚴(yán)格的格式。該方法的好處是它保持了自然語言中的絕大部分好的性質(zhì)，包括表現(xiàn)能力和易懂性，同時又在不同程度上對描述做了一致性的約束。

為了用基于格式的方法來描述系統(tǒng)需求，必須定義標(biāo)準(zhǔn)格式或模板來表達(dá)需求。需求描述的結(jié)構(gòu)化是圍繞三個主要內(nèi)容進(jìn)行的，一是系統(tǒng)操縱的對象，二是系統(tǒng)運(yùn)行的功能，三是系統(tǒng)處理的事件。這樣一個以格式為基礎(chǔ)的描述胰島素泵的例子見表2-2。

胰島素泵是根據(jù)用戶的胰島素需求進(jìn)行計(jì)算的，而用戶的胰島素需求是根據(jù)自身血糖水平的變化速率得到的，這些變化速率是通過當(dāng)前和先前一次的讀數(shù)計(jì)算的。

當(dāng)用一個標(biāo)準(zhǔn)格式描述功能需求時，下列各項(xiàng)信息應(yīng)該被包括在內(nèi)。

(1)關(guān)于所定義的實(shí)體或功能的描述；

(2)關(guān)于輸入及輸入來源的描述；

(3)關(guān)于輸出及輸出去向的描述；

(4)其他被引用的實(shí)體的索引；

(5)關(guān)于所采取的行動的描述；

(6)如果一個功能性方法被用到，前置條件設(shè)定在什么邏輯子句為真時執(zhí)行該功能；后置條件設(shè)定該功能執(zhí)行之后什么邏輯子句應(yīng)該為真；

(7)關(guān)于操作的副作用(如果有的話)的描述。

使用結(jié)構(gòu)化描述消除了自然語言描述中的一些問題，這是在描述中減少了可變性和需求被有效組織的結(jié)果。然而，用一種無二義性的描述方法來書寫需求是很困難的，尤其是需要復(fù)雜計(jì)算的時候。

2.5.3軟件需求文檔

軟件需求文檔(SRS)是對系統(tǒng)開發(fā)者應(yīng)當(dāng)實(shí)現(xiàn)的內(nèi)容的正式陳述。它應(yīng)該包括系統(tǒng)的用戶需求和一個詳細(xì)的系統(tǒng)需求描述。在某些情況下，用戶需求和系統(tǒng)需求被集中在一起描述。在其他情況下，用戶需求在系統(tǒng)需求的引言部分給出。如果有很多的需求，詳細(xì)的系統(tǒng)需求可能被分開到不同文檔中單獨(dú)描述。

表2-3是一個基于IEEE標(biāo)準(zhǔn)的需求文檔的結(jié)構(gòu)。該內(nèi)容將有助于系統(tǒng)的維護(hù)人員，允許系統(tǒng)設(shè)計(jì)人員加入對未來系統(tǒng)特點(diǎn)的支持。

需求文檔中內(nèi)容的詳細(xì)程度，取決于所要開發(fā)的系統(tǒng)的類型，以及所使用的開發(fā)過程。當(dāng)一個系統(tǒng)是由某個外部機(jī)構(gòu)承擔(dān)開發(fā)的時候，要求極高的一類系統(tǒng)描述就需要非常精確和詳細(xì)。如果需求中有較大的彈性，且系統(tǒng)是由本機(jī)構(gòu)內(nèi)部開發(fā)的話，文檔就不必寫得太詳細(xì)，一些二義性問題可以在開發(fā)階段得以解決。

當(dāng)軟件系統(tǒng)是大型系統(tǒng)工程項(xiàng)目的一部分時，大系統(tǒng)本身包含交互式硬件和軟件系統(tǒng)，一般就必須在細(xì)節(jié)層次上定義需求。這意味著需求文檔會非常長，而且可能包含表2-3中的大部分章節(jié)。對于長文檔，尤其需要一個詳細(xì)的目錄和文檔索引，以便讀者能快速找到所需的信息。

當(dāng)采取外包方式進(jìn)行系統(tǒng)開發(fā)時，需求文檔是至關(guān)重要的。然而，敏捷開發(fā)方法認(rèn)為，需求變更是如此頻繁以至于需求文檔在剛寫完就可能已經(jīng)過時了，所以大量的人力都浪費(fèi)了。代替形式化文檔的是采用如極限編程這樣的方法。這種方法的主要特點(diǎn)是，用戶需求應(yīng)該是一點(diǎn)一點(diǎn)地收集起來的，而且應(yīng)該書寫在卡片上。這樣，用戶就能夠在下一個系統(tǒng)增量實(shí)現(xiàn)時，優(yōu)先介紹比較緊迫的需求。

2.6系統(tǒng)流程圖

系統(tǒng)流程圖是概括地描繪物理系統(tǒng)的工具。所謂物理系統(tǒng)，是指一個具體實(shí)現(xiàn)的系統(tǒng)，也是描述一個組織的信息處理具體實(shí)現(xiàn)的系統(tǒng)。它不僅能用于需求分析階段，還能用于可行性研究階段。在可行性分析過程中，可以用系統(tǒng)流程圖來描述所建議系統(tǒng)的物理模型。

系統(tǒng)流程圖的基本思想是用圖形符號以黑盒子形式描繪組成系統(tǒng)的每個部件(程序、文檔、數(shù)據(jù)庫、人工過程等)。它表達(dá)了數(shù)據(jù)在系統(tǒng)各部件之間流動的情況，不是對數(shù)據(jù)進(jìn)行加工處理的控制過程，因此盡管系統(tǒng)流程圖的某些符號和程序流程圖的符號形式相同，但是它卻是物理數(shù)據(jù)流圖而不是程序流程圖。

1．系統(tǒng)流程圖符號

當(dāng)以概括的方式抽象地描繪一個實(shí)際系統(tǒng)時，只需要使用表2-4中列出的基本符號就可以了。

當(dāng)需要更具體地描繪一個物理系統(tǒng)時還需要使用表2-5中的系統(tǒng)符號，利用這些符號可以把一個廣義的輸入/輸出操作具體化為讀/寫存儲在特殊設(shè)備上的文件(或數(shù)據(jù)庫)，把抽象處理具體化為特定的程序或手工操作等。

畫系統(tǒng)流程圖時，首先要搞清楚業(yè)務(wù)處理過程以及處理中的各個元素，同時要理解系統(tǒng)流程圖中各個符號的含義，選擇相應(yīng)的符號來代表系統(tǒng)中的各個元素。所畫的系統(tǒng)流程圖要反映出系統(tǒng)的處理流程。

2．系統(tǒng)流程圖示例

下面我們通過一個簡單的例子來介紹系統(tǒng)流程圖的用法。

舉例：某裝配廠有一座存放零件的倉庫，倉庫中現(xiàn)有的各種零件的數(shù)量以及每種零件的庫存量臨界值等數(shù)據(jù)記錄在庫存清單主文件中。當(dāng)倉庫中零件數(shù)量有變化時，應(yīng)該及時修改庫存清單主文件，如果哪種零件的庫存量少于它的庫存量臨界值，則應(yīng)該報(bào)告給采購部門以便定貨，規(guī)定每天向采購部門送一次定貨報(bào)告。

該裝配廠使用一臺小型計(jì)算機(jī)處理更新庫存清單主文件和產(chǎn)生定貨報(bào)告的任務(wù)。零件庫存量的每一次變化稱為一個事務(wù)，由放在倉庫中的CRT終端輸入到計(jì)算機(jī)中；系統(tǒng)中的庫存清單程序?qū)κ聞?wù)進(jìn)行處理，更新存儲在磁盤上的庫存清單主文件，并且把必要的定貨信息寫在磁帶上。最后，每天由報(bào)告生成程序讀一次磁帶，并且打印出定貨報(bào)告。

圖2-4的系統(tǒng)流程圖描繪了上述系統(tǒng)的概貌。圖2-4庫存清單系統(tǒng)的系統(tǒng)流程圖

需要說明的是，圖中每個符號用黑盒子形式定義了組成系統(tǒng)的一個部件，然而并沒有指明每個部件的具體工作過程；圖中的箭頭確定了信息通過系統(tǒng)的邏輯路徑。系統(tǒng)流程圖的習(xí)慣畫法是使信息在圖中從頂向下或從左向右流動。

我們再看一個管理圖書館的例子。圖2-5描述了圖書館借書系統(tǒng)流程圖。

舉例：學(xué)校圖書館借書流程是：讀者先被驗(yàn)明證件后進(jìn)入圖書查詢室，在查詢室通過檢書卡或者利用CRT終端檢索圖書數(shù)據(jù)庫來查詢自己需要的圖書。讀者在找到圖書后填寫索書單，交到服務(wù)臺借書。如果所借圖書有剩余，管理員將填好借書單，從庫房取出圖書交予讀者。

圖2-5圖書館借書系統(tǒng)流程圖

2.7數(shù)據(jù)流圖

數(shù)據(jù)流圖(DataFlowDiagram，DFD)是描述數(shù)據(jù)處理過程的工具。它從信息傳遞和加工的角度，以圖形化方式描繪信息流和數(shù)據(jù)從輸入移動到輸出的過程中所經(jīng)過的變換，只是描繪數(shù)據(jù)在軟件中流動和被處理的邏輯過程。它只反映系統(tǒng)必須完成的邏輯功能，所以是一種功能模型。數(shù)據(jù)流圖是系統(tǒng)邏輯功能的圖形表示，即使不是專業(yè)的計(jì)算機(jī)技術(shù)人員也容易理解它，因此是系統(tǒng)分析員與用戶之間極好的通信工具。

此外，設(shè)計(jì)數(shù)據(jù)流圖時只需考慮系統(tǒng)必須完成的基本邏輯功能，完全不需要考慮怎樣具體地實(shí)現(xiàn)這些功能，也就是說，數(shù)據(jù)流圖基本要點(diǎn)是描繪系統(tǒng)“做什么”，而不考慮系統(tǒng)“怎么做”，所以它也是后面進(jìn)行軟件設(shè)計(jì)的很好出發(fā)點(diǎn)，如圖2-6所示。

圖2-6數(shù)據(jù)流圖的框圖

2.7.1數(shù)據(jù)流圖的符號

基于計(jì)算機(jī)的信息處理系統(tǒng)有數(shù)據(jù)流和一系列加工構(gòu)成，這些加工將輸入數(shù)據(jù)流加工為輸出數(shù)據(jù)流。數(shù)據(jù)流圖用圖形符號表示數(shù)據(jù)流、加工、數(shù)據(jù)源及外部實(shí)體。它具有層次結(jié)構(gòu)，支持問題分解、逐步求精的分析方法，是數(shù)據(jù)驅(qū)動的。

數(shù)據(jù)流圖有四種基本符號：正方形(或立方體)表示數(shù)據(jù)的源點(diǎn)或終點(diǎn)；圓角矩形(或圓形)代表變換數(shù)據(jù)的處理；開口矩形(或兩條平行橫線)代表數(shù)據(jù)存儲；箭頭表示數(shù)據(jù)流，即特定數(shù)據(jù)的流動方向，見表2-6。

注意，在數(shù)據(jù)流圖中應(yīng)該描繪所有可能的數(shù)據(jù)流向，而不應(yīng)該描繪出現(xiàn)某個數(shù)據(jù)流的條件。

數(shù)據(jù)存儲和數(shù)據(jù)流都是數(shù)據(jù)，僅僅在于所處的狀態(tài)不同。數(shù)據(jù)存儲是處于靜止?fàn)顟B(tài)的數(shù)據(jù)，數(shù)據(jù)流是處于運(yùn)動中的數(shù)據(jù)。

2.7.2設(shè)計(jì)數(shù)據(jù)流圖的步驟和示例

數(shù)據(jù)流圖目的是讓用戶明確系統(tǒng)中數(shù)據(jù)流動和處理的情況。對于一個系統(tǒng)來說，表示數(shù)據(jù)流圖的較好方法是分層次描述系統(tǒng)。頂層數(shù)據(jù)流圖描述系統(tǒng)的總體概貌，然后把每個關(guān)鍵功能適當(dāng)?shù)剡M(jìn)行詳細(xì)描述。這樣分層次描述，便于用戶逐步深入地了解一個復(fù)雜系統(tǒng)。數(shù)據(jù)流圖可以按自頂向下、逐步分解的方法表示內(nèi)容不斷增加的數(shù)據(jù)流和功能細(xì)節(jié)。數(shù)據(jù)流圖的設(shè)計(jì)步驟如下：

(1)從問題描述中分析出外部實(shí)體、加工、數(shù)據(jù)存儲、數(shù)據(jù)流模型；

(2)根據(jù)第一步結(jié)果畫出基本系統(tǒng)數(shù)據(jù)流圖，即頂層圖；

(3)把頂層數(shù)據(jù)流圖細(xì)化為功能級數(shù)據(jù)流圖；

(4)將功能級數(shù)據(jù)流圖中的主要功能進(jìn)一步細(xì)化，直至滿意為止。

各種軟件系統(tǒng)，無論其數(shù)據(jù)流圖如何復(fù)雜和龐大，根據(jù)數(shù)據(jù)處理對象和處理方式不同，通常又將數(shù)據(jù)流圖劃分為變換型數(shù)據(jù)流圖和事務(wù)型數(shù)據(jù)流圖。變換型數(shù)據(jù)流圖具有較明顯的輸入、主加工和輸出，其中主加工是系統(tǒng)的中心。事務(wù)型數(shù)據(jù)流圖的特征是，某個加工將它的輸入分離成一串發(fā)散的數(shù)據(jù)流，形成許多活動路徑，并根據(jù)輸入的值選擇其中一條路徑。這兩類結(jié)構(gòu)往往同時存在于一個系統(tǒng)的數(shù)據(jù)流圖中。某些系統(tǒng)的整體結(jié)構(gòu)是事務(wù)型，而在它的某些動作路徑中出現(xiàn)變換型結(jié)構(gòu)。還有些情況正好相反，系統(tǒng)整體是變換型，某些部分又可能具有事務(wù)型結(jié)構(gòu)特征。

下面我們以某個工廠的定貨系統(tǒng)為例，來說明數(shù)據(jù)流圖的畫法。

舉例：假設(shè)一家工廠的采購部每天需要一張定貨報(bào)表，報(bào)表按零件編號排序，表中列出所有需要再次定貨的零件。對于每個需要再次定貨的零件應(yīng)該列出下述數(shù)據(jù)：零件編號，零件名稱，定貨數(shù)量，目前價(jià)格，主要供應(yīng)者，次要供應(yīng)者等。零件入庫或出庫稱為事務(wù)，通過放在倉庫中的CRT終端把事務(wù)報(bào)告給定貨系統(tǒng)。當(dāng)某種零件的庫存數(shù)量少于庫存量臨界值時就應(yīng)該再次定貨。

1.確定系統(tǒng)數(shù)據(jù)流圖的4個部分并畫出頂層圖

數(shù)據(jù)流圖有4種成分：源點(diǎn)或終點(diǎn)，加工，數(shù)據(jù)存儲和數(shù)據(jù)流。因此，第一步可以從問題描述中提取數(shù)據(jù)流圖的4種成分：首先考慮數(shù)據(jù)的源點(diǎn)和終點(diǎn)，從上面對系統(tǒng)的描述可以知道“采購部每天需要一張定貨報(bào)表”，“通過放在倉庫中的CRT終端把事務(wù)報(bào)告給定貨系統(tǒng)”，所以采購員是數(shù)據(jù)終點(diǎn)，而倉庫管理員是數(shù)據(jù)源點(diǎn)。接下來考慮加工，再一次閱讀問題描述，“采購部需要報(bào)表”，顯然他們還沒有這種報(bào)表，因此必須有一個用于產(chǎn)生報(bào)表的加工。事務(wù)的后果是改變零件庫存量，然而任何改變數(shù)據(jù)的操作都是加工，因此對事務(wù)進(jìn)行的加工是另一個加工。

注意，在問題描述中并沒有明顯地提到需要對事務(wù)進(jìn)行處理，但是通過分析可以看出這種需要。最后，考慮數(shù)據(jù)流和數(shù)據(jù)存儲：系統(tǒng)把定貨報(bào)表送給采購部，因此定貨報(bào)表是一個數(shù)據(jù)流；事務(wù)需要從倉庫送到系統(tǒng)中，顯然事務(wù)是另一個數(shù)據(jù)流。產(chǎn)生報(bào)表和處理事務(wù)這兩個加工在時間上明顯不匹配——每當(dāng)有一個事務(wù)發(fā)生時立即處理它，然而每天只產(chǎn)生一次定貨報(bào)表。因此，用來產(chǎn)生定貨報(bào)表的數(shù)據(jù)必須存放一段時間，也就是應(yīng)該有一個數(shù)據(jù)存儲。注意，并不是所有數(shù)據(jù)存儲和數(shù)據(jù)流都能直接從問題描述中提取出來。圖2-7展示了定貨系統(tǒng)的基本系統(tǒng)模型。

圖2-7定貨系統(tǒng)的基本系統(tǒng)模型

2.進(jìn)一步細(xì)化功能級數(shù)據(jù)流圖

下一步把基本系統(tǒng)模型細(xì)化，描繪系統(tǒng)的主要功能?！疤幚硎聞?wù)”和“產(chǎn)生報(bào)表”是系統(tǒng)必須完成的兩個主要功能，代替圖2-7中的“定貨系統(tǒng)”。此外，細(xì)化后的數(shù)據(jù)流圖中還需增加兩個數(shù)據(jù)存儲：處理事務(wù)需要“庫存清單”數(shù)據(jù)；產(chǎn)生報(bào)表和處理事務(wù)在不同時間，因此需要存儲“定貨信息”。相應(yīng)增加另外兩個數(shù)據(jù)流，它們與數(shù)據(jù)存儲相同。因?yàn)閺囊粋€數(shù)據(jù)存儲中取出來的或放進(jìn)去的數(shù)據(jù)通常和原來存儲的數(shù)據(jù)相同，也就是說，數(shù)據(jù)存儲和數(shù)據(jù)流只不過是同樣數(shù)據(jù)的兩種不同形式。圖2-8中給加工和數(shù)據(jù)存儲都加上了編號，目的是便于引用和追蹤。

圖2-8定貨系統(tǒng)的功能級數(shù)據(jù)流圖

接下來應(yīng)該對功能級數(shù)據(jù)流圖中的系統(tǒng)主要功能進(jìn)一步細(xì)化?？紤]通過系統(tǒng)的邏輯數(shù)據(jù)流：當(dāng)發(fā)生一個事務(wù)時必須首先接收它；隨后按照事務(wù)的內(nèi)容修改庫存清單；最后如果更新后的庫存量少于庫存量臨界值時，則應(yīng)該再次定貨，也就是需要處理定貨信息。因此，把“處理事務(wù)”這個功能分解為以下3個步驟：“接收事務(wù)”、“更新庫存清單”和“處理定貨”，如圖2-9所示。

圖2-9把處理事務(wù)的功能進(jìn)一步分解后的數(shù)據(jù)流圖

在一個實(shí)際的系統(tǒng)中，可能需要畫多張數(shù)據(jù)流圖。為了反映系統(tǒng)的概貌，需要畫出高層數(shù)據(jù)流圖；為了反映局部細(xì)節(jié)，需要在較低層次，畫出詳細(xì)的數(shù)據(jù)流圖。因而，數(shù)據(jù)流圖是自上而下逐步細(xì)化的，如圖2-10所示。

圖2-10分層數(shù)據(jù)流圖

2.7.3數(shù)據(jù)流圖中命名的可理解性

數(shù)據(jù)流圖中每個成分的命名是否恰當(dāng)，直接影響數(shù)據(jù)流圖的可理解性。因此，給這些成分命名時應(yīng)該仔細(xì)推敲。下面講述對數(shù)據(jù)流圖中數(shù)據(jù)存儲、數(shù)據(jù)流、加工以及外部實(shí)體的命名應(yīng)注意的問題。

1.為數(shù)據(jù)流(或數(shù)據(jù)存儲)命名

為數(shù)據(jù)流(或數(shù)據(jù)存儲)命名需注意以下問題：

(1)命名應(yīng)與實(shí)際的業(yè)務(wù)相結(jié)合。

(2)名字應(yīng)代表整個數(shù)據(jù)流(或數(shù)據(jù)存儲)的內(nèi)容，而不是僅僅反映它的某些成分。

(3)不要使用空洞的、缺乏具體含義的名字，例如“數(shù)據(jù)”、“信息”、“輸入”等。

(4)如果在為某個數(shù)據(jù)流(或數(shù)據(jù)存儲)起名字時遇到了困難，則很可能是因?yàn)閷?shù)據(jù)流圖分解不恰當(dāng)造成的，應(yīng)該試試重新分解，看是否能克服這個困難。

2.為加工命名

為加工命名需注意以下問題：

(1)通常先為數(shù)據(jù)流命名，然后再為與之相關(guān)聯(lián)的加工處理命名。這樣命名比較容易，而且體現(xiàn)了人們習(xí)慣的“由表及里”的思考過程。

(2)名字應(yīng)該反映整個處理的功能，而不是它的一部分功能。

(3)名字最好由一個具體的及物動詞加上一個具體的賓語組成。應(yīng)該盡量避免使用“加工”、“處理”等空洞籠統(tǒng)的動詞作名字。

(4)通常名字中僅包括一個動詞，如果必須用兩個動詞才能描述整個加工處理的功能，則把這個處理再分解成兩個加工處理可能更恰當(dāng)些。

(5)如果在為某個加工處理命名時遇到困難，則很可能是分解不當(dāng)造成的，應(yīng)考慮重新分解。

3.為外部實(shí)體命名

數(shù)據(jù)源點(diǎn)/終點(diǎn)并不需要在開發(fā)目標(biāo)系統(tǒng)的過程中設(shè)計(jì)和實(shí)現(xiàn)，它并不屬于數(shù)據(jù)流圖的核心內(nèi)容，只不過是目標(biāo)系統(tǒng)的外圍環(huán)境部分(可能是人員、計(jì)算機(jī)外部設(shè)備或傳感器裝置)。通常，為數(shù)據(jù)源點(diǎn)/終點(diǎn)命名時采用它們在問題域中習(xí)慣使用的術(shù)語(如“采購員”、“倉庫管理員”等)。

2.7.4數(shù)據(jù)流圖的用途

可以依靠數(shù)據(jù)流圖來實(shí)現(xiàn)從用戶需求到系統(tǒng)需求的過渡。例如，可以將用戶需求陳述中的關(guān)鍵名詞、動詞提取出來，其中的名詞可以作為數(shù)據(jù)流圖中的數(shù)據(jù)源、數(shù)據(jù)存儲，而動詞則可以作為數(shù)據(jù)流圖中的數(shù)據(jù)加工進(jìn)程。

數(shù)據(jù)流圖也能夠方便系統(tǒng)物理模型與邏輯模型之間的轉(zhuǎn)換，可以將圖2-4中系統(tǒng)流程圖經(jīng)過符號轉(zhuǎn)換而獲得系統(tǒng)的數(shù)據(jù)流圖。

研究表明，一張數(shù)據(jù)流圖包含的加工處理多于9個時，用戶將難于領(lǐng)會它的含義。因此數(shù)據(jù)流圖必須分層細(xì)化，并且在把功能級數(shù)據(jù)流圖細(xì)化后得到的處理超過9個加工，也就是把每個主要功能都細(xì)化為一張數(shù)據(jù)流分圖，而原有的功能級數(shù)據(jù)流圖用來描繪系統(tǒng)的整體邏輯概貌。

當(dāng)用數(shù)據(jù)流圖輔助物理系統(tǒng)的設(shè)計(jì)時，以圖中不同處理的定時要求為指南，能夠在數(shù)據(jù)流圖上畫出許多組自動化邊界，每組自動化邊界可能意味著一個不同的物理系統(tǒng)，因此可以根據(jù)系統(tǒng)的邏輯模型考慮系統(tǒng)的物理實(shí)現(xiàn)。例如，考慮圖2-9，事務(wù)隨時可能發(fā)生，因此處理1.1(“接收事務(wù)”)必須是聯(lián)機(jī)的；采購員每天需要一次定貨報(bào)表，因此處理2(“產(chǎn)生報(bào)表”)應(yīng)該以批量方式進(jìn)行。問題描述并沒有對其他處理施加限制，例如，可以聯(lián)機(jī)地接收事務(wù)并放入隊(duì)列中，然而更新庫存清單、處理定貨和產(chǎn)生報(bào)表以批量方式進(jìn)行，如圖2-11所示。當(dāng)然，這種方案需要增加一個數(shù)據(jù)存儲以存放事務(wù)數(shù)據(jù)。

圖2-11此種劃分自動化邊界的方法暗示以批量方式更新庫存清單、一次定貨

改變自動化邊界，把處理1.1、1.2和1.3放在同一個邊界內(nèi)，如圖2-12所示，這個系統(tǒng)將聯(lián)機(jī)地接收事務(wù)、更新庫存清單和處理定貨及輸出定貨信息；然而處理2將以批量方式產(chǎn)生定貨報(bào)表。

圖2-12此種劃分自動化邊界的方法建議以聯(lián)機(jī)方式更新庫存清單、批量定貨

2.7.5數(shù)據(jù)流圖中的數(shù)據(jù)字典

在需求分析中，數(shù)據(jù)字典是各類數(shù)據(jù)描述的集合，能夠提供對數(shù)據(jù)的詳細(xì)規(guī)格定義，并可用于驗(yàn)證數(shù)據(jù)，以發(fā)現(xiàn)系統(tǒng)在數(shù)據(jù)需求描述中是否出現(xiàn)遺漏。

數(shù)據(jù)流圖中的數(shù)據(jù)字典能夠提供對圖中的諸多數(shù)據(jù)元素的更加詳細(xì)的說明。其一般要求是：(1)對數(shù)據(jù)的定義應(yīng)該是嚴(yán)密、精確、一致的，不能有二義性；(2)需要對數(shù)據(jù)流圖中的每一個被命名的數(shù)據(jù)元素進(jìn)行定義；(3)需要分類定義各種不同種類的數(shù)據(jù)元素，或采用類別代號加以區(qū)別。

數(shù)據(jù)流圖中的數(shù)據(jù)字典通常包括數(shù)據(jù)項(xiàng)、數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)流、數(shù)據(jù)存儲、數(shù)據(jù)接口和數(shù)據(jù)處理過程這幾個部分的數(shù)據(jù)內(nèi)容。其中，數(shù)據(jù)項(xiàng)是數(shù)據(jù)的最小組成單位，若干個數(shù)據(jù)項(xiàng)可以組成一個數(shù)據(jù)結(jié)構(gòu)。數(shù)據(jù)字典就是通過對數(shù)據(jù)項(xiàng)和數(shù)據(jù)結(jié)構(gòu)的定義來描述數(shù)據(jù)流、數(shù)據(jù)存儲的邏輯內(nèi)容的。

1．?dāng)?shù)據(jù)項(xiàng)

數(shù)據(jù)項(xiàng)是不可再分的數(shù)據(jù)單位。對數(shù)據(jù)項(xiàng)的描述通常包括以下內(nèi)容：

｛數(shù)據(jù)項(xiàng)名，數(shù)據(jù)項(xiàng)含義說明，別名，數(shù)據(jù)類型，長度，取值范圍，取值含義，與其他數(shù)據(jù)項(xiàng)的邏輯關(guān)系｝

以學(xué)生學(xué)籍管理子系統(tǒng)為例，該子系統(tǒng)涉及多個數(shù)據(jù)項(xiàng)，其中“學(xué)號”數(shù)據(jù)項(xiàng)可以如下描述。

數(shù)據(jù)項(xiàng)名：學(xué)號

含義說明：唯一標(biāo)識每個學(xué)生

別名：學(xué)生編號

數(shù)據(jù)類型：字符型

長度：8

取值范圍：00000000至99999999

取值含義：前兩位標(biāo)別該學(xué)生所在年級，后六位按順序編號

與其他數(shù)據(jù)項(xiàng)的邏輯關(guān)系(略)

2．?dāng)?shù)據(jù)結(jié)構(gòu)

數(shù)據(jù)結(jié)構(gòu)反映了數(shù)據(jù)之間的組合關(guān)系。一個數(shù)據(jù)結(jié)構(gòu)可以由若干個數(shù)據(jù)項(xiàng)組成，也可以由若干個數(shù)據(jù)結(jié)構(gòu)組成，或由若干個數(shù)據(jù)項(xiàng)和數(shù)據(jù)結(jié)構(gòu)混合組成。對數(shù)據(jù)結(jié)構(gòu)的描述通常包括以下內(nèi)容：

｛數(shù)據(jù)結(jié)構(gòu)名，含義說明，組成：｛數(shù)據(jù)項(xiàng)或數(shù)據(jù)結(jié)構(gòu)｝｝

在定義數(shù)據(jù)結(jié)構(gòu)時，可以采用以下符號說明數(shù)據(jù)的組成：

=

被定義為，表示數(shù)據(jù)組成。

+

與，用于連接兩個數(shù)據(jù)分量。

或，從若干數(shù)據(jù)分量中選擇一個，方括號中的數(shù)據(jù)分量用“|”號隔開。

重復(fù)，重復(fù)大括號內(nèi)的數(shù)據(jù)，最少重復(fù)m次，最多重復(fù)n次。

可選，圓括號內(nèi)數(shù)據(jù)可有可無。

我們再來看一個用數(shù)據(jù)字典定義電話號碼的例子。

舉例：某高校內(nèi)部用的電話號碼有以下幾類：校內(nèi)電話號碼由4位數(shù)字組成，第1位數(shù)字不是0；校外電話又分為市內(nèi)電話和長途電話，撥校外電話需先撥0，如果是市內(nèi)電話再接著撥8位電話號碼(第1位不是0)，如果是長途電話則先撥3位區(qū)碼，再撥8位電話號碼(第1位不是0)。上述電話號碼的定義如下：

電話號碼=[校內(nèi)電話號碼|校外電話號碼]

校內(nèi)電話號碼=非零數(shù)字+3位數(shù)字

校外電話號碼=[市內(nèi)號碼|長途號碼]

市內(nèi)號碼=數(shù)字零+8位數(shù)字

長途號碼=數(shù)字零+3位數(shù)字+8位數(shù)字

數(shù)字零=0

非零數(shù)字=[1|2|3|4|5|6|7|8|9]

3位數(shù)字=3{數(shù)字}3

8位數(shù)字=非零數(shù)字+7位數(shù)字

7位數(shù)字=7{數(shù)字}7

數(shù)字=[0|1|2|3|4|5|6|7|8|9]

以“學(xué)生”為例，“學(xué)生”是該系統(tǒng)中的一個核心數(shù)據(jù)結(jié)構(gòu)，它可以描述如下：

數(shù)據(jù)結(jié)構(gòu)：學(xué)生

含義說明：是學(xué)籍管理子系統(tǒng)的主體數(shù)據(jù)結(jié)構(gòu)，定義了一個學(xué)生的有關(guān)信息

組成：學(xué)號+姓名+性別+年齡+所在系+年級

3．?dāng)?shù)據(jù)流

數(shù)據(jù)流是數(shù)據(jù)結(jié)構(gòu)在軟件系統(tǒng)內(nèi)傳輸?shù)穆窂?。對?shù)據(jù)流的描述通常包括以下內(nèi)容：

｛數(shù)據(jù)流名，說明，數(shù)據(jù)流來源，數(shù)據(jù)流去向，組成｛數(shù)據(jù)結(jié)構(gòu)｝，平均流量，高峰期流量｝

其中，數(shù)據(jù)流來源是說明該數(shù)據(jù)流來自哪個過程。數(shù)據(jù)流去向是說明該數(shù)據(jù)流將到哪個過程去。平均流量則是指在單位時間(每天、每周、每月等)里的傳輸次數(shù)。高峰期流量則是指在高峰時期的數(shù)據(jù)流量。

以“入庫單”為例，描述如下：

數(shù)據(jù)流：

入庫單

編號：x-xx

簡述：

倉庫驗(yàn)收物料后輸入入庫單

來源：

驗(yàn)收入庫加工處理

流向：

物料庫存文件，結(jié)算加工處理

流通量：

平均10份/天

包含的數(shù)據(jù)結(jié)構(gòu)：物料編號、物料名稱、入庫數(shù)量、入庫日期。

4．?dāng)?shù)據(jù)存儲

數(shù)據(jù)存儲是數(shù)據(jù)結(jié)構(gòu)停留或保存的地方，也是數(shù)據(jù)流的來源和去向之一。對數(shù)據(jù)存儲的描述通常包括以下內(nèi)容。

｛數(shù)據(jù)存儲名，說明，編號，流入的數(shù)據(jù)流，流出的數(shù)據(jù)流，組成｛數(shù)據(jù)結(jié)構(gòu)｝，數(shù)據(jù)量，存取方式｝

其中，數(shù)據(jù)量是指每次存取多少數(shù)據(jù)，每天(或每小時、每周等)存取幾次等信息。存取方式則包括：是批處理還是聯(lián)機(jī)處理，是檢索還是更新，是順序檢索還是隨機(jī)檢索等。另外，流入的數(shù)據(jù)流要指出其來源，流出的數(shù)據(jù)流要指出其去向。

以數(shù)據(jù)存儲“學(xué)生登記表”為例，描述如下：

數(shù)據(jù)存儲：學(xué)生登記表

說明：記錄學(xué)生的基本情況

流入數(shù)據(jù)流：…

流出數(shù)據(jù)流：…

組成：…

數(shù)據(jù)量：每年3000張

存取方式：隨機(jī)存取

2.8實(shí)體-聯(lián)系圖

需求分析的一項(xiàng)重要任務(wù)就是弄清楚系統(tǒng)要處理的數(shù)據(jù)和數(shù)據(jù)之間的關(guān)系。為了把用戶的數(shù)據(jù)要求清楚、準(zhǔn)確地描述出來，系統(tǒng)分析員通常建立一個概念性的數(shù)據(jù)模型，即實(shí)體-聯(lián)系圖。概念性數(shù)據(jù)模型是一種面向問題的數(shù)據(jù)模型，是按照用戶的觀點(diǎn)對數(shù)據(jù)建立的模型。它描述了從用戶角度看到的數(shù)據(jù)，反映了用戶的現(xiàn)實(shí)環(huán)境，而且與在軟件系統(tǒng)中的實(shí)現(xiàn)方法無關(guān)。數(shù)據(jù)模型中包含3種相互關(guān)聯(lián)的信息：數(shù)據(jù)對象(實(shí)體)、數(shù)據(jù)對象的屬性、數(shù)據(jù)對象彼此間相互連接的聯(lián)系(關(guān)系)。

1．?dāng)?shù)據(jù)對象(實(shí)體)

數(shù)據(jù)對象是對軟件必須理解的復(fù)合信息的抽象。所謂復(fù)合信息，是指具有一系列不同性質(zhì)或?qū)傩缘氖挛?，僅有單一屬性的事物不是數(shù)據(jù)對象。

數(shù)據(jù)對象可以是：

外部實(shí)體，例如，產(chǎn)生或使用信息的任何事物；

事物，例如，報(bào)表；

行為，例如，打電話；

事件，例如，響警報(bào)；

角色，例如，教師、學(xué)生；

單位，例如，會計(jì)科；

地點(diǎn)，例如，倉庫；

結(jié)構(gòu)，例如，文件、目錄。

總之，可以由一組屬性來定義的實(shí)體都可以被認(rèn)為是數(shù)據(jù)對象，如圖2-13所示。

圖2-13圖書數(shù)據(jù)對象描述

數(shù)據(jù)對象彼此間是有關(guān)聯(lián)的，例如，教師“教”課程，學(xué)生“學(xué)”課程，教或?qū)W的關(guān)系表示教師和課程或?qū)W生和課程之間的一種特定的連接。需要注意的是，數(shù)據(jù)對象只封裝了數(shù)據(jù)而沒有對施加于數(shù)據(jù)上的操作進(jìn)行描述，這是數(shù)據(jù)對象與面向?qū)ο蠓缎椭械摹邦悺被颉皩ο蟆钡娘@著區(qū)別。

2．屬性

屬性定義了數(shù)據(jù)對象的性質(zhì)。一個數(shù)據(jù)對象有若干屬性，必須把一個或多個屬性定義為“標(biāo)識符”，也就是說，當(dāng)我們希望找到數(shù)據(jù)對象的一個實(shí)例時，用標(biāo)識符屬性作為“關(guān)鍵字”(通常簡稱為“鍵”)。應(yīng)該根據(jù)對所要解決的問題的理解，來確定特定數(shù)據(jù)對象的一組合適的屬性。例如，在教學(xué)管理系統(tǒng)中，學(xué)生具有學(xué)號、姓名、性別、年齡、專業(yè)等屬性，課程具有課程號、課程名、學(xué)分、學(xué)時數(shù)等屬性，教師具有職工號、姓名、年齡、職稱等屬性。屬性定義了數(shù)據(jù)對象、聯(lián)系的性質(zhì)，在設(shè)計(jì)屬性時，應(yīng)該根據(jù)對要解決的問題的理解，來確定數(shù)據(jù)對象、聯(lián)系的一組適當(dāng)?shù)膶傩浴?/p>

對數(shù)據(jù)字典中的4類元素進(jìn)行分類、組織。數(shù)據(jù)項(xiàng)是基本數(shù)據(jù)單位，一般可作為數(shù)據(jù)對象的屬性。數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)存儲、數(shù)據(jù)流都可以作為數(shù)據(jù)對象，這三類元素總是包含了若干的數(shù)據(jù)項(xiàng)。

3．聯(lián)系

數(shù)據(jù)對象彼此之間相互連接的方式稱為聯(lián)系，也稱為關(guān)系。例如，學(xué)生可以通過學(xué)號、分?jǐn)?shù)與課程和教師發(fā)生聯(lián)系，如此可得教學(xué)實(shí)體關(guān)系圖，如圖2-14所示。

圖2-14某校教學(xué)管理E-R圖

假如X和Y都是數(shù)據(jù)對象，則其聯(lián)系可分為以下3種類型：

(1)一對一聯(lián)系(1:1)。X的一次出現(xiàn)只能聯(lián)系到Y(jié)的一次出現(xiàn)，Y的一次出現(xiàn)只能聯(lián)系到X的一次出現(xiàn)。例如，一個部門有一個經(jīng)理，而每個經(jīng)理只在一個部門任職，則部門與經(jīng)理的聯(lián)系是一對一的。

(2)一對多聯(lián)系(1:N)。X的一次出現(xiàn)可以聯(lián)系到Y(jié)的一次或多次出現(xiàn)，但Y的一次出現(xiàn)只能聯(lián)系到X的一次出現(xiàn)。例如，某校教師與課程之間存在一對多的聯(lián)系“教”，即每位教師可以教多門課程，但是每門課程只能由一位教師來教，如圖2-14所示。

(3)多對多聯(lián)系(M:N)。X的一次出現(xiàn)可以聯(lián)系到Y(jié)的一次或多次出現(xiàn)，同時Y的一次出現(xiàn)也可以聯(lián)系到X的一次或多次出現(xiàn)。例如，教務(wù)系統(tǒng)中，學(xué)生與課程之間的聯(lián)系是多對多的關(guān)系，即一個學(xué)生可以學(xué)多門課程，而每門課程可以有多個學(xué)生來學(xué)。

聯(lián)系也可能有屬性。例如，學(xué)生“學(xué)”某門課程所取得的成績，既不是學(xué)生的屬性也不是課程的屬性。由于“成績”既依賴于某個特定的學(xué)生又依賴于某門特定的課程，所以它是學(xué)生與課程之間的聯(lián)系“學(xué)”的屬性，如見圖2-14所示。

4．實(shí)體-聯(lián)系圖的符號

通常，使用實(shí)體-聯(lián)系圖(Entity-relationshipDiagram)來建立數(shù)據(jù)模型。可以把實(shí)體-聯(lián)系圖簡稱為E-R圖，相應(yīng)地可把用E-R圖描繪的數(shù)據(jù)模型稱為E-R模型。E-R圖中包含了實(shí)體(即數(shù)據(jù)對象)、聯(lián)系、屬性等3種基本成分，通常用矩形框代表實(shí)體，用連接相關(guān)實(shí)體的菱形框表示關(guān)系，用橢圓形或圓角矩形表示實(shí)體(或關(guān)系)的屬性，并用直線把實(shí)體(或關(guān)系)與其屬性連接起來，如圖2-15所示。

圖2-15實(shí)體-聯(lián)系圖符號

人們通常用實(shí)體、聯(lián)系和屬性這3個概念來理解現(xiàn)實(shí)問題的，因此，E-R模型比較接近人的習(xí)慣思維方式。此外，E-R模型使用簡單的圖形符號表達(dá)系統(tǒng)分析員對問題域的理解，不熟悉計(jì)算機(jī)技術(shù)的用戶也能理解它，因此，E-R模型可以作為用戶與分析員之間有效的交流工具。例如，圖2-14是教學(xué)、學(xué)生和課程的E-R圖。

注意，關(guān)聯(lián)基數(shù)經(jīng)常用符號“*”表示，它表示0…N。例如，一個家庭可以有0個或多個子女，這時就應(yīng)該用0…*表示。

2.9需求分析中使用的其他圖形工具

描述任何復(fù)雜事物，采用圖形方法要優(yōu)于文字的描述，它更直觀形象且更容易理解。前面介紹了建立功能模型的數(shù)據(jù)流圖，建立數(shù)據(jù)模型的實(shí)體-聯(lián)系圖。本節(jié)將簡要介紹幾種在需求階段可能用到的圖形工具。

1．層次方框圖

層次方框圖用樹形結(jié)構(gòu)的一系列多層次的矩形框描繪數(shù)據(jù)的層次結(jié)構(gòu)。樹形結(jié)構(gòu)的頂層是一個單獨(dú)的矩形框，它代表完整的數(shù)據(jù)結(jié)構(gòu)，下面的各層矩形框代表這個數(shù)據(jù)的子集，最底層的各個框代表組成這個數(shù)據(jù)的實(shí)際數(shù)據(jù)元素(不能再分割的元素)。例如，描繪一家計(jì)算機(jī)公司全部產(chǎn)品的數(shù)據(jù)結(jié)構(gòu)可以用圖2-16中的層次方框圖表示。

圖2-16計(jì)算機(jī)公司產(chǎn)品結(jié)構(gòu)的層次方框圖

隨著結(jié)構(gòu)的精細(xì)化，層次方框圖對數(shù)據(jù)結(jié)構(gòu)也描繪得越來越詳細(xì)，這種模式非常適合于需求分析階段的需要。系統(tǒng)分析員從對頂層信息的分類開始，沿圖中每條路徑反復(fù)細(xì)化，直到確定了數(shù)據(jù)結(jié)構(gòu)的全部細(xì)節(jié)時為止。

2．Warnier圖

Warnier圖是由法國計(jì)算機(jī)科學(xué)家Warnier提出的表示信息層次結(jié)構(gòu)的另外一種圖形工具。Warnier圖和層次方框圖很類似，用樹形結(jié)構(gòu)描繪信息，但是這種圖形工具比層次方框圖提供了更豐富的描繪手段。用Warnier圖可以表明信息的邏輯組織，也就是說，它可以指出一類信息或一個信息元素是重復(fù)出現(xiàn)的，也可以表示特定信息在某一類信息中是有條件地出現(xiàn)的。因?yàn)橹貜?fù)和條件約束是說明軟件處理過程的基礎(chǔ)，所以很容易把Warnier圖轉(zhuǎn)變成軟件設(shè)計(jì)的工具。

圖2-17是用Warnier圖描繪一類軟件產(chǎn)品的例子，它說明了這種圖形工具的用法。在圖2-17中，用大括號“{”表示層次關(guān)系，在同一個大括號下，自上向下是順序排列的信息項(xiàng)；“

”是異或符號，表示對位于其上下兩邊的信息項(xiàng)可以條件選擇，二者擇一；信息項(xiàng)后面附加了圓括號，給出該信息項(xiàng)重復(fù)的次數(shù)或種類個數(shù)。

圖2-17軟件概念的Warnier圖

例如，該Warnier圖表示一種軟件產(chǎn)品要么是系統(tǒng)軟件要么是應(yīng)用軟件。系統(tǒng)軟件中有P1種操作系統(tǒng)，P2種編譯程序，此外還有軟件工具。軟件工具是系統(tǒng)軟件的一種，它又可以進(jìn)一步細(xì)分為編輯程序、測試驅(qū)動程序和設(shè)計(jì)輔助工具。

3．IPO圖

IPO(InputProcessOutput)圖是輸入—處理—輸出圖的簡稱，是由美國IBM公司發(fā)展完善起來的一種圖形工具，能夠方便地描繪輸入數(shù)據(jù)、處理數(shù)據(jù)和輸出數(shù)據(jù)之間的關(guān)系。

IPO圖使用的基本符號既少又簡單，因此很容易學(xué)會使用這種圖形工具。IPO圖包括三個矩形框，在左邊的框中列出有關(guān)的輸入數(shù)據(jù)，在中間的框內(nèi)列出主要的處理，在右邊的框內(nèi)列出產(chǎn)生的輸出數(shù)據(jù)。處理框中列出處理的次序暗示了執(zhí)行的順序。在IPO圖中還用類似向量符號的粗大箭頭指出數(shù)據(jù)通信的情況。圖2-18是一個主文件更新的例子，通過這個例子不難了解IPO圖的用法。

圖2-18數(shù)據(jù)庫更新記錄的IPO圖

建議使用一種改進(jìn)的IPO圖(也稱為IPO表)，這種圖中包含某些附加的信息，在軟件設(shè)計(jì)過程中將比原始的IPO圖更有用，如圖2-19所示。

圖2-19改進(jìn)的IPO圖的形式及樣例

在需求分析階段可以使用IPO圖簡略地描述系統(tǒng)的主要算法(即數(shù)據(jù)流圖中各個處理的基本算法)。盡管在需求分析階段，IPO圖的許多附加信息暫時還不具備，在軟件設(shè)計(jì)階段可以進(jìn)一步補(bǔ)充修正這些圖，作為設(shè)計(jì)階段的文檔。這正是在需求分析階段用IPO圖作為描述算法工具的重要優(yōu)點(diǎn)。

4．狀態(tài)轉(zhuǎn)換圖

在現(xiàn)實(shí)世界中，大部分事物是動態(tài)變化的，為了反映事物的變化規(guī)律，在需求分析過程中應(yīng)該建立起軟件系統(tǒng)的動態(tài)模型(即行為模型)。狀態(tài)轉(zhuǎn)換圖(簡稱為狀態(tài)圖)通過描繪系統(tǒng)的狀態(tài)及引起系統(tǒng)狀態(tài)轉(zhuǎn)換的事件來表示系統(tǒng)的行為。它反映了系統(tǒng)因?yàn)橥獠康妮斎攵梢粋€狀態(tài)轉(zhuǎn)換到另一個狀態(tài)。狀態(tài)圖提供了行為建模機(jī)制。

狀態(tài)圖既可以表示系統(tǒng)循環(huán)運(yùn)行過程，也可以表示系統(tǒng)單程生命期。當(dāng)描繪循環(huán)運(yùn)行過程時，通常并不關(guān)心循環(huán)是怎樣啟動的。當(dāng)描繪單程生命期時，需要標(biāo)明初始狀態(tài)和最終狀態(tài)。

1)狀態(tài)

狀態(tài)是任何可以被觀察到的系統(tǒng)行為模式，一個狀態(tài)代表系統(tǒng)的一種行為模式。狀態(tài)規(guī)定了系統(tǒng)對事件的響應(yīng)方式。當(dāng)事件發(fā)生時，系統(tǒng)既可以做一個或多個動作，也可以是僅僅改變系統(tǒng)本身的狀態(tài)，還可以既改變狀態(tài)又做動作。在狀態(tài)圖中定義的狀態(tài)主要有：初態(tài)(即系統(tǒng)啟動時進(jìn)入初始狀態(tài))、終態(tài)(即系統(tǒng)運(yùn)行結(jié)束時到達(dá)最終狀態(tài))和中間狀態(tài)。在一張狀態(tài)圖中只能有一個初態(tài)，但可以有零到多個終態(tài)。

2)事件

事件是在某個特定時刻發(fā)生的事情，它是對引起系統(tǒng)從一個狀態(tài)轉(zhuǎn)換到另一個狀態(tài)的外界事件的抽象。例如，內(nèi)部時鐘表明某個規(guī)定的時間段已經(jīng)過去，用戶移動或點(diǎn)擊鼠標(biāo)等都是事件。簡而言之，事件就是引起系統(tǒng)做動作或轉(zhuǎn)換狀態(tài)的控制信息。

3)符號

在狀態(tài)圖中，初態(tài)用實(shí)心圓表示，終態(tài)用一對同心圓(內(nèi)圓為實(shí)心圓)表示。中間狀態(tài)用橢圓或圓角矩形表示，通?？稍诶锩鏄?biāo)上狀態(tài)名稱和該狀態(tài)下要執(zhí)行的動作。狀態(tài)圖中兩個狀態(tài)之間帶箭頭的連線稱為狀態(tài)轉(zhuǎn)換，箭頭指明了轉(zhuǎn)換方向。狀態(tài)變遷通常是由事件觸發(fā)的，應(yīng)在表示狀態(tài)轉(zhuǎn)換的箭頭線上標(biāo)出觸發(fā)轉(zhuǎn)換的事件表達(dá)式(即事件[條件])；如果在箭頭線上未標(biāo)明事件，則表示在源狀態(tài)的內(nèi)部活動執(zhí)行完之后自動觸發(fā)轉(zhuǎn)換。

每個活動可用活動表來表示，活動表的語法格式：事件名(參數(shù)表)/動作表達(dá)式。

活動表中經(jīng)常用下述3種標(biāo)準(zhǔn)事件：

entry事件指定進(jìn)入該狀態(tài)的動作；

exit事件指定退出該狀態(tài)的動作；

do事件則指定在該狀態(tài)下的動作。

需要時可以為事件指定參數(shù)表。活動表中的動作表達(dá)式描述應(yīng)做的具體動作。

狀態(tài)變遷通常是由事件觸發(fā)的，在這種情況下應(yīng)在表示狀態(tài)轉(zhuǎn)換的箭頭線上標(biāo)出觸發(fā)轉(zhuǎn)換的事件表達(dá)式；如果在箭頭線上未標(biāo)明事件，則表示在源狀態(tài)的內(nèi)部活動執(zhí)行完之后自動觸發(fā)轉(zhuǎn)換。狀態(tài)圖使用的主要符號如圖2-20所示。

圖2-20狀態(tài)圖使用的主要符號

4)舉例

為了具體說明怎樣用狀態(tài)圖建立系統(tǒng)的行為模型，下面通過一個數(shù)據(jù)結(jié)構(gòu)“?！睂ο蟮臓顟B(tài)圖來進(jìn)行說明，如圖2-21所示。

圖2-21“?！睂ο蟮臓顟B(tài)轉(zhuǎn)換圖

2.10面向數(shù)據(jù)流的建模

數(shù)據(jù)流圖(DFD)采取了系統(tǒng)的輸入—處理—輸出的觀點(diǎn)，也就是說，流入軟件的數(shù)據(jù)對象經(jīng)過處理變換，最后以結(jié)果數(shù)據(jù)對象的形式流出軟件。數(shù)據(jù)流圖使用分層的方式表示整個系統(tǒng)。

由2.7節(jié)可知，數(shù)據(jù)流圖(DFD)使得軟件工程師可以同時開發(fā)信息域和功能域的模型。當(dāng)DFD被精化到較細(xì)的級別時，分析員對系統(tǒng)進(jìn)行了隱式的功能分解，這樣完成了第四條操作性分析原則。同時，當(dāng)數(shù)據(jù)流過體現(xiàn)應(yīng)用的加工時，DFD的精化導(dǎo)致了數(shù)據(jù)的相應(yīng)精化。

一些簡單的指南在導(dǎo)出數(shù)據(jù)流圖時會有所幫助：(1)第0層的數(shù)據(jù)流圖應(yīng)將軟件/系統(tǒng)描述為一個泡泡；(2)應(yīng)仔細(xì)地標(biāo)記主要的輸入和輸出；(3)通過隔離要表示在下一層中的候選加工、數(shù)據(jù)對象和存儲而開始精化過程；(4)所有的箭頭和泡泡應(yīng)使用有意義的名稱標(biāo)記；(5)當(dāng)從一個級別到另一個級別時要維護(hù)“信息流連續(xù)性”；(6)一次精化一個加工。經(jīng)常存在一種使數(shù)據(jù)流圖過分復(fù)雜的自然趨勢，當(dāng)分析員試圖過早地顯示過多的細(xì)節(jié)或在信息流中表示軟件的過程時，會發(fā)生這種情況。

下面我們以SafeHome安全功能為例來說明。

SafeHome軟件使得房主能夠在安裝時配置安全系統(tǒng)，監(jiān)測所有和安全系統(tǒng)連接的傳感器，通過互聯(lián)網(wǎng)、個人計(jì)算機(jī)或控制面板和房主進(jìn)行交互活動。

在安裝過程中，SafeHome使用個人計(jì)算機(jī)設(shè)計(jì)和配置系統(tǒng)，每個傳感器被分配一個編號和類型，用主密碼控制啟動和關(guān)閉系統(tǒng)，當(dāng)傳感器事件發(fā)生時將輸入電話號碼并撥號。

當(dāng)某傳感器事件被識別出時，軟件激活一個附于系統(tǒng)上的可發(fā)聲的警報(bào)，在一定的延遲時間后(由房主在系統(tǒng)配置活動中指定)，軟件撥出監(jiān)控服務(wù)的電話號碼，并報(bào)告關(guān)于位置和被檢測到的事件的性質(zhì)等信息，電話號碼將每20秒重?fù)芤淮危敝岭娫捊油ā?/p>

和SafeHome的所有交互由用戶交互子系統(tǒng)管理，該子系統(tǒng)讀入通過鍵盤和功能鍵提供的輸入，接口在控制面板、個人計(jì)算機(jī)或?yàn)g覽器窗口顯示提示信息和系統(tǒng)狀況。

圖2-22顯示了系統(tǒng)第0層的DFD。主要的外部實(shí)體產(chǎn)生了系統(tǒng)所使用的信息及系統(tǒng)產(chǎn)生的消費(fèi)信息，帶標(biāo)記的箭頭代