【正文】 字典中作為一個(gè)詞條加以定義，使得每一個(gè)圖形元素的名字都有一個(gè)確切的解釋。內(nèi)容?數(shù)據(jù)流?數(shù)據(jù)流分量?數(shù)據(jù)存儲(chǔ)?處理（一般不用DD描述）定義數(shù)據(jù)的方法?自頂向下分解數(shù)據(jù)數(shù)據(jù)字典屮的基木符號(hào)及其含義(2)數(shù)醉典巾的條目及說(shuō)明數(shù)據(jù)字典是關(guān)于數(shù)據(jù)流圖中各種成分詳細(xì)定義的信息集合，可將其按照說(shuō)明對(duì)象的類(lèi)型劃分為四類(lèi)條目，分別為數(shù)據(jù)流條目、數(shù)據(jù)項(xiàng)條目、數(shù)據(jù)文件條目和數(shù)據(jù)加工條目。數(shù)據(jù)字典DD數(shù)據(jù)字典的提出背景：?雖然分層數(shù)據(jù)流圖能夠形象、清晰地描述數(shù)據(jù)在系統(tǒng)中流動(dòng)、加工、存儲(chǔ)的情況，但僅依靠名稱(chēng)并不能反映其本質(zhì)含義，作為對(duì)數(shù)據(jù)流圖的補(bǔ)充，數(shù)據(jù)字典(DD，Data Dictionary)能夠準(zhǔn)確地定義數(shù)據(jù)流圖中各組成成分的具體含義，二者共同構(gòu)成了系統(tǒng)的邏輯模型。改進(jìn)分解的均勻性。?⑵改進(jìn)DFD圖的易理解性簡(jiǎn)化加工之間的聯(lián)系(加工間的數(shù)據(jù)流越少，獨(dú)立性越強(qiáng)，易理解性越好）。分層DFD圖的改進(jìn)改進(jìn)的原則與畫(huà)分層DFD圖的基本原則是一致的，可從以下方面考慮DFD圖的改進(jìn)：?⑴檢查數(shù)據(jù)流的正確性數(shù)據(jù)守恒子圖、父圖的平衡文件使用是否合理。通常一個(gè)加工每次可分解為2?4個(gè)子加工，最多不要超過(guò)七個(gè)，因?yàn)檫^(guò)快的分解會(huì)增加用戶(hù)對(duì)系統(tǒng)模型理解的難度。(6)數(shù)據(jù)流圖只能由四種基本符號(hào)組成，是實(shí)際業(yè)務(wù)流程的客觀映象，用于說(shuō)明系統(tǒng)應(yīng)該“做什么”，而不需要指明系統(tǒng)“如何做”。(4)在數(shù)據(jù)流圖中，應(yīng)按照層次給每個(gè)加工編號(hào)，用于表明該加工所處的層次及上、下層的父圖與子圖的關(guān)系。(3)對(duì)數(shù)據(jù)流圖中某個(gè)加工進(jìn)行細(xì)化生成的下層數(shù)據(jù)流圖，稱(chēng)為其上層圖的子圖。(3)建立數(shù)據(jù)流模型的原則建立數(shù)據(jù)流模型要遵循以下的原則:(1)每個(gè)加工至少應(yīng)有一個(gè)輸入數(shù)據(jù)流(反映被處理數(shù)據(jù)的來(lái)源)和一個(gè)輸出數(shù)據(jù)流(反映加工的結(jié)果）。?(3)畫(huà)出底層的DFD圖。每分解一次，系統(tǒng)中加工的數(shù)量就隨之增加，每個(gè)加工的功能描述也越來(lái)越具體。按照結(jié)構(gòu)化分析方法中“自頂向下，逐步分解”的思想，可以先將整個(gè)系統(tǒng)看作是一個(gè)加工，它的輸入數(shù)據(jù)和輸出數(shù)據(jù)表明了系統(tǒng)和外部環(huán)境的接口，從而首先畫(huà)出系統(tǒng)的頂層數(shù)據(jù)流圖?⑵逐層分解頂層DFD圖，獲得若干屮間層DFD圖。畫(huà)各層DFD圖時(shí)，應(yīng)“由外向內(nèi)”。在頂層和底層之間的是屮間層。頂層圖說(shuō)明了系統(tǒng)的邊界，即系統(tǒng)的輸入和輸出數(shù)據(jù)流，頂層圖只有一張。為了降低系統(tǒng)的復(fù)雜性，采取“逐層分解”的技術(shù)，畫(huà)分層的DFD圖。(2)數(shù)據(jù)流圖的細(xì)化■分層理由?下圖是培訓(xùn)中心管理系統(tǒng)的數(shù)據(jù)流圖，由于只有一層，因此分解的加工較多不易理解，而且如果其中某個(gè)加工較復(fù)雜，影響需求分析結(jié)果的可讀性。?數(shù)據(jù)流圖是從數(shù)據(jù)的角度來(lái)描述一個(gè)系統(tǒng)，而框圖則是從對(duì)數(shù)據(jù)進(jìn)行加工的工作人員的角度來(lái)描述系統(tǒng)。一般只出現(xiàn)在數(shù)據(jù)流圖的頂層圖屮。?流向數(shù)據(jù)存儲(chǔ)的數(shù)據(jù)流可理解為寫(xiě)入文件，或查詢(xún)文件，從數(shù)據(jù)存儲(chǔ)流出的數(shù)據(jù)可理解為從文件讀數(shù)據(jù)或得到查詢(xún)結(jié)果。在分層的數(shù)據(jù)流圖屮，加工還應(yīng)有編號(hào)。■⑵加工 ?也稱(chēng)為數(shù)據(jù)處理，它對(duì)數(shù)據(jù)流進(jìn)行某些操作或變換。?數(shù)據(jù)流可以從加工流向加工，也可以從加工流向文件或從文件流向加工，也可以從源點(diǎn)流向加工或從加工流向終點(diǎn)。數(shù)據(jù)流圖DFD數(shù)據(jù)流圖數(shù)據(jù)流圖(Data Flow Diagram,簡(jiǎn)稱(chēng)DFD)是描述系統(tǒng)屮數(shù)據(jù)流程的圖形工具，它標(biāo)識(shí)了一個(gè)系統(tǒng)的邏輯輸入和邏輯輸出，以及把邏輯輸入轉(zhuǎn)換成邏輯輸出所需的加工處理。?分析系統(tǒng)的“物理模型”，抽象出其本質(zhì)的因素，排除次要因素，獲得用DFD圖描述的當(dāng)前系統(tǒng)的“邏輯模型⑶建立目標(biāo)系統(tǒng)的邏輯模型。這樣的表達(dá)與當(dāng)前系統(tǒng)完全對(duì)應(yīng)，因此用戶(hù)容易理解。自頂向下逐甚分解如圖所示，頂層抽象地描述了整個(gè)系統(tǒng)，底層具體地畫(huà)出了系統(tǒng)的每一個(gè)細(xì)節(jié)，而中間層是從抽象到具體的逐層過(guò)渡。?主要應(yīng)用技術(shù)和工具：數(shù)據(jù)流圖（DFD)；數(shù)據(jù)字典（DD)；加工說(shuō)明(PESPEC)；實(shí)體關(guān)系圖(ER)；狀態(tài)變遷圖（STD)等?數(shù)據(jù)流圖（DPD)數(shù)據(jù)字典加工說(shuō)明參 結(jié)構(gòu)化語(yǔ)言參 判定表參 判斷樹(shù)?主要應(yīng)用技術(shù)和工具:數(shù)據(jù)流圖（DFD)；數(shù)據(jù)字典（DD)；加工說(shuō)明(PESPEC)；實(shí)體關(guān)系圖(ER)；狀態(tài)變遷圖（STD)等SA法的基本思想■結(jié)構(gòu)化分析的基本思想：“分解”和u抽象”■分解：把系統(tǒng)的復(fù)雜性降低到可以掌握的程度，把大問(wèn)題分解成若干小問(wèn)題，然后分別解決。結(jié)構(gòu)化分析方法?結(jié)構(gòu)化分析方法(Structured Analysis,簡(jiǎn)稱(chēng)SA法)是面向數(shù)據(jù)流的需求分析方法，是70年代末辦Pbwrcfoc Cons taint ine及DeMarco箏乂提出和發(fā)展，并得到廣泛的應(yīng)用。它主要借助于分層數(shù)據(jù)流圖和數(shù)據(jù)字典等圖形及半形式化的工具表達(dá)系統(tǒng)的需求。結(jié)構(gòu)化開(kāi)發(fā)方法包含三部分：?結(jié)構(gòu)化分析方法(SA法）?結(jié)構(gòu)化設(shè)計(jì)方法(SD法）?結(jié)構(gòu)化程序設(shè)計(jì)方法(SP法)SA法建模就是用抽象模型的概念，按照軟件內(nèi)部數(shù)據(jù)傳遞、變換的關(guān)系，自頂向下逐層分解,直到找到滿足功能要求的所有可實(shí)現(xiàn)的軟件模型為止。?第三步:評(píng)價(jià)對(duì)工期的影響?第四步:評(píng)價(jià)對(duì)成本的影響?第五步:評(píng)價(jià)對(duì)質(zhì)量的影響?第六步:風(fēng)險(xiǎn)評(píng)價(jià)?第七步:變更決策七步法印證了我經(jīng)常鼓吹的項(xiàng)目管理三部曲:細(xì)化、量化、圖形化，七步法主要驗(yàn)證了細(xì)化和量化的必要性和好處。需求變更決策七步法需求變更決策過(guò)程可分為七步：?第一步:變更申請(qǐng)。?每個(gè)階段結(jié)束后，是不是要將整個(gè)項(xiàng)目的文檔做一個(gè)快照呢？通常是需要的，那此時(shí)的項(xiàng)目基線也就是我們這里說(shuō)的需求體系的版木。.需求體系的版本今天，越來(lái)越多的公司采用迭代或增量開(kāi)發(fā)模式。? 一種簡(jiǎn)單的版木控制形式，例如，賦給圖的初版二個(gè)版本等級(jí)“A”。雖然需求變更的表現(xiàn)形式千差萬(wàn)別，但究其根本不外乎以下幾種原因：? (1)、范圍沒(méi)有圈定就開(kāi)始細(xì)化? (2)、沒(méi)存指定需求的基線? (3)、沒(méi)存良好的軟件結(jié)構(gòu)適應(yīng)變化版本控制版本控制透過(guò)文檔控制（documentation control)記錄程序各個(gè)模組的改動(dòng)，并為每次改動(dòng)編上序號(hào)。需求移交的目的：(1)形成甲乙雙方的工程實(shí)施技術(shù)合同(2)確定了施工團(tuán)隊(duì)的施工方案、依據(jù)(3)達(dá)成了多方公認(rèn)的驗(yàn)收依據(jù)、標(biāo)準(zhǔn)需求管理11變更控制版本控制需求跟蹤需求狀態(tài)跟蹤?建議變更?確定需求文?定義對(duì)其它?定義需求狀?分析影響檔的版本需求的鏈接態(tài)?作出決策?確定需求條?定義對(duì)其它?跟蹤需求的?交流目的版本系統(tǒng)元素的每一個(gè)狀態(tài)?合并?確定需求體接鏈?測(cè)量需求的系的版本?需求文檔跟穩(wěn)定性蹤變更控制需求變更的表現(xiàn)形式是多方面的，如老板臨時(shí)改變想法、項(xiàng)目預(yù)算增加或減少、客戶(hù)對(duì)功能的需求改變等。? 3)用戶(hù)審查法分析人員可以把《用例需求說(shuō)明書(shū)》提交給用戶(hù)，有條件時(shí)可以同時(shí)編寫(xiě)一份針對(duì)此需求的《用戶(hù)使用說(shuō)明書(shū)》并提交給用戶(hù)，用戶(hù)找出不滿意或認(rèn)為不能實(shí)現(xiàn)的需求，雙方再對(duì)這些有爭(zhēng)議的需求進(jìn)行討論，最后達(dá)成一致認(rèn)識(shí)。第一種是小組審查法，即由一名分析人員向開(kāi)發(fā)小組中其他人員介紹用例需求,小組中的成員進(jìn)行提問(wèn)，由介紹人進(jìn)行解答。? 1)自查法自查法由需求分析人員對(duì)自己所確定的用例需求進(jìn)行審核和驗(yàn)證，糾正需求中存在的問(wèn)題。軟件需求規(guī)約的一種典型格式1引言、同義詞與縮寫(xiě)2 一般性描述23用戶(hù)特征《軟件需求規(guī)約》模板3特殊需求■為需求 引言 輸入 輸出■為需求2軟件(產(chǎn)品）需求說(shuō)明書(shū)/. /項(xiàng)目筒介12編寫(xiě)說(shuō)明!. 3參考資料2. 1概述2. 2此務(wù)標(biāo)2. 2. ； , B標(biāo)2. 2. 2此務(wù)標(biāo)2. 2. 3羅制性因案3. /較件包結(jié)構(gòu)圖 ；概述4,3用例規(guī)約分析說(shuō)明5軟件功能限制因素5.；概迷6. !軟件S餘的主要風(fēng)竣6. 2風(fēng)殮的處理策評(píng)審——同行或?qū)＜以u(píng)審確認(rèn)需求規(guī)格說(shuō)明書(shū)需求評(píng)審目的是要確保需求能夠反映用戶(hù)的意愿?評(píng)審人員評(píng)審時(shí)往往需要檢查以下內(nèi)容：；；文檔中的描述是否完整、清晰、準(zhǔn)確地反映了用戶(hù)要求；；，是否都己充分說(shuō)明；；；，它們能否對(duì)系統(tǒng)定義是否成功進(jìn)行確認(rèn)。它所包括的信息必須局部化，這樣當(dāng)信息被修改時(shí)，只要修改某個(gè)單個(gè)的段落（理想情況）。(7).規(guī)約必須允許不完備性并允許擴(kuò)充。⑶.規(guī)約必須是一個(gè)認(rèn)識(shí)模型，而不是設(shè)計(jì)或?qū)崿F(xiàn)的模型。(3).如果被開(kāi)發(fā)軟件系統(tǒng)規(guī)模很小，那么整個(gè)系統(tǒng)也包括在規(guī)格說(shuō)明的描述之中。需求規(guī)約遵循如下原則：⑴.從現(xiàn)實(shí)中分離功能，即描述要“做什么”而不是“怎樣實(shí)現(xiàn)”。一個(gè)條件列表，如果其中包含條件，則這些條件將在用例成功完成以后得到滿足。一個(gè)條件列表，如果其中包含條件，則這些條件必須在訪問(wèn)用例之if得到滿足。這是一個(gè)自由式問(wèn)題，如用戶(hù)每次錄訪問(wèn)一次戒每月一次。頻手。狀態(tài)、[可選]。與此用例相關(guān)的參與者列表。概述用例的幾句話。唯一標(biāo)識(shí)符，如UC1701，在項(xiàng)目的其他元素（如類(lèi)模型）中可用它表引用這個(gè)用例。名稱(chēng)無(wú)疑應(yīng)該表明用戶(hù)的意圖或用例的用途，如“研究班招生”。（說(shuō)明文本格式目前尚未統(tǒng)一，下表僅供參考。用例說(shuō)明■用例說(shuō)明（UseCase Explanation)是對(duì)功能用例圖中的用例做出的說(shuō)明。在需求階段，數(shù)據(jù)字典至少應(yīng)定義客戶(hù)數(shù)據(jù)項(xiàng)以確?？蛻?hù)與開(kāi)發(fā)小組是使用一致的定義和術(shù)語(yǔ)。必須有的基本需求期望需求，即客戶(hù)或許并未提及，但如若缺少會(huì)讓他們感到不滿意；興奮需求，即實(shí)現(xiàn)了會(huì)給客戶(hù)帶去驚喜，但若未實(shí)現(xiàn)也不會(huì)受到責(zé)備。?該技術(shù)提供了一種分析方法以明確那些是客戶(hù)最為關(guān)注的特性。?描述： 關(guān)于對(duì)象的文字描述。 {destroyed}說(shuō)明對(duì)象在交互期間被刪除。?限制類(lèi)型：可供選擇的類(lèi)型有：None ： 對(duì)對(duì)象不做限制。?類(lèi)名：對(duì)象所屬的類(lèi)的名稱(chēng)。協(xié)作圖中的對(duì)象屬性定義?對(duì)象名稱(chēng)：在可視化表示屮所用的對(duì)象的名字。這些動(dòng)態(tài)方面可能涉及一個(gè)系統(tǒng)的體系結(jié)構(gòu)的任意視圖中的任何種類(lèi)的實(shí)例的交互，包括類(lèi)(含主動(dòng)類(lèi)）、接口、構(gòu)件和節(jié)點(diǎn)的實(shí)例的交互。它們可以從一種形式的圖轉(zhuǎn)換為另一種形式的圖，而不丟失任何伯息。協(xié)作圖協(xié)作圖強(qiáng)調(diào)參加交互的對(duì)象的組織?？梢杂靡粋€(gè)或多個(gè)順序圖來(lái)闡明實(shí)現(xiàn)用例的對(duì)象交互過(guò)程。?應(yīng)用質(zhì)量功能調(diào)配將產(chǎn)品特性、屬性與對(duì)客戶(hù)的重要性聯(lián)系起來(lái)。備速洗的描14格式可以與基木洗的格式一玫，也需要編號(hào)并以標(biāo)題概連其A東，編號(hào)前可以加以孝母前敬A (Alternative)以示與基木洗步腺相區(qū)別。事件流：備選流備迷洗負(fù)責(zé)描遂用例執(zhí)行過(guò)程中弄常的或偶糸發(fā)生的一些情況，備速洗和基本洗的組合應(yīng)該能夠棗蓋該用例所有可能發(fā)生的場(chǎng)景。建議采用雙向（roundtrip)描述法來(lái)保證描述的完整性，即每一步驟都需要從正反兩個(gè)方面來(lái)描述： (1)參與者向系統(tǒng)提交了什么信息；(2)對(duì)此系統(tǒng)有什么樣的響應(yīng)。彺用例建模的早期，我們圯只需耍描逑到事件流步驟標(biāo)邐這一層，以免迓早杷陷入到用例描逑的細(xì)節(jié)中去。成們建說(shuō)用以下格式來(lái)描連基本洗：?1)每一個(gè)步驟都需要用數(shù)字編呈以清楚地標(biāo)明步驟的先后順序。?后置條件(PostCondition)用例執(zhí)行完畢后系統(tǒng)可能處于的一組狀態(tài)。?特殊需求(Special Requirement)描述與該用例相關(guān)的非功能性需求（包括性能、可靠性、可用性和可擴(kuò)展性等）和設(shè)計(jì)約束（所使用的操作系統(tǒng)、開(kāi)發(fā)工具等）。?事件流(Flow of Event)包括基本流和備選流，事件流應(yīng)該表示出所有的場(chǎng)景。（也是一種泛化（繼承）關(guān)聯(lián)、也稱(chēng)包含關(guān)聯(lián)）擴(kuò)展關(guān)聯(lián)?通過(guò)對(duì)已有用例增加一些額外的步驟來(lái)建立新的用例。參與關(guān)聯(lián)?描述角色和用例之間有信息交流或系統(tǒng)為誰(shuí)提供哪些功能與服務(wù)。用例用于表示系統(tǒng)所提供的服務(wù)，它定義了系統(tǒng)是如何被參與者所使用的，它描述的是參與者為了使用系統(tǒng)所提供的某一完整功能而與系統(tǒng)之間發(fā)生的一段對(duì)話。在一個(gè)用例圖中，有一個(gè)或多個(gè)參與者與一個(gè)或多個(gè)用例相互關(guān)聯(lián)。■用例的厭用在^p中鈹推崇備至：?鼙個(gè)足程鄄絞秫飽慝用例驅(qū)勱” (VseCaseDriven)$^?各神券型的訐亥話勁窆括項(xiàng)目管理、分柝埂計(jì)、測(cè)芪、賓現(xiàn)等鄠夏以系:統(tǒng)用閔竅歪耍褕入工T牛?用例鏌型黧定了鼙個(gè)系統(tǒng)5U牛開(kāi)茨：的基礎(chǔ)。建立用例模型1用例的泠法來(lái)描遠(yuǎn)系統(tǒng)的功能需求的遠(yuǎn)程就是用例建棋，用例棋型立要包招以下兩部分內(nèi)東：?用例圖(Use Case Diagram)確定系統(tǒng)屮所包含的參與者、用例和兩者之間的對(duì)應(yīng)關(guān)系，用例圖描述的是關(guān)于系統(tǒng)功能的一個(gè)概述。?用例圖描述用例建模的結(jié)果。?軟件目標(biāo)是用例建模的依據(jù)。?從用產(chǎn)的角度釆看’他們笄不想了解系統(tǒng)的閃部結(jié)構(gòu)和設(shè)計(jì)，他們所哭心的是系：統(tǒng)所能提偌的服務(wù),圯就慝衹開(kāi)芡幽來(lái)的系：統(tǒng)將慝忉何衹丨更用的,這就用彳列方法的基不慝想。?(在后續(xù)章節(jié)詳細(xì)講述，此處省略)RUP細(xì)化：用例建模用例(Use Case)是一種描述系統(tǒng)需求的方法，使用用例的方法來(lái)描述系統(tǒng)需求的過(guò)程就是用例建模。?它們能提供不同的信息與關(guān)系以宥助于找到不正確的、不一致的、遺漏的和冗