第5章軟件項目需求分析階段的知識和管理ppt課件

1、第5章 軟件工程需求分析階段的知識和管理本章要點： 需求分析是軟件工程的立足之本 需求分析的任務(wù)內(nèi)容 需求分析階段的團隊組織 需求分析階段的工程管理 需求獲取的方法和特點 需求分析方法和建模工具 需求分析階段性成果和考核根據(jù) 軟件需求分析階段任務(wù)的根本義務(wù)就是要準確回答“用戶真正需求一個什么樣的軟件系統(tǒng)?該軟件系統(tǒng)必需完成什么功能?。 需求分析階段將對軟件系統(tǒng)提出完好、準確、明晰、詳細的要求。5.1 需求分析是軟件工程的立足之本 需求分析是整個軟件工程開展任務(wù)的根底，需求分析質(zhì)量的好壞，直接關(guān)系到軟件工程交付成果的客戶稱心度，甚至整個工程的成敗。假設(shè)需求分析任務(wù)做的不扎實，無論設(shè)計階段任務(wù)完成

2、得如何出色、軟件編碼質(zhì)量如何高，其結(jié)果將只會給用戶帶來絕望，給開發(fā)者帶來失敗的苦惱。5.2 需求分析的任務(wù)內(nèi)容5.2.1需求分析的目的、內(nèi)容和義務(wù) 目的 獲取完好、準確的用戶需求； 充分了解、認識和分析用戶的需求； 采用需求建模方法編寫需求規(guī)格闡明，為開展整個軟件工程的延續(xù)任務(wù)提供詳細的義務(wù)要求，為開發(fā)者和用戶提供軟件工程成果質(zhì)量評價的重要根據(jù)。 任務(wù)內(nèi)容 描寫出軟件的功能和性能、指明軟件和其他系統(tǒng)元素的接口、并建立軟件必需滿足的約束條件； 分解軟件系統(tǒng)模塊，建造將被軟件處置的數(shù)據(jù)、功能和行為模型，為軟件設(shè)計者提供了可被翻譯成數(shù)據(jù)、體系構(gòu)造、界面和處置流程的設(shè)計模型； 提交需求規(guī)格闡明書，構(gòu)成

3、軟件工程管理過程的第一個里程碑成果。 義務(wù) 問題分析 (即如何獲取需求 )、需求描畫(即如何定義需求)和需求驗證。 問題分析 需求分析人員經(jīng)過對問題及其環(huán)境的了解、分析和綜合，消除用戶需求的模糊性、歧義性和不一致性。 系統(tǒng)分析人員應(yīng)該將本人對客戶需求及問題的了解與本人所擁有的軟件開發(fā)閱歷結(jié)合起來，以便發(fā)現(xiàn)哪些要求是由于用戶的片面了解和短期行為所提出的不合理的要求，哪些要求是尚未提出但具有真正價值的潛在需求。 由于用戶群中每個用戶的出發(fā)點不同，思索問題的角度也有所區(qū)別，從不同的運用層面論述對原始問題的了解和對目的系統(tǒng)的要求，因此，有必要對原始問題及其軟件求解建立模型。 這種模型一方面用于準確記錄

4、用戶從不同的角度、在不同的籠統(tǒng)級別對原始問題和軟件要求的描畫；另一方面，它也將協(xié)助分析人員發(fā)現(xiàn)用戶需求中的不一致性，排除不合理的部分，發(fā)掘潛在的用戶需求。 這種模型是分析人員對于原始問題及其軟件了解的一種知識構(gòu)造。這種構(gòu)造往往包含問題及其環(huán)境所涉及的信息流、處置功能、用戶界面、行為模型及設(shè)計約束。它是需求規(guī)格闡明書、軟件設(shè)計和實現(xiàn)的主要根底。 (2)需求描畫 以需求模型為根底，思索問題的軟件可解性，生成需求規(guī)格闡明書和初步的用戶手冊。 需求規(guī)格闡明書包含對目的系統(tǒng)外部行為的完好描畫、需求驗證規(guī)范以及用戶對系統(tǒng)在性能、質(zhì)量、可維護性等方面的要求。 用戶手冊那么包括用戶界面描畫以及有關(guān)目的系統(tǒng)運用

5、方法的初步想象。 (3)需求驗證 分析人員在用戶和軟件設(shè)計人員的配合下對生成的需求規(guī)格闡明進展復(fù)核，以確保軟件需求的全面性、準確性、一致性、可行性。 并運用戶和軟件設(shè)計人員對需求規(guī)格闡明及用戶手冊的了解達成共識，達成對目的系統(tǒng)了解的一致性。 問題分析、需求描畫和需求驗證并不遵照線性順序，這些活動是相互浸透、增量并行和延續(xù)反復(fù)的。包括四個過程： 第一，系統(tǒng)分析員和用戶開展面對面的交流，記錄用戶提供的信息，即開展獲取活動； 第二，需求分析員處置從用戶那里獲取的信息并了解它們，把它們分成不同的類別，并將客戶需求同能夠的軟件需求相聯(lián)絡(luò)，即開展需求分析活動； 第三，系統(tǒng)分析人員將客戶需求信息構(gòu)造化，編寫

6、成文檔和表示圖，構(gòu)成需求規(guī)格闡明書； 最后，組織用戶代表評審文檔，并糾正存在的錯誤，完成需求的驗證任務(wù)。 這四個過程循環(huán)往復(fù)，浸透到客戶業(yè)務(wù)系統(tǒng)的各個環(huán)節(jié)，貫穿于需求分析的整個任務(wù)過程中，直到工程組人員與客戶在對目的系統(tǒng)的功能、流程、接口、數(shù)據(jù)、操作等多方面內(nèi)容達成共識后，方可宣布需求分析義務(wù)的終了。 需求還有能夠再發(fā)生變動，此時需求分析的終了，只是標志客戶需求在一定時期內(nèi)的“相對鎖定，這對整個工程未來任務(wù)的開展非常重要。5.2.2需求分析的任務(wù)方式 需求分析在通常情況下劃分為三個階段。 第一階段：“訪談式(Visitation) 這一階段是和詳細用戶方的指點層、業(yè)務(wù)層人員進展訪談式溝通，主要

