【文章內(nèi)容簡介】 關(guān)的參與者列表。盡管這則信息包含在用例本身中，但在沒有用例圖時(shí)，它有助于增加對該用例的理解。狀態(tài)、[可選]。指示、用例的狀態(tài)，通常為以下幾種之一：進(jìn)行中、等待審查、通過華i或菜通過帝查。頻手。參與者訪A7此用例的頻率。這是一個(gè)自由式問題，如用戶每次錄訪問一次戒每月一次。前置條件。一個(gè)條件列表，如果其中包含條件，則這些條件必須在訪問用例之if得到滿足。后置條件。一個(gè)條件列表，如果其中包含條件，則這些條件將在用例成功完成以后得到滿足。需求規(guī)約軟件需求規(guī)約是分析任務(wù)的最終產(chǎn)物，通過建立完整的信息描述、詳細(xì)的功能和行為描述、性能需求和設(shè)計(jì)約束的說明、合適的驗(yàn)收標(biāo)準(zhǔn)，給出對目標(biāo)軟件的各種需求。需求規(guī)約遵循如下原則：⑴.從現(xiàn)實(shí)中分離功能，即描述要“做什么”而不是“怎樣實(shí)現(xiàn)”。(2).要求使用面向處理的規(guī)約語言，討論來自環(huán)境的各種剌激可能導(dǎo)致系統(tǒng)做出什么樣的功能性反應(yīng)，來定義一個(gè)行為模型，從而得到“做什么”的規(guī)約。(3).如果被開發(fā)軟件系統(tǒng)規(guī)模很小，那么整個(gè)系統(tǒng)也包括在規(guī)格說明的描述之中。⑷.規(guī)約必須包括系統(tǒng)運(yùn)行環(huán)境。⑶.規(guī)約必須是一個(gè)認(rèn)識(shí)模型，而不是設(shè)計(jì)或?qū)崿F(xiàn)的模型。(6).規(guī)約必須是可操作的，以便能夠利用它決定對于任意給定的測試用例，巳提出的解決方案是否都能滿足規(guī)約。(7).規(guī)約必須允許不完備性并允許擴(kuò)充。⑶.規(guī)約必須局部化和松散耦合。它所包括的信息必須局部化，這樣當(dāng)信息被修改時(shí)，只要修改某個(gè)單個(gè)的段落（理想情況）。同時(shí)，規(guī)約應(yīng)被松散地構(gòu)造，以便能夠很容易地加入和刪去一些段落。軟件需求規(guī)約的一種典型格式1引言、同義詞與縮寫2 一般性描述23用戶特征《軟件需求規(guī)約》模板3特殊需求■為需求 引言 輸入 輸出■為需求2軟件(產(chǎn)品）需求說明書/. /項(xiàng)目筒介12編寫說明!. 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ī)約分析說明5軟件功能限制因素5.；概迷6. !軟件S餘的主要風(fēng)竣6. 2風(fēng)殮的處理策評(píng)審——同行或?qū)＜以u(píng)審確認(rèn)需求規(guī)格說明書需求評(píng)審目的是要確保需求能夠反映用戶的意愿?評(píng)審人員評(píng)審時(shí)往往需要檢查以下內(nèi)容：；；文檔中的描述是否完整、清晰、準(zhǔn)確地反映了用戶要求；；，是否都己充分說明；；；，它們能否對系統(tǒng)定義是否成功進(jìn)行確認(rèn)。^ 需求驗(yàn)證的方法幾種需求驗(yàn)證的基本萬法。? 1)自查法自查法由需求分析人員對自己所確定的用例需求進(jìn)行審核和驗(yàn)證，糾正需求中存在的問題。自查法又可以分為多種具體方法。第一種是小組審查法，即由一名分析人員向開發(fā)小組中其他人員介紹用例需求,小組中的成員進(jìn)行提問，由介紹人進(jìn)行解答。? 2)專家審查法專家審查法是指聘請業(yè)務(wù)領(lǐng)域、用例、政策、法律等方面的專家對用例需求進(jìn)行審查。? 3)用戶審查法分析人員可以把《用例需求說明書》提交給用戶，有條件時(shí)可以同時(shí)編寫一份針對此需求的《用戶使用說明書》并提交給用戶，用戶找出不滿意或認(rèn)為不能實(shí)現(xiàn)的需求，雙方再對這些有爭議的需求進(jìn)行討論，最后達(dá)成一致認(rèn)識(shí)。? 4)原型法原型法是對存在的有爭議或拿不準(zhǔn)的需求，通過建立原型進(jìn)行驗(yàn)證，以確定需求的正確性。需求移交的目的：(1)形成甲乙雙方的工程實(shí)施技術(shù)合同(2)確定了施工團(tuán)隊(duì)的施工方案、依據(jù)(3)達(dá)成了多方公認(rèn)的驗(yàn)收依據(jù)、標(biāo)準(zhǔn)需求管理11變更控制版本控制需求跟蹤需求狀態(tài)跟蹤?建議變更?確定需求文?定義對其它?定義需求狀?分析影響檔的版本需求的鏈接態(tài)?作出決策?確定需求條?定義對其它?跟蹤需求的?交流目的版本系統(tǒng)元素的每一個(gè)狀態(tài)?合并?確定需求體接鏈?測量需求的系的版本?需求文檔跟穩(wěn)定性蹤變更控制需求變更的表現(xiàn)形式是多方面的，如老板臨時(shí)改變想法、項(xiàng)目預(yù)算增加或減少、客戶對功能的需求改變等。在IT項(xiàng)目中，變更可能來自方案服務(wù)商、客戶或產(chǎn)品供應(yīng)商等，也可能來源于項(xiàng)目組內(nèi)部。雖然需求變更的表現(xiàn)形式千差萬別，但究其根本不外乎以下幾種原因：? (1)、范圍沒有圈定就開始細(xì)化? (2)、沒存指定需求的基線? (3)、沒存良好的軟件結(jié)構(gòu)適應(yīng)變化版本控制版本控制透過文檔控制（documentation control)記錄程序各個(gè)模組的改動(dòng)，并為每次改動(dòng)編上序號(hào)。?這種方法是工程圖（engineering drawings)維護(hù)(maintenance)的標(biāo)準(zhǔn)做法，它伴隨著工程圖從圖的誕生一直到圖的定型。? 一種簡單的版木控制形式，例如，賦給圖的初版二個(gè)版本等級(jí)“A”。當(dāng)做了第一次改變后，版木等級(jí)改為“B”，以此類推等等。.需求體系的版本今天，越來越多的公司采用迭代或增量開發(fā)模式。為了降低風(fēng)險(xiǎn)，將開發(fā)過程分為多個(gè)增量部分可以加快整個(gè)開發(fā)過程。?每個(gè)階段結(jié)束后，是不是要將整個(gè)項(xiàng)目的文檔做一個(gè)快照呢？通常是需要的，那此時(shí)的項(xiàng)目基線也就是我們這里說的需求體系的版木。?需求體系的版木包含自需求而來的多個(gè)相關(guān)文檔，此時(shí)的版本管理不僅應(yīng)將這些文檔打上統(tǒng)一的基線，并且將該組文檔之間的追蹤關(guān)系也進(jìn)行基線化的管理。需求變更決策七步法需求變更決策過程可分為七步：?第一步:變更申請。?第二步:技術(shù)評(píng)審。?第三步:評(píng)價(jià)對工期的影響?第四步:評(píng)價(jià)對成本的影響?第五步:評(píng)價(jià)對質(zhì)量的影響?第六步:風(fēng)險(xiǎn)評(píng)價(jià)?第七步:變更決策七步法印證了我經(jīng)常鼓吹的項(xiàng)目管理三部曲:細(xì)化、量化、圖形化，七步法主要驗(yàn)證了細(xì)化和量化的必要性和好處。第三講結(jié)構(gòu)化分析方法(DFD、 DD、 PESPEC)結(jié)構(gòu)化開發(fā)方法是現(xiàn)有的軟件開發(fā)方法中最成熟，應(yīng)用最廣泛的方法，主要特點(diǎn)是快速、自然和方便。結(jié)構(gòu)化開發(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)的軟件模型為止。■結(jié)構(gòu)化分析方法是傳統(tǒng)軟件工程中公認(rèn)的技術(shù)成熟和使用廣泛的需求分析方法。它主要借助于分層數(shù)據(jù)流圖和數(shù)據(jù)字典等圖形及半形式化的工具表達(dá)系統(tǒng)的需求。—?結(jié)構(gòu)化分析方法是面向數(shù)據(jù)流進(jìn)行需求分析的方法，適合于數(shù)據(jù)處理類型軟件的需表分析。結(jié)構(gòu)化分析方法?結(jié)構(gòu)化分析方法(Structured Analysis,簡稱SA法)是面向數(shù)據(jù)流的需求分析方法，是70年代末辦Pbwrcfoc Cons taint ine及DeMarco箏乂提出和發(fā)展，并得到廣泛的應(yīng)用。它適合于分析A：型的數(shù)椐處理系統(tǒng)，特別是企事業(yè)管理系統(tǒng)。?主要應(yīng)用技術(shù)和工具：數(shù)據(jù)流圖（DFD)；數(shù)據(jù)字典（DD)；加工說明(PESPEC)；實(shí)體關(guān)系圖(ER)；狀態(tài)變遷圖（STD)等?數(shù)據(jù)流圖（DPD)數(shù)據(jù)字典加工說明參 結(jié)構(gòu)化語言參 判定表參 判斷樹?主要應(yīng)用技術(shù)和工具:數(shù)據(jù)流圖（DFD)；數(shù)據(jù)字典（DD)；加工說明(PESPEC)；實(shí)體關(guān)系圖(ER)；狀態(tài)變遷圖（STD)等SA法的基本思想■結(jié)構(gòu)化分析的基本思想：“分解”和u抽象”■分解：把系統(tǒng)的復(fù)雜性降低到可以掌握的程度，把大問題分解成若干小問題，然后分別解決?！龀橄螅杭聪瓤紤]問題最本質(zhì)的屬性，暫把細(xì)節(jié)略去，以后再逐層添加細(xì)節(jié)，直至涉及到最詳細(xì)的內(nèi)容。自頂向下逐甚分解如圖所示，頂層抽象地描述了整個(gè)系統(tǒng)，底層具體地畫出了系統(tǒng)的每一個(gè)細(xì)節(jié)，而中間層是從抽象到具體的逐層過渡。⑴建立當(dāng)前系統(tǒng)的“物理模型”?系統(tǒng)的“物理模型”就是現(xiàn)實(shí)環(huán)境的忠實(shí)寫照，即將當(dāng)前系統(tǒng)用DFD圖描述出來。這樣的表達(dá)與當(dāng)前系統(tǒng)完全對應(yīng)，因此用戶容易理解。⑵抽象出當(dāng)前系統(tǒng)的邏輯模型。?分析系統(tǒng)的“物理模型”，抽象出其本質(zhì)的因素，排除次要因素，獲得用DFD圖描述的當(dāng)前系統(tǒng)的“邏輯模型⑶建立目標(biāo)系統(tǒng)的邏輯模型。?分析目標(biāo)系統(tǒng)與當(dāng)前系統(tǒng)邏輯上的差別，從而進(jìn)一步明確目標(biāo)系統(tǒng)“做什么”，建立目稱系統(tǒng)的“邏輯模型”⑷為了對目標(biāo)系統(tǒng)作完整的描述，還需要考慮人機(jī)界面和其它一些問題。數(shù)據(jù)流圖DFD數(shù)據(jù)流圖數(shù)據(jù)流圖(Data Flow Diagram,簡稱DFD)是描述系統(tǒng)屮數(shù)據(jù)流程的圖形工具，它標(biāo)識(shí)了一個(gè)系統(tǒng)的邏輯輸入和邏輯輸出，以及把邏輯輸入轉(zhuǎn)換成邏輯輸出所需的加工處理?！?DFD描述系統(tǒng)選輯模型?信息在系統(tǒng)中的流動(dòng)和處理■ DFD用途?交流信息的工具?結(jié)構(gòu)化分析和設(shè)計(jì)的工具(1)數(shù)據(jù)流圖（DFD)圖形符號(hào)輔助的圖形符號(hào)DFD基本繪圖符號(hào)說明⑴數(shù)據(jù)流 ?是數(shù)據(jù)在系統(tǒng)內(nèi)傳播的路徑，由一組成固定的數(shù)據(jù)項(xiàng)組成。?數(shù)據(jù)流可以從加工流向加工，也可以從加工流向文件或從文件流向加工，也可以從源點(diǎn)流向加工或從加工流向終點(diǎn)。?除了與數(shù)據(jù)存儲(chǔ)(文件)之間的數(shù)據(jù)流不用命名外，其余數(shù)據(jù)流都應(yīng)該用名詞或名詞短語命名?！觫萍庸??也稱為數(shù)據(jù)處理，它對數(shù)據(jù)流進(jìn)行某些操作或變換。每個(gè)加工也要存名字，通常是動(dòng)詞短語，簡明地描述完成什么加I:。在分層的數(shù)據(jù)流圖屮，加工還應(yīng)有編號(hào)。(3)數(shù)據(jù)存儲(chǔ)?指暫時(shí)保存的數(shù)據(jù)，它可以是數(shù)據(jù)庫文件或任何形式的數(shù)據(jù)組織。?流向數(shù)據(jù)存儲(chǔ)的數(shù)據(jù)流可理解為寫入文件，或查詢文件，從數(shù)據(jù)存儲(chǔ)流出的數(shù)據(jù)可理解為從文件讀數(shù)據(jù)或得到查詢結(jié)果。■⑷數(shù)據(jù)源點(diǎn)和終點(diǎn)?是軟件系統(tǒng)外部環(huán)境屮的實(shí)體(包括人員、組織或其他軟件系統(tǒng)），統(tǒng)稱為外部實(shí)體。一般只出現(xiàn)在數(shù)據(jù)流圖的頂層圖屮。注意事項(xiàng)特別要注意的是：?數(shù)據(jù)流圖不是傳統(tǒng)的流程圖或框圖，數(shù)據(jù)流也不是控制流。?數(shù)據(jù)流圖是從數(shù)據(jù)的角度來描述一個(gè)系統(tǒng)，而框圖則是從對數(shù)據(jù)進(jìn)行加工的工作人員的角度來描述系統(tǒng)。?數(shù)據(jù)流圖中的箭頭是數(shù)據(jù)流，而框圖中的箭頭則是控制流，控制流表達(dá)的是程序執(zhí)行的次序。(2)數(shù)據(jù)流圖的細(xì)化■分層理由?下圖是培訓(xùn)中心管理系統(tǒng)的數(shù)據(jù)流圖，由于只有一層，因此分解的加工較多不易理解，而且如果其中某個(gè)加工較復(fù)雜，影響需求分析結(jié)果的可讀性。 數(shù)據(jù)流圖分層分層理由?如果系統(tǒng)規(guī)模較大，僅用一個(gè)DFD圖難以描述，會(huì)使得系統(tǒng)變得復(fù)雜，且難以理解。為了降低系統(tǒng)的復(fù)雜性，采取“逐層分解”的技術(shù)，畫分層的DFD圖。分層DFD酬“分解”與“抽象”I “先全局后局部，先整體后細(xì)節(jié)，先抽象后具體”?通常將這種分層的DFD圖，分為頂層、中間層、底層。頂層圖說明了系統(tǒng)的邊界，即系統(tǒng)的輸入和輸出數(shù)據(jù)流，頂層圖只有一張。底層圖由一些不能再分解的加工組成，這些加工都已足夠簡單，稱為基本加工。在頂層和底層之間的是屮間層。屮間層的數(shù)據(jù)流圖描述了某個(gè)加工的分解，而它的組成部分又要進(jìn)一步分解。畫各層DFD圖時(shí)，應(yīng)“由外向內(nèi)”。畫分層DFD圖的具體步驟?⑴先確定系統(tǒng)范圍，畫出頂層的DFD圖。按照結(jié)構(gòu)化分析方法中“自頂向下，逐步分解”的思想，可以先將整個(gè)系統(tǒng)看作是一個(gè)加工，它的輸入數(shù)據(jù)和輸出數(shù)據(jù)表明了系統(tǒng)和外部環(huán)境的接口，從而首先畫出系統(tǒng)的頂層數(shù)據(jù)流圖?⑵逐層分解頂層DFD圖，獲得若干屮間層DFD圖。為了能夠清楚地表明系統(tǒng)加工的詳細(xì)過程，接著從頂層數(shù)據(jù)流圖出發(fā)，逐層地對系統(tǒng)進(jìn)行分解。每分解一次，系統(tǒng)中加工的數(shù)量就隨之增加，每個(gè)加工的功能描述也越來越具體。重復(fù)這種分解，直至得到系統(tǒng)的底層數(shù)據(jù)流圖。?(3)畫出底層的DFD圖。底層數(shù)據(jù)流圖中的所有加工都應(yīng)是不可再分解的、最簡單的“原子加工”。(3)建立數(shù)據(jù)流模型的原則建立數(shù)據(jù)流模型要遵循以下的原則:(1)每個(gè)加工至少應(yīng)有一個(gè)輸入數(shù)據(jù)流(反映被處理數(shù)據(jù)的來源)和一個(gè)輸出數(shù)據(jù)流(反映加工的結(jié)果）。(2)數(shù)據(jù)流圖中各構(gòu)成元素的名稱必須具有明確的含義且能夠代表對應(yīng)元素的內(nèi)容或功能。(3)對數(shù)據(jù)流圖中某個(gè)加工進(jìn)行細(xì)化生成的下層數(shù)據(jù)流圖，稱為其上層圖的子圖。應(yīng)保證分層數(shù)據(jù)流圖中任意對應(yīng)的父圖和子圖的輸入/輸出數(shù)據(jù)保持一致。(4)在數(shù)據(jù)流圖中，應(yīng)按照層次給每個(gè)加工編號(hào)，用于表明該加工所處的層次及上、下層的父圖與子圖的關(guān)系。(5)在父圖中不要出現(xiàn)子圖中涉及的局部數(shù)據(jù)存儲(chǔ)文件。(6)數(shù)據(jù)流圖只能由四種基本符號(hào)組成，是實(shí)際業(yè)務(wù)流程的客觀映象，用于說明系統(tǒng)應(yīng)該“做什么”，而不需要指明系統(tǒng)“如何做”。(7)數(shù)據(jù)流圖的分解速度應(yīng)保持適中。通常一個(gè)加工每次可分解為2?4個(gè)子加工，最多不要超過七個(gè)，因?yàn)檫^快的分解會(huì)增加用戶對系統(tǒng)模型理解的難度。(8)為了便于數(shù)據(jù)流圖在計(jì)算機(jī)上的輸入和輸出，免去畫斜線、弧線、圓等符號(hào)的麻煩，數(shù)據(jù)流圖還有另一套表示符號(hào)，如下表所示。分層DFD圖的改進(jìn)改進(jìn)的原則與畫分層DFD圖的基本原則是一致的，可從以下方面考慮DFD圖的改進(jìn)：?⑴檢查數(shù)據(jù)流的正確性數(shù)據(jù)守恒子圖、父圖的平衡文件使用是否合理。特別注意輸入/出文件的數(shù)據(jù)流。?⑵改進(jìn)DFD圖的易理解性簡化加工之間的聯(lián)系(加工間的數(shù)據(jù)流越少，獨(dú)立性越強(qiáng)，易理解性越好）。169。改進(jìn)分解的均勻性。適當(dāng)命名(各成分名稱無二義性，準(zhǔn)確、