7、目的是從宏觀上把握用戶的詳細需求，了解現(xiàn)有的組織架構(gòu)、業(yè)務(wù)流程、硬件環(huán)境、軟件環(huán)境、現(xiàn)有系統(tǒng)等詳細情況，建立起良好的溝通渠道和方式。 實現(xiàn)手段：訪談、發(fā)放調(diào)查表 成果：調(diào)查報告、業(yè)務(wù)流程報告 第二階段：“誘導式(1nducement) 在分析人員曾經(jīng)了解了詳細用戶方的組織架構(gòu)、業(yè)務(wù)流程、硬件環(huán)境、軟件環(huán)境、現(xiàn)有的運轉(zhuǎn)系統(tǒng)等信息的根底上，作出簡單的用戶流程和操作界面，同時結(jié)合以往的工程閱歷對用戶采用誘導式、啟發(fā)式的調(diào)研方法和手段，和用戶一同討論業(yè)務(wù)流程設(shè)計的合理性、準確性、方便性、習慣性和易操作性。 實現(xiàn)手段：訪問誘導、DEMO演示 輸出成果：調(diào)研分析報告、原型反響報告、業(yè)務(wù)流程報告。 第三階段

8、：“確認式(Affirm) 進展詳細的流程細化、數(shù)據(jù)項確實認階段。 分析人員需求完成明確的業(yè)務(wù)流程報告、數(shù)據(jù)項描畫、修正后的DEMO系統(tǒng)及業(yè)務(wù)流設(shè)計目的。 用戶方審查業(yè)務(wù)流程報告、數(shù)據(jù)項描畫以及經(jīng)過操作開發(fā)方提供的DEMO系統(tǒng)，提出反響意見，并對曾經(jīng)完成并可接受的報告、文檔簽字確認。 實現(xiàn)手段：訪問(回想、確認)，提交業(yè)務(wù)流程報告、數(shù)據(jù)項描畫；DEMO演示系統(tǒng)。 輸出成果：需求分析報告 5.3 需求分析階段的團隊組織5.3.1團隊組織與建立 需求分析作為軟件開發(fā)生命周期的第一個里程碑，它的內(nèi)容貫穿于整個軟件生命周期全過程，是一個需求團隊成員高度配合和親密協(xié)作的階段。 需求分析階段參與工程的人員

9、及任務(wù)職責如下： (1)工程經(jīng)理：擔任需求分析階段工程進度的安排和控制；參與工程的各種資源調(diào)度；擔任工程的總體協(xié)調(diào)任務(wù)。 (2)系統(tǒng)分析人員：與用戶方的技術(shù)人員和業(yè)務(wù)人員進展良好的溝通，了解業(yè)務(wù)流程、功能需求、系統(tǒng)想象和工程目的，完成軟件需求闡明書的編制義務(wù)。 (3)程序員：在采用原型法的系統(tǒng)分析過程中，程序員參與用戶的需求分析過程，根據(jù)用戶的實踐需求，完成原型系統(tǒng)的開發(fā)任務(wù)。 (4)質(zhì)量管理人員：擔任組織有關(guān)人員完成對需求分析任務(wù)的質(zhì)量審核和需求闡明書的評審任務(wù)。 (5)配置管理人員：把經(jīng)過評審的需求闡明書納入軟件的配置管理項。 (6)用戶方的技術(shù)人員：用戶方參與工程的技術(shù)人員(往往是計算中

10、心的任務(wù)人員，未來任務(wù)是維護系統(tǒng))，經(jīng)過與系統(tǒng)分析人員的溝通，確定系統(tǒng)的技術(shù)實現(xiàn)方案。要求該人員具有對需求闡明書中系統(tǒng)技術(shù)方案的最終簽字認可權(quán)。 (7)用戶方的業(yè)務(wù)人員：用戶方參與工程的業(yè)務(wù)人員，經(jīng)過與系統(tǒng)分析人員的溝通，確定未來軟件系統(tǒng)實現(xiàn)的詳細功能和業(yè)務(wù)模型。要求該類人員對需求闡明書中的業(yè)務(wù)需求具有最終簽字認可的權(quán)益。 圖5-4為需求分析階段典型的團隊組織模型。 需求分析涉及的單位、組織和人員主要包括兩大類，一類是用戶方，一類是開發(fā)方。 雙方參與需求分析階段任務(wù)的人員在各自工程經(jīng)理的指點和協(xié)調(diào)下開展任務(wù)，并分別與對方工程人員進展充分的溝通和交流；雙方工程人員之間協(xié)調(diào)不了的事情由雙方工程經(jīng)理

11、進展協(xié)調(diào)，工程經(jīng)理協(xié)調(diào)不了的事情交工程委員會協(xié)調(diào)。 整個軟件需求分析階段的團隊組織是按照工程管理中典型的矩陣式構(gòu)造來開展，可以有效地利用工程資源，添加了溝通的時機，充分發(fā)揚工程人員的積極性。5.3.2團隊管理 本階段的團隊管理包含工程參與雙方團隊的管理任務(wù)。 團隊管理的特點有： (1)團隊成員才干的要求 具有良好的溝通及協(xié)作才干是對工程一切參與人員的共同要求。 對開發(fā)方需求分析人員，需求具備豐富的需求分析閱歷、良好的業(yè)務(wù)知識。切忌承當分析義務(wù)的分析人員既是新手，又不熟習業(yè)務(wù)知識 對用戶方人員來說，技術(shù)人員要具備良好的技術(shù)背景，熟習本單位的計算機系統(tǒng)及網(wǎng)絡(luò)情況。業(yè)務(wù)人員需求具有豐富的業(yè)務(wù)知識，熟

12、習各種業(yè)務(wù)的處置流程及結(jié)果方式。 (2)明確劃分雙方的職責 在需求分析階段開場時，要明確工程雙方在協(xié)作中的權(quán)益和義務(wù)，構(gòu)成正式的工程協(xié)作文件。 為了防止用戶方任務(wù)人員不情愿積極參與需求調(diào)研過程，或?qū)π枨蠓治龅娜蝿?wù)不注重的景象，對需求分析結(jié)果，用戶方必需簽字確認。 (3)團隊矛盾及問題的防備及處理方法 需求分析階段容易發(fā)生的矛盾與問題主要是系統(tǒng)分析人員與用戶的任務(wù)配合上。 例如：由于種種緣由，用戶借任務(wù)忙，使需求調(diào)研任務(wù)一拖再拖；或用戶回絕對各項需求分析結(jié)果進展簽字確認等；或是雙方任務(wù)方式上的不恰當，呵斥任務(wù)配合上的矛盾和摩擦等。 可采用以下方法加以防備和處理： 1)明確各自的責任和義務(wù) 2)樹

13、立共同的工程目的和勝利認識 3)添加友誼 4)出現(xiàn)問題盡量在小范圍內(nèi)自行協(xié)調(diào)處理 5)組織工程協(xié)調(diào)會議5.4 需求分析階段的工程管理5.4.1需求分析階段的進度管理與控制 做好需求分析階段的進度管理任務(wù)，需求做好以下幾個方面的任務(wù)： (1)詳細的任務(wù)方案和明確的責任分工 由于需求分析階段工程雙方任務(wù)協(xié)作較多，容易出現(xiàn)配合上的矛盾和問題。所以，在需求分析階段開場時，雙方的工程經(jīng)理要進展溝通，制定本階段詳細的任務(wù)方案、參與人員的任務(wù)分工及職責。 方案主要包括： 本階段詳細的進度方案安排； 工程參與雙方參與人員的任務(wù)分派及職責要求； 雙方人員的任務(wù)時間商定、任務(wù)內(nèi)容及任務(wù)時間的保證要求； 在工程協(xié)作

14、過程中雙方任務(wù)人員的任務(wù)流程商定、問題及其處理流程商定等。 方案完成后，要構(gòu)成正式的書面文件。雙方工程經(jīng)理簽字認可后下發(fā)執(zhí)行。 (2)合理的需求調(diào)研和科學的任務(wù)安排 較為理想的需求調(diào)研步驟為： 首先與用戶方的技術(shù)人員交流，確定系統(tǒng)實現(xiàn)的技術(shù)方面的需求，即技術(shù)實現(xiàn)的架構(gòu)與要求。 接下來再與業(yè)務(wù)人員交流，獲取詳細的業(yè)務(wù)需求。在業(yè)務(wù)需求的調(diào)研過程中，應(yīng)先確定系統(tǒng)的主要功能要求，再在此根底上逐漸進展需求細化任務(wù)。 (3)有效遏制需求變卦 需求分析階段用戶需求的變卦主要表現(xiàn)為用戶需求的反復(fù)，容易使需求分析任務(wù)原地轉(zhuǎn)圈，無法按方案完成需求分析任務(wù)。 要遏制分析階段的需求變卦，通常采用的方法有以下幾種： 1

15、)充分到位的需求調(diào)研。 詳細縝密的需求分析，以及對用戶需求的深層次發(fā)掘等任務(wù)，是保證高質(zhì)量需求分析任務(wù)的根底，也是防止需求變卦的根本手段。 2)用戶簽字制度。 簽字的方法可以運用戶在需求調(diào)研中以積極擔任的態(tài)度，仔細對待每個需求分析項。這樣做可有效遏制需求的反復(fù)。 3)定期的任務(wù)通報制度。 開發(fā)方工程經(jīng)理要定期將需求分析階段的任務(wù)進展情況、存在的問題進展匯總，向工程雙方的高層指點、工程管理委員會進展任務(wù)通報。 4)對簽字認可后的需求納入需求管理，對發(fā)生的需求變卦，執(zhí)行需求變卦處置流程。 (4)確保與用戶溝通的深度和廣度 所謂深度是指分析人員在需求調(diào)查的過程中，不但要與用戶建立良好的任務(wù)關(guān)系，甚至

16、要努力去建立比較深沉的私人關(guān)系，拉近間隔，便于溝通。只需這樣才干更清楚的了解用戶的真實想法，獲得用戶的尊重和任務(wù)支持。 所謂廣度就是在需求調(diào)研過程中要進展整體調(diào)研，需求調(diào)研要面向用戶工程參與的全體人員。一方面是要了解用戶的整體需求細節(jié)；另一方面也可從不同人員各自的角度了解用戶方究竟想要完成一個什么樣的系統(tǒng)。 對于用戶方的不同認識，分析人員可經(jīng)過召開工程協(xié)調(diào)會議的方法，協(xié)調(diào)并一致用戶方人員對相關(guān)需求的一致看法。 (5)采取有效的需求調(diào)研方法 分析人員要確保本階段任務(wù)可以按方案執(zhí)行，首先需求分析在工程需求分析中的困難和問題，并采用有針對性的需求調(diào)研方法。 (6)需求的復(fù)用 在軟件工程實施的過程中，

17、許多不同工程間的需求都有類似性，特別是對于同類型工程在不同用戶間的實施，需求之間的類似性就更加普遍。所以，分析人員應(yīng)該非常留意需求的復(fù)用。 經(jīng)過復(fù)用，用戶構(gòu)成了一個需求的原型，進而只需求對原型進展修正和完善即可。 (7)需求分析的終了控制 要做好需求驗收任務(wù)，需求踏踏實實做好需求分析的各階段任務(wù)： 1)經(jīng)過工程的合同條款，做好工程的范圍規(guī)劃，明確工程的任務(wù)內(nèi)容。 2)做好分析階段的任務(wù)方案，明確任務(wù)進度、人員分工及各自的任務(wù)職責。 3)做好各部分需求條款的簽字驗收任務(wù)及定期的任務(wù)總結(jié)與任務(wù)匯報。 4)做好目的系統(tǒng)的引見或原型系統(tǒng)的演示。 在做好上述任務(wù)的根底上，才干確保需求分析任務(wù)按進度、高質(zhì)

18、量地完成，需求階段的驗收任務(wù)也就可以順利地進展。5.4.2需求分析階段的質(zhì)量管理與控制 高質(zhì)量的需求最能真實反映用戶的實踐要求，也將對整個工程的開展帶來較少的變卦處置及較高的軟件開發(fā)效率。 要得到高質(zhì)量的需求分析，應(yīng)做到以下幾點： (1)積極仔細進展調(diào)研預(yù)備 分析人員在進展每一次需求調(diào)研前，要仔細做好調(diào)研前的預(yù)備任務(wù)：即要按照任務(wù)方案設(shè)定需求調(diào)研主題；設(shè)計采用的需求調(diào)研方式；能夠的結(jié)果方式估計及每種結(jié)果的應(yīng)對措施等。 (2)正確了解用戶的需求描畫及非二異性的需求文字記錄 對于用戶描畫的軟件需求，一方面分析人員要正確了解，使工程雙方之間達成共識；另一方面，分析人員在進展記錄或書寫需求闡明書的時候

19、，要表達準確，防止二異性描畫的出現(xiàn)。 (3)做好各需求項的用戶簽字認可任務(wù) 需求分析結(jié)果是工程驗收的質(zhì)量規(guī)范，具有用戶評審及驗收簽字的需求文檔是最終軟件產(chǎn)品能否經(jīng)過驗收的關(guān)鍵。將需求分析階段的一切需求調(diào)研及會議討論的結(jié)果構(gòu)成正式的書面文件，經(jīng)用戶審核簽字后，納入需求管理。 (4)做好需求的管理任務(wù) 完成需求文檔的版本控制及需求變卦的控制任務(wù)，一方面可使需求分析的結(jié)果可管理，防止頻繁的修正及內(nèi)容混亂；另一方面經(jīng)過有效的管理也可提高軟件需求文檔的復(fù)用率。 (5)定期的會議交流和評審 經(jīng)過定期召開工程交流會議，一方面可將已獲得的結(jié)果通報全體用戶人員；另一方面將需求分析中的問題拿出來，供全體人員討論，

20、最終構(gòu)成一致的結(jié)果。同時對已完成的需求結(jié)果進展用戶確實認，構(gòu)成“相對鎖定的用戶需求。5.4.3需求分析階段的溝通管理 (1)溝通的主要目的 溝通的主要目的就是要準確、全面地了解用戶的實踐運用需求和理想目的。為最終實現(xiàn)和滿足用戶的實踐需求奠定良好的根底。 (2)溝通的技巧 需求分析人員一方面不能有害怕用戶的心思，應(yīng)以一種積極、自動，將工程做好的心態(tài)與用戶進展溝通；另一方面要將需求調(diào)研看作是為了給用戶處理問題，而不是來指點任務(wù)的。 在協(xié)作任務(wù)中，只需對他人尊重和了解，才干換取他人的尊重和支持。同時在任務(wù)中要以平和的心態(tài)面對用戶的需求變卦，該當積極地與用戶進展交流，實現(xiàn)對需求變卦的最正確處理。 不卑

21、不亢、相互尊重、心平氣和 (3)溝通的方式 1)正式的方式。即按照本階段任務(wù)方案的安排，對用戶進展需求調(diào)研?；蛘呤窍嚓P(guān)人員參與問題的討論等。 2)非正式的方式。經(jīng)過共同進餐、閑聊、體育活動等方式。 在實踐任務(wù)中，采用非正式的用戶溝通方式往往可以獲得意想不到的任務(wù)效果。 (4)溝通結(jié)果 對于溝通獲得的任務(wù)結(jié)果，都要構(gòu)成正式的書面文件，經(jīng)過用戶的簽字驗收，納入需求管理范圍。5.4.4需求管理 軟件工程的實現(xiàn)過程是由需求驅(qū)動的，因此人們希望在軟件的開場階段盡量提供一個準確的需求定義，然后嚴厲的實現(xiàn)這些需求。 但是，每個大型軟件的需求都是隨著需求的開展和人們認識程度的提高發(fā)生不同程度的需求變卦。 一切

22、針對需求變卦的任務(wù)在需求分析階段要納入需求管理的范圍。 1需求工程 把一切與需求直接相關(guān)的活動通稱為需求工程。 需求工程的活動可分為兩大類：需求開發(fā)；需求管理。其構(gòu)造如圖5-5所示需求開發(fā)需求獲取需求分析需求定義需求驗證需求跟蹤需求變卦控制版本管理需求復(fù)用需求工程需求管理圖5-5 需求工程構(gòu)造圖 需求開發(fā)的目的是經(jīng)過調(diào)查與分析，獲取用戶需求并定義產(chǎn)品需求。需求開發(fā)的過程有四個主要活動: 1)需求獲取。與用戶進展交流，捕捉、分析和修正用戶目的系統(tǒng)的需求，并提煉出符合處理問題的用戶需求，產(chǎn)生。 2)需求分析。對各種需求信息進展分析并籠統(tǒng)描畫，為目的系統(tǒng)建立一個概念模型。 3)需求定義。是根據(jù)需求調(diào)

23、查和需求分析的結(jié)果，進一步定義準確無誤的產(chǎn)品需求，產(chǎn)生。 4)需求驗證。指開發(fā)方和用戶共同對需求文檔進展評審，經(jīng)雙方對需求達成共識后作出書面承諾，使需求文檔具有商業(yè)合同效果。 需求管理的目的是：在用戶與開發(fā)方對需求有著共同了解的根底上，維護需求的完好性和一致性，并控制需求的變卦。 需求管理過程也有四個主要活動： 1)需求跟蹤。指經(jīng)過比較需求文檔與后續(xù)任務(wù)成果之間的對應(yīng)關(guān)系，確保產(chǎn)品根據(jù)需求文檔進展開發(fā)。 2)需求變卦控制。指根據(jù)“變卦懇求一審批一更改一重新確認的流程處置需求的變卦，防止需求變卦失去控制而導致工程發(fā)生混亂。 3)版本管理。詳細記錄發(fā)生需求變卦的需求文檔版本的日期，發(fā)生變卦的緣由，

24、變卦發(fā)生的控制記錄，更新后文檔的版本號等。 4)需求復(fù)用。實現(xiàn)為需求開發(fā)過程提供可復(fù)用的需求文檔資料，提高需求開發(fā)的任務(wù)效率和質(zhì)量。 需求開發(fā)與需求管理活動的業(yè)務(wù)流程如圖5-6所示。 (2)需求跟蹤 是為了建立與維護“需求一設(shè)計一編程一測試之間的一致性，確保一切的任務(wù)成果符合用戶需求。 需求跟蹤有兩種方式： 1)正向跟蹤。經(jīng)過檢查中的每個需求，看能否都能在后繼任務(wù)成果中找到對應(yīng)點。 2)逆向跟蹤。經(jīng)過檢查設(shè)計文檔、代碼、測試用例等任務(wù)成果，看能否都能在中找到出處。 在實踐任務(wù)中，我們通常將正向跟蹤和逆向跟蹤合并運用。 (3)需求變卦控制 對軟件工程來說廣需求的變卦是不可防止的，并且許多需求的改

25、良是必要的、合理的。 需求發(fā)生變卦的緣由主要有： 1)隨著工程的進展，人們對需求的認識越來越深化。對于早些時候的在需求描畫中的錯誤或缺乏有了明晰的認識，因此要對早先提出的需求進展必要的變卦處置。 2)業(yè)務(wù)或市場發(fā)生了變化，原先的需求文檔曾經(jīng)不能順運用戶實踐業(yè)務(wù)的開展要求、或跟不上當前市場的變化。因此，要進展需求的變卦處置，否那么，完成的軟件產(chǎn)品就失去了其應(yīng)有的運用價值。 提出需求變卦的動機是好的，目的是希望產(chǎn)品更加符合用戶的需求或市場的變化。但對軟件工程開發(fā)小組而言，變卦需求意味著要調(diào)整工程資源、調(diào)整任務(wù)方案和重新分配任務(wù)義務(wù)、修正前期的任務(wù)成果等，開發(fā)小組要為此付出較大的代價。因此，變卦懇求

26、要有一定的范圍，否那么工程實施將會遙遙無期。 需求變卦控制的根本出發(fā)點是： 1)假設(shè)需求變卦帶來的益處大于害處，那么允許變卦，但必需按照在方案階段已定義好的變卦處置流程執(zhí)行，防止變卦失去控制。 2)假設(shè)需求變卦帶來的害處大于益處，那么回絕變卦。 需求變卦控制是一個渠道和過濾器，經(jīng)過它可以確保采用最適宜的變卦，使變卦能夠產(chǎn)生的負面影響減少到最小。 需求變卦控制的普通流程如下 1)提出變卦懇求 需求變卦懇求的提出者可以是任何一個工程的利益相關(guān)人員。目的是完善需求或修正原需求文檔中不正確的內(nèi)容。 2)審批 對于變卦懇求的審批流程要根據(jù)工程方案階段確定的變卦處置流程進展。普通要由開發(fā)方和用戶方共同承當

27、需求變卦的審批任務(wù)。審 批任務(wù)的主要目的是評價需求變卦是利大于弊、還是弊大于利，根據(jù)評價結(jié)果斷定能否贊同進展需求變卦。 3)修正需求文檔 對于經(jīng)過審批的變卦懇求，變卦懇求人從配置管理員或需求管理 員處獲得需求修正的當前運用的需求文檔版本，完成相關(guān)內(nèi)容的修正和完善任務(wù)。 4)重新進展需求確認 修正完成的需求文檔，要重新組織對需求的評審和確認任務(wù)。對經(jīng)過需求評審和確認的需求文檔納入配置管理和需求管理，構(gòu)成最新的需求文檔版本。 5)變卦終了 需求變卦處置終了后，需求根據(jù)變卦處置過程的任務(wù)記錄完成。根據(jù)需求變卦情況進展任務(wù)量的估算，并進展任務(wù)方案的調(diào)整。 需求變卦將呵斥費用添加、工期延伸，所以，在審批

28、階段就要仔細進展變卦所帶來的任務(wù)量及本錢添加情況的評價。 假設(shè)任務(wù)量或本錢添加不是很大時，可由工程雙方協(xié)商能否由用戶方添加適當?shù)拈_發(fā)費用完成。 假設(shè)任務(wù)量或本錢添加較大時，一個較為理想的處理方法是將變卦部分作為本工程的二期工程來實施。 5.5 需求獲取的方法和特點5.5.1需求獲取的主要困難及對策 整個軟件工程實施過程中，需求獲取是軟件開發(fā)中最困難、最關(guān)鍵、最易出錯及最需求溝通和交流的重要方面。 呵斥需求獲取困難的主要緣由是： (1)分析人員領(lǐng)域知識的缺乏 大多數(shù)承當需求分析義務(wù)的需求分析人多數(shù)是技術(shù)出身，而不是業(yè)務(wù)出身。其知識構(gòu)造的重點是計算機技術(shù)，對在工程實施過程中的管理及用戶的業(yè)務(wù)操作等

29、普通都不太熟習。而用戶是個計算機的門外漢。 需求分析員該當抓緊補習和學習該領(lǐng)域的業(yè)務(wù)知識。能夠的話，最好聘請既懂軟件開發(fā)又懂領(lǐng)域知識的行家來協(xié)助。 (2)用戶對需求描畫不清 大多數(shù)的用戶不知道應(yīng)該提什么樣的需求，或者說他們對目的系統(tǒng)究竟要做成什么樣子只需一個模糊的概念。這樣的想法很能夠只是出自于企業(yè)規(guī)劃中提出的一個宏觀描畫 需求分析員要擅長發(fā)掘、擅長誘導、甚至給用戶演示一些實踐運用系統(tǒng)來啟發(fā)用戶對目的系統(tǒng)的了解和認識。 (3)對需求了解上的偏向 在需求分析的過程中，對于用戶表達的軟件需求，不同的開發(fā)人員能夠存在不同的了解。假設(shè)需求分析員誤解了用戶的真正意圖，將會導致后續(xù)的開發(fā)任務(wù)在錯誤的方向指

30、引下越走越遠。 不論是復(fù)雜的工程還是簡單的工程，需求分析員和用戶都有能夠誤解需求。所以需求評審(需求驗證)任務(wù)必不可少，經(jīng)過需求分析、用戶交流、需求評審等手段可使工程一切人員對目的系統(tǒng)的認識 達成共識。5.5.2基于調(diào)查的需求獲取方法 (1)需求調(diào)查任務(wù)流程 需求調(diào)查的普通任務(wù)流程如下： 1)需求調(diào)查預(yù)備。 2)進展需求調(diào)查并記錄。 3)分析用戶的需求信息并撰寫。 4)進展需求確認任務(wù)。 (2)需求調(diào)查預(yù)備 需求調(diào)查預(yù)備任務(wù)圍繞以下三個中心進展： 1)要調(diào)查什么內(nèi)容? 2)經(jīng)過什么方式進展調(diào)查? 3)對“何人在“何時進展調(diào)查? 確定需求調(diào)查的內(nèi)容 需求分析調(diào)查前，分析人員應(yīng)將一切的工程資料進展

31、匯總和分析，并與本工程的相關(guān)人員進展簡單溝通，以便對工程整體上有一個根本的了解。 然后，根據(jù)本人對工程的認識，確定進展需求分析任務(wù)的重點和目的，起草相關(guān)的需求調(diào)查詢題表，將調(diào)查任務(wù)的重點鎖定在該問題表內(nèi)。 確定需求調(diào)查的方式 普通可以采取以下幾種方式： 與用戶交談，向用戶提問題。 觀賞用戶的任務(wù)流程，察看用戶的操作。 向用戶群體發(fā)放調(diào)查詢卷表。 與同行專家交談，聽取他們的意見。 分析曾經(jīng)存在的同類軟件產(chǎn)品，提取需求。 從行業(yè)規(guī)范、規(guī)那么中提取需求。 從Inlemet上搜索相關(guān)資料。 對于一個詳細的軟件工程，分析人員可以根據(jù)詳細工程和用戶的情況選擇12種方式作為本工程主要的需求調(diào)查方式，其他方式

32、作為輔助的調(diào)查方式完成需求調(diào)查的義務(wù)。 最后，需求確定調(diào)查的時間、地點和人員等 對于調(diào)查的時間、地點、人員確實定，分析人員首先需求做好本人的需求調(diào)查計 劃，由工程經(jīng)理組織工程會議，經(jīng)過工程會議討論并產(chǎn)生“需求調(diào)查方案，確定用戶方需求調(diào)查的人員、時間和地點。 經(jīng)過工程會議可確保需求調(diào)查方案的可性行，確保調(diào)查者和被調(diào)查者都能很好的履 行本人的任務(wù)職責。 要特別留意的是，在調(diào)查方案中確定的調(diào)查對象一定要全面、并具有廣泛的代表性，不要漏掉典型的用戶。 (3)進展調(diào)查并記錄 需求調(diào)查過程中應(yīng)留意以下問題： 1)對于按方案即將調(diào)查的用戶，要盡量提早約定并進展時間確認，這樣做一方面可防止用戶遺忘；另一方面可

33、提示用戶做好調(diào)研的預(yù)備任務(wù)，使調(diào)研獲得較好的效果。 2)與用戶約好的調(diào)查時間，分析人員切勿遲到或早退。同時要留意本人的禮節(jié)和說話方式，盡能夠多地獲得用戶的好感。 3)對于本人將要調(diào)查的用戶，需求分析員應(yīng)事先了解用戶的身份、背景、甚至用戶的性格、興趣和喜好等，以便調(diào)查時能采用靈敏的說話方式，使交談的氣氛融洽。 4)在需求調(diào)研過程中，應(yīng)防止運用IT行業(yè)術(shù)語，以便運用戶可以很好的了解。 5)在交談過程中，要迅速記錄需求調(diào)研的中心問題。不要等交流終了后才去整理和記錄，那樣會呵斥信息喪失和錯誤信息的發(fā)生。 (4)撰寫用戶需求闡明書 用戶需求闡明書的參考模板見表5-2。 用戶需求闡明書 0文檔引見 01文

34、檔目的 02文檔范圍 03讀者對象 04參考文檔 05術(shù)語與縮寫解釋 1產(chǎn)品引見 2產(chǎn)品面向的用戶群體 3產(chǎn)品該當遵照的規(guī)范或規(guī)范 4產(chǎn)品的功能性需求 5產(chǎn)品的非功能性需求 6其他需求 附錄：用戶需求調(diào)查報告表5-2 模板 (5)進展需求確認 編寫完成以后，工程經(jīng)理應(yīng)組織同行專家和用戶對的正確性進展驗證，即進展的評審任務(wù)，以使可以準確無誤地反映用戶的真實意圖。 對于經(jīng)過需求驗證后的，用戶進展簽字確認。5.5.3基于用例的需求獲取方法 利用傳統(tǒng)的需求調(diào)查獲取方法，當系統(tǒng)較復(fù)雜或較大時，有能夠出現(xiàn)前后描畫不一致的問題，而且，這些需求規(guī)格闡明也很難轉(zhuǎn)變?yōu)樵O(shè)計和實現(xiàn)的規(guī)格闡明。 面向?qū)ο蠹夹g(shù)的開展為我

35、們提供理處理問題的新思緒，其中基于用例(Use Case)的需求獲取方法作為日益流行的一種技術(shù)，被越來越多的開發(fā)團隊所運用。 (1)用例在需求分析中的運用 用例是指一個用戶或其他系統(tǒng)與要設(shè)計的系統(tǒng)進展的一個交互，這個交互是為了描畫某個目的。 用例是對一組動作序列的描畫，系統(tǒng)執(zhí)行該動作序列來為參與者產(chǎn)生一個可察看的結(jié)果值。UML用戶指南 用例的重要功能是經(jīng)過畫用例圖的方法來鑒別和劃分系統(tǒng)功能。它把系統(tǒng)分成角色(actor)和用例。其中角色可以是一個人、另一個軟件、一個硬件或其他與系統(tǒng)交互的實體。一個單一的用例，能夠包括完成某項義務(wù)的一系列邏輯相關(guān)的義務(wù)。 用例圖在面向?qū)ο蟮能浖_發(fā)中，為用戶進展

36、需求獲取和建模提供了一種有效的方法，是面向?qū)ο蠓治鼋５母住?用例像一個黑盒，它沒有包括任何和實現(xiàn)有關(guān)一些信息。它很容易就被用戶所了解。 假設(shè)用例缺乏以表達足夠的信息來支持系統(tǒng)的開發(fā)，就有必要把用例黑盒翻開，審視其內(nèi)部的構(gòu)造，找出黑盒內(nèi)部的Actor和用例。 就這樣經(jīng)過不斷的翻開黑盒，分析黑盒，再翻開新的黑盒。直到整個系統(tǒng)可以被明晰的了解為止。 采用用例的需求獲取是經(jīng)過訊問用戶要利用系統(tǒng)做什么。而大部分程序員的任務(wù)習慣也是思索計算機應(yīng)該如何實現(xiàn)用戶的要求。運用用例方法恰好可以調(diào)和雙方的矛盾。 雖然用例來源于用戶、效力于用戶，但是它同樣可以用做軟件開發(fā)的流程。 當系統(tǒng)的開發(fā)過程全部基于用例的時

37、候，如利用用例獲取需求，采用用例進展設(shè)計，運用用例進展編碼，運用用例開展測試的時候。這個開發(fā)過程就屬于用例驅(qū)動型的。 (2)用例的獲取方法 大部分用例將在工程的需求分析階段產(chǎn)生，并且隨著任務(wù)的深化會發(fā)現(xiàn)更多的用例，這些都應(yīng)及時增添到已有的用例集合中。 用例集合中的每個用例都是一個潛在的需求。 用例的獲取普通需求經(jīng)過兩個階段: 1)確定角色 獲取用例從識別角色開場。 角色可以分主要角色、次要角色。 經(jīng)過回答一些問題來發(fā)現(xiàn)角色。以下是可供參考的問題： 誰運用系統(tǒng)的主要功能(主要運用者)。 誰需求系統(tǒng)支持他們的日常任務(wù)。 誰來維護和管理，使系統(tǒng)正常任務(wù)(輔助運用者)。 系統(tǒng)需求支配哪些硬件。 系統(tǒng)需

38、求與哪些其他系統(tǒng)交互，包含其他計算機系統(tǒng)和其他運用程序。 對系統(tǒng)產(chǎn)生的結(jié)果感興趣的人或事物。 系統(tǒng)需求何種輸入輸出?輸入從何處來?輸出到何處? 2)獲取用例 獲取角色，就可以對每個角色提出問題以獲取用例。以下是可供參考的問題： 角色要求系統(tǒng)提供哪些功能(執(zhí)行者需求做什么)? 角色需求讀取、產(chǎn)生、刪除、修正或存儲的信息有哪些類型? 必需提示角色的系統(tǒng)事件有哪些?或者角色必需提示系統(tǒng)的事件有哪些?這些事件能干什么? 為了完好地描畫用例，還需求知道角色的某些典型功能能否被系統(tǒng)自動實現(xiàn)? 當前運轉(zhuǎn)系統(tǒng)(也許是一些手工操作而不是計算機系統(tǒng))的主要問題是什么? 用例為表達用戶需求提供了一種方法，而這一方法

39、必需與系統(tǒng)的業(yè)務(wù)需求相一致。分析者和用戶必需檢查每一個用例，在把它們納入需求之前決議其能否在工程所定義的范圍內(nèi)。 基于“用例方法進展需求獲取的目的在于描畫用戶需求運用系統(tǒng)完成一切的義務(wù)。 實際上，用例的結(jié)果集將包括一切合理的系統(tǒng)功能。實踐任務(wù)中，分析人員不能夠完全獲得需求，但是比起其他獲取方法，基于用例的方法可以帶來更好的效果。 5.5.4原型法 原型法(Rapid Prototyping)是一種以計算機程序設(shè)計為根底的系統(tǒng)開發(fā)方法，它可以快速經(jīng)過迭代的方法完成最終系統(tǒng)任務(wù)模型的建立。 原型法經(jīng)過先構(gòu)造一個功能簡單的原型系統(tǒng)，然后用戶經(jīng)過對原型系統(tǒng)的討論和評價而不斷完善與細化，最終得到符合用戶

40、需求的軟件系統(tǒng)。 原型法開發(fā)普通閱歷以下幾個階段： (1)確定用戶根本需求 經(jīng)過初步伐查獲取用戶的根本需求，了解用戶期望的功能、運用范圍、約束條件等。 這個階段用戶和開發(fā)者對系統(tǒng)功能要求的認識是不完好的，這種不完好可在今后的迭代過程中加以彌補和糾正。 (2)開發(fā)原型系統(tǒng)模型 原型系統(tǒng)是根據(jù)根本需求建立的初始方案，只包括部分功能，目的是為了進一步和用戶討論實踐的需求。 這個模型是在計算機上實現(xiàn)的，它包括了數(shù)據(jù)庫信息模型、系統(tǒng)功能模型和簡單的業(yè)務(wù)流程過程模型。 在構(gòu)造系統(tǒng)原型時比較強調(diào)預(yù)期的評價，而不是為了正規(guī)的運用。所以，對于最終產(chǎn)品的一些要求，如平安性、可靠性等普通不思索。 (3)征求用戶對原

41、型的改良意見 用戶在試用原型系統(tǒng)以后，可以指出哪些是他們需求的，哪些是不能接受的，還需求做哪些改良任務(wù)，還需求添加哪些新的功能。 (4)修正原型 根據(jù)用戶要求進展原型的改良任務(wù)。這個過程可以反復(fù)多次，直到用戶真正以為原型系統(tǒng)已實現(xiàn)了他所希望的實踐需求為止。 原型化方法比較適宜于用戶需求不清，業(yè)務(wù)不確定、需求經(jīng)常變化的軟件工程。原型法的優(yōu)點是見效快，用戶可以在很短的時間內(nèi)認識目的系統(tǒng)的概貌，然后再不斷去改良和完善。5.6 需求分析方法和建模工具 需求建模就是指用圖形符號來表示、描寫需求。5.6.1數(shù)據(jù)流圖法 數(shù)據(jù)流程圖法，即構(gòu)造化分析方法，是面向數(shù)據(jù)流開展需求分析任務(wù)的一種有效方法。普通采用自頂

42、向下，逐層分解的演義分析法來定義系統(tǒng)的需求，即先把分析對象籠統(tǒng)成一個系統(tǒng)，然后自頂向下的逐層分解，將復(fù)雜的系統(tǒng)分解成簡單的、可以清楚地被了解和表達的假設(shè)干個子系統(tǒng)。 這樣就可以分別了解系統(tǒng)的每個細節(jié)、前后順序和相互關(guān)系，找出各部分之間的數(shù)據(jù)接口。 構(gòu)造化分析方法通常用數(shù)據(jù)流圖(DFD)表達需求，以數(shù)據(jù)字典(DD)的方式記錄數(shù)據(jù)的邏輯定義。 構(gòu)造化分析方法的主要任務(wù)步驟包括： 1) 畫出反映當前系統(tǒng)的數(shù)據(jù)流程圖，指明系統(tǒng)的輸入輸出數(shù)據(jù)流。 2) 分析新系統(tǒng)的設(shè)定目的，按照設(shè)定目的的要求推導出等價邏輯模型的數(shù)據(jù)流程圖。 3)構(gòu)造新系統(tǒng)的邏輯模型，生成數(shù)據(jù)字典。 4)確定人機接口界面與操作方式。 5

43、)確定各種方案的本錢與效益，據(jù)此對各種方案進展分析比較。 6)選擇一種方案，建立完好的需求規(guī)格闡明書。 (1)數(shù)據(jù)流程圖 數(shù)據(jù)流程圖是以圖形的方式表達在問題中信息的變換和傳送過程。 它把系統(tǒng)看成是由數(shù)據(jù)流聯(lián)絡(luò)的各種概念的組合，用分解及籠統(tǒng)手段來控制需求分析的復(fù)雜性，采用分層的數(shù)據(jù)流程圖來表示一個復(fù)雜的系統(tǒng)。 數(shù)據(jù)流程圖中四種主要圖形元素： ：數(shù)據(jù)流。箭頭的始點和終點分別代表數(shù)據(jù)流的源和目的。 ：數(shù)據(jù)源、終點。代表系統(tǒng)之外的實體。 ：對數(shù)據(jù)的加工(處置)。加工是對數(shù)據(jù)進展處置的單元，它接納一定的數(shù)據(jù)輸入，對其進展處置，并產(chǎn)生輸出。 ：數(shù)據(jù)存儲。表示信息的靜態(tài)存儲，可以代表文件、文件的一部分、數(shù)據(jù)

44、庫的元素等。 (2)數(shù)據(jù)字典 數(shù)據(jù)字典的作用是對數(shù)據(jù)流圖中描畫的一切元素作出完好定義與闡明，是數(shù)據(jù)流圖的補充工具。 數(shù)據(jù)流圖和數(shù)據(jù)字典共同構(gòu)成系統(tǒng)的邏輯模型。 數(shù)據(jù)字典中的一切定義是嚴厲的、準確的，沒有二義性。它的用途是改善分析員與用戶之間的溝通，防止發(fā)生誤解。 數(shù)據(jù)字典的條目可以分為以下幾類： 1)數(shù)據(jù)流條目 主要闡明數(shù)據(jù)流條目是由哪些數(shù)據(jù)項組成，以及數(shù)據(jù)在單位時間內(nèi)的流量、來源、去向等。 內(nèi)容包括： 數(shù)據(jù)流名及其編號 數(shù)據(jù)流來源 數(shù)據(jù)流去向 數(shù)據(jù)流組成 數(shù)據(jù)流流量與頻度 2)數(shù)據(jù)項條目 闡明數(shù)據(jù)項類型、長度、取值范圍等。 內(nèi)容包括： 數(shù)據(jù)項稱號及編號 數(shù)據(jù)項類型 取值的范圍和取值含義 數(shù)據(jù)

45、項長度 3)數(shù)據(jù)存儲 數(shù)據(jù)存儲是數(shù)據(jù)停留和保管的場所。 內(nèi)容包括： 數(shù)據(jù)存儲的稱號及編號 流入和流出的數(shù)據(jù)流 數(shù)據(jù)存儲的組成 數(shù)據(jù)存儲方式 頻率及數(shù)據(jù)量 4)加工處置條目 闡明加工處置的輸人數(shù)據(jù)、輸出數(shù)據(jù)及其加工邏輯等。 內(nèi)容包括： 加工處置邏輯的稱號及編號 輸入和輸出 主要處置功能 5)外部實體條目 是系統(tǒng)的數(shù)據(jù)流由外部實體流人或者向外流出。 內(nèi)容包括： 外部實體的稱號及編號 與外部實體有關(guān)的數(shù)據(jù)流5.6.2面向?qū)ο蟮姆治龇椒?1面向?qū)ο蟮母靖拍?2面向?qū)ο蠓椒ㄅc構(gòu)造化方法的比較 構(gòu)造化方法強調(diào)過程的籠統(tǒng)和分解，將現(xiàn)實世界映射為數(shù)據(jù)流及加工，并且加工之間經(jīng)過數(shù)據(jù)流進展通訊。數(shù)據(jù)作為被動的實

46、體被自動的操作所加工，是以過程(或操作)為中心的分析方法。 面向?qū)ο蠓椒ㄒ詫ο鬄橹行?。對象將?shù)據(jù)和操作封裝在一同，提供有限的外部接口。對象之間經(jīng)過音訊相互通訊。 與構(gòu)造化方法相比，面向?qū)ο蠓椒ň哂幸韵绿攸c： 1)它把問題域的概念直接映射到對象及對象之間接口，符合人們通常的思想方式，減少了構(gòu)造化方法從問題域到分析階段的映射誤差。 2)面向?qū)ο蠓椒◤姆治?、設(shè)計到編碼采用一致的模型表示，后一階段可以直接復(fù)用前一階段的任務(wù)成果，彌合了構(gòu)造化方法從數(shù)據(jù)流圖到模塊構(gòu)造圖轉(zhuǎn)換的鴻溝，減少了任務(wù)量和映射誤差。 3)在客觀世界以及作為它的映射的軟件系統(tǒng)中，實體的構(gòu)造是相對穩(wěn)定的。面向?qū)ο蠓椒ń?jīng)過把屬性和效力封裝

47、在對象中，當外部功能發(fā)生變化時，堅持了對象構(gòu)造的相對穩(wěn)定，使改動局限于一個對象的內(nèi)部，減少了由于改動而引起的系統(tǒng)動搖效應(yīng)。 4)面向?qū)ο蠓椒ň哂械某欣^性和封裝性支持軟件復(fù)用，并易于擴展，能較好地順應(yīng)復(fù)雜大系統(tǒng)不斷開展和變化的要求。 (3)面向?qū)ο蠓治龅牟襟E 以Coad-Yourdon方法引見面向?qū)ο蟮能浖_發(fā)過程。 Coad-Yourdon方法在分析階段采用五個主要步驟確定一個多層的面向?qū)ο蠓治瞿Ｐ汀?標識對象 標識構(gòu)造 確定主題 定義屬性 定義效力及音訊銜接 這五個步驟并不是必需順序進展，經(jīng)常是根據(jù)需求交叉進展。當五個層次的任務(wù)全部完成時，系統(tǒng)分析的義務(wù)也就完成了。 1) 標識對象 應(yīng)該從問題域和系統(tǒng)責任兩個方面來確定對象。 問題域偏重于客觀存在的事物與系統(tǒng)中對象的映射；系統(tǒng)責任偏重于系統(tǒng)責任范圍內(nèi)的每一項職責都應(yīng)落實到某些對象來完成。