需求分析思考題

1、第一章 軟件需求概述思考題1 軟件項目目標的三個要素是什么？質(zhì)量（需求是根本），時間，成本2 理解IEEE對需求的定義。IEEE（電氣電子工程師協(xié)會）軟件工程標準詞匯表中定義需求為：（1）用戶解決問題或達到目標所需的條件或權(quán)能（Capability）。（2）系統(tǒng)或系統(tǒng)部件（組件）要滿足合同、標準、規(guī)范或其它正式規(guī)定文檔所需具有的條件或權(quán)能。（3）一種反映上面（1）或（2）所描述的條件或權(quán)能的文檔說明。對于這一定義的理解為：（1）條件：如CRM（客戶關(guān)系管理）系統(tǒng)，有CALL CENTER、市場開發(fā)管理、銷售管理、售后服務(wù)、統(tǒng)計分析、績效分析等等模塊，有滿足市場人員進行客戶關(guān)系管理的條件。 （2

2、）權(quán)能（能力）：系統(tǒng)的運算能力（速度和準確性）、系統(tǒng)平穩(wěn)運行能力、系統(tǒng)可配置能力。如，某一ERP系統(tǒng)，物料憑證到會計憑證的自動化，運算速度快、可靠性好。3 談?wù)勑枨笪臋n的重要性。案例一：中途更換所有的開發(fā)者，這就使得客戶需求從頭開始；重要性：如果只有一堆郵件、貼條、會談過幾次或一些零碎的對話，就確信已明白用戶的需求，那是難以做到的。案例二：某軟件開發(fā)小組所開發(fā)的一套工具缺少某一特定的功能重要性：這說明那怕需求明確無誤并構(gòu)思準確，如果我們沒有編寫文檔，軟件達不到期望目標也只能是咎由自取了。通過需求文檔回復(fù)設(shè)計人員提出的各類問題。依據(jù)需求對系統(tǒng)進行測試時，此系統(tǒng)不僅非常清晰地實現(xiàn)了所有必需功能，而

3、且未發(fā)現(xiàn)任何錯誤。4 好的需求特征有哪些？深入理解用戶的真正的意圖和需要。清晰完整的需求表達。借助需求分析工具，E-R圖、DFD圖、DD、UML工具等等。？使用科學的需求管理方法， 完善需求變更控制流程。5 軟件需求分析的目標是什么？軟件需求分析的目標是深入描述軟件的功能和性能，確定軟件設(shè)計的約束和軟件同其它系統(tǒng)元素的接口細節(jié)，定義軟件的其它有效性需求6 需求分析的任務(wù)是什么？需求分析的任務(wù)就是借助于當前系統(tǒng)（含手工作業(yè)）的邏輯模型導出目標系統(tǒng)的邏輯模型（如業(yè)務(wù)流程圖等），解決目標系統(tǒng)的 “做什么” 的問題。7 錯誤需求的代價有哪些？（1）錯誤的需求浪費了人力、物力，浪費了金錢，總之，浪費資源

4、。（2）影響軟件項目的成功，加大軟件項目的風險。（3）影響項目組及開發(fā)方形象，對用戶滿意度埋下“禍根”。（4）增加開發(fā)的成本。8 產(chǎn)生不合格需求的原因有哪些？（1）無足夠用戶參與。（2）用戶需求的不斷增加。（3）模棱兩可的需求。（4）過于精簡的規(guī)格說明。（5）忽略了用戶分類，如菜單驅(qū)動操作對高級用戶太低效了，但含義不清的命令和快捷鍵又會使不熟練的用戶感到困難（如SAP的事務(wù)代碼）。（6）不準確的計劃，往往低估開發(fā)時間。9. 好的軟件需求特性有哪些？理解其含義。內(nèi)涵一致，外延完整。具體包含兩個特征：一致性和全面性。引申為9個因素：（1） 無歧義因素（2）完整性因素（3）一致性因素（4）可檢驗性因

5、素（5） 確定性因素（6）可跟蹤性因素（7）正確性因素（8）可行性因素（9）必要性因素10. 理解需求層次的構(gòu)成，能識別業(yè)務(wù)需求、用戶需求、功能需求和非功能需求。軟件需求包括不同的層次：業(yè)務(wù)需求、用戶需求、功能需求和非功能需求。業(yè)務(wù)需求反映了組織機構(gòu)或客戶對系統(tǒng)、產(chǎn)品的高層次的目標要求，它們在項目視圖與范 圍文檔中予以說明。用戶需求文檔描述了用戶使用產(chǎn)品必須要完成的任務(wù)，使用實例文檔或場景描述中予以 明。功能需求定義了開發(fā)人員必須實現(xiàn)的軟件功能，使得用戶能完成他們的任務(wù)，從而滿足了 業(yè)務(wù)需求和用戶需求非功能需求描述了系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等11. 什么是需求的路線圖，理解特性和涉眾的

6、概念。需求路線：了解從用戶要求到軟件需求的一般路徑（從問題領(lǐng)域轉(zhuǎn)向解決方案領(lǐng)域）涉眾需要（必須解決的業(yè)務(wù)或運作問題的反映）系統(tǒng)特性（完成涉眾需要而提供的服務(wù)）軟件需求（面向電腦語言的需求方案）涉眾：涉眾是與要建設(shè)的業(yè)務(wù)系統(tǒng)相關(guān)的一切人和事。軟件或系統(tǒng)項目涉眾包括：客戶、用戶、需求分析員、開發(fā)人員、測試人員、文檔編制人員、項目經(jīng)理、法律人員、生產(chǎn)人員、市場營銷特性：所謂特性(feature)是指邏輯上相關(guān)的功能需求的集合，給用戶提供處理能力并滿足業(yè)務(wù)需求。第二章 軟件需求工程及其過程思考題9 什么是需求工程？了解其組成示意圖。需求工程是軟件工程的核心組成部分，是指應(yīng)用有效的技術(shù)、方法進行需求分析

7、，確定客戶需求，幫助分析和設(shè)計人員理解問題，并定義目標系統(tǒng)的一門學科。它把整個軟件需求工程研究領(lǐng)域劃分為需求開發(fā)和需求管理兩部分。10 需求管理活動的內(nèi)容有哪些？(1)定義需求基線（迅速制定需求文檔的主體）。(2)評審提出的需求變更、評估每項變更的可能影響從而決定是否實施它。(3)使當前的項目計劃與需求一致。(4)估計變更需求所產(chǎn)生影響并在此基礎(chǔ)上協(xié)商新的承諾（約定）。(5)讓每項需求都能與其對應(yīng)的設(shè)計、源代碼和測試用例聯(lián)系起來以實現(xiàn)跟蹤。(6)在整個項目過程中，跟蹤需求狀態(tài)及其變更情況。11 什么是軟件生命周期模型？軟件產(chǎn)品經(jīng)歷需求、分析、設(shè)計、實現(xiàn)、部署后，軟件將被使用并進入維護階段，直到

8、最后逐漸消亡。這樣一個過程，叫軟件生命周期模型。12 理解RUP二維開發(fā)模型。(第二章第22頁ppt）13 如何基于需求特點選擇生命周期模型？ 需求情況 瀑布 模型 螺旋模型 RAD 迭代模型需求容易定義或明確嗎？是否是否能在早期確定需求嗎？是否是是周期中需求經(jīng)常變化嗎？否是是是14 理解需求開發(fā)的迭代的過程圖。15 掌握需求開發(fā)過程框架的內(nèi)容（翻譯成中文）。注：這是我自己翻譯的結(jié)果，大家可以自己具體看看第2章的29頁，可能會有更加準確的翻譯。1 定義愿景和范圍2標識用戶類3 標識用戶代表4標識需求決策者5選擇啟發(fā)式技術(shù)6標識用例7排序用例8開發(fā)用例9指定質(zhì)量屬性10導出文檔的功能需求11需求

9、建模12審查需求規(guī)格13開發(fā)原型14設(shè)計架構(gòu)15給組件分配需求16開發(fā)測試用例17確認用例，功能需求，分析模型，原型 16 理解Pressman的需求工程過程及其使用的需求環(huán)境。需求獲取需求分析需求規(guī)格說明系統(tǒng)建模需求確認需求管理使用的需求環(huán)境：瀑布模型17 需求工程方法分成哪四類？1.面向過程，注重輸入輸出,如傳統(tǒng)的結(jié)構(gòu)化分析。2.面向數(shù)據(jù)，強調(diào)數(shù)據(jù)結(jié)構(gòu)，如E-R模型，DD描述。3.面向控制，強調(diào)同步、并發(fā)，如DFD圖。4.面向?qū)ο?，它建立在對象間的交互基礎(chǔ)上，對對象模型、動態(tài)模型和功能模型三個方面對問題進行描述，如以UML為基礎(chǔ)的Rose的建模工具。10.系統(tǒng)分析員的職責和技能有哪些？職責

10、：1. 收集、整理、分析、提煉、跟蹤、控制用戶的產(chǎn)品需求；2.編寫產(chǎn)品需求說明書，準確描述和解釋業(yè)務(wù)需求；3.編寫設(shè)計文檔，引導UI設(shè)計師制作產(chǎn)品原型（可選）；4.編寫詳細產(chǎn)品需求分析書，提供給軟件開發(fā)工程師，測試工程師。技能：（1）傾聽的技巧（2）交談和提問的技巧 （3）分析能力 （4）協(xié)調(diào)能力 （5）觀察能力 （6）寫作能力（7）組織信息能力 （8）人際交往能力 （9）8建模能力第三章 軟件需求獲取思考題1 需求獲取可以分成哪些活動？ 查找需求源（識別需求的涉眾）、網(wǎng)羅需求信息（收集各方面人員對產(chǎn)品的要求，得到“系統(tǒng)特性列表”）、整合需求信息2 客戶與開發(fā)人員的合作伙伴關(guān)系建立的前提是什么

11、？合作關(guān)系建立的前提：明確雙方權(quán)利和義務(wù)3 軟件需求工程中，SRS指什么？需求分析員對來自不同客戶的信息進行整理，把業(yè)務(wù)需求、業(yè)務(wù)規(guī)則、功能需求、質(zhì)量目標、解決方案的建議等內(nèi)容區(qū)分開來，形成SRS（軟件需求規(guī)格說明）。4 如何更好地讓客戶聽取對需求工作成果的解釋？需求分析員應(yīng)使用不同的示意圖來配合SRS文本對需求進行描述。 客戶可以要求分析人員解釋說明每個圖表的作用、符號的意義和需求開發(fā)工作的結(jié)果，以及怎樣檢查圖表有無錯誤及不一致等。5 對于MIS系統(tǒng)，通常情況下怎么樣的需求，其優(yōu)先級比較高？2. 關(guān)鍵任務(wù)需求、基礎(chǔ)性的數(shù)據(jù)處理要求，完不成此版本或下一版本需求就不能實現(xiàn)；只有這些需求實現(xiàn)后，客

12、戶才能接受軟件。關(guān)鍵任務(wù)需求優(yōu)先級為高。（2）業(yè)務(wù)流程處理中比較繁瑣、容易出錯，客戶特別希望能改進、簡化工作量、提高效率的業(yè)務(wù)需求，此類業(yè)務(wù)需求優(yōu)先級為中。（3）客戶的主管領(lǐng)導比較關(guān)心、容易得到領(lǐng)導認可的業(yè)務(wù)需求，此類業(yè)務(wù)需求優(yōu)先級為中。（4）最后才是某些非功能類需求，實現(xiàn)或不實現(xiàn)均可的，一般此類業(yè)務(wù)需求優(yōu)先級為低。6 如何理解需求確認中客戶的“簽字”？客戶代表把在需求文檔上簽字視作毫無意義的儀式。開發(fā)經(jīng)理把簽字作為凍結(jié)需求的方法。 簽字不僅僅是儀式，更重要的是建立需求協(xié)議的基線 。7 項目的范圍說明主要應(yīng)該包括以下三個方面的內(nèi)容？項目的合理性說明 （解釋為什么要實施這個項目）項目目標 （也就

13、是期望達到的產(chǎn)品或服務(wù)）項目可交付成果清單8 根據(jù)前景和范圍文檔，我們可以判斷出某項特性或需求是否包括在項目中，一般有哪三種情況？ 一種是被提議的需求明顯在范圍之外。另一種可能是需求顯然是在定義好的項目范圍之內(nèi)。第三種可能是被提議的新需求不再范圍之內(nèi)，但它很有價值，因而需要對項目范圍做出調(diào)整以容納這一新的需求。9 尋找客戶需求中，為征求客戶的意見，必須采取哪幾步？明確項目用戶需求的來源。明確使用該產(chǎn)品（軟件）的不同類型的用戶。與不同用戶類的代表進行溝通。遵從項目的最終決策者的意見。10 能舉出和理解四種以上的軟件需求來源。與潛在用戶進行交談和討論 描述現(xiàn)有產(chǎn)品或競爭產(chǎn)品的文檔系統(tǒng)需求規(guī)格說明現(xiàn)

14、有系統(tǒng)的問題報告和改進要求 市場調(diào)查和用戶問卷調(diào)查 觀察用戶如何工作用戶工作的情景分析 11 畫出客戶和用戶的層次結(jié)構(gòu)圖（2） 用戶代表（代言人）的作用是什么？為構(gòu)造客戶和開發(fā)人員之間的伙伴關(guān)系提供了有效途徑。是他所屬用戶類的成員與項目的需求分析員之間的主要聯(lián)系人。13理解不同情況下，需求“誰來做出決策”。如果是個別用戶之間的分歧，則由用戶代言人來裁決用戶經(jīng)理表述的需求和實際用戶需求相矛盾，此時應(yīng)該服從于用戶代言人開發(fā)人員對產(chǎn)品的想法和客戶要求不一致，此時應(yīng)該服從于客戶不同用戶類或客戶群的需求相矛盾，支持最重要的用戶類或?qū)ι虡I(yè)前景影響最大的客戶群不同的企業(yè)客戶有不同的需求，依據(jù)項目的業(yè)務(wù)目標來

15、確定哪些客戶對項目的成敗影響最大14調(diào)查研究的主要方法有哪些？用戶訪談收集和研究資料調(diào)查問卷實地觀察，即深入現(xiàn)場,跟班作業(yè)15問卷調(diào)查和用戶訪談的優(yōu)點和缺點各是什么？問卷調(diào)查：優(yōu)點：大量發(fā)放、快速、低成本，保護隱私（不記名），便于歸納整理。缺點：問卷不夠靈活（內(nèi)容局限）、信息質(zhì)量難于保證。用戶訪談：優(yōu)點：為分析人員提供了與訪談對象自由溝通的機會；通過訪談可以挖掘更深層次的用戶需求；訪談允許分析人員使用一些個性化的問題；成功的訪談在很大程度上取決于分析人員的經(jīng)驗與技巧；缺點：訪談?wù)加玫臅r間較多，訪談后的資料整理，也需要花費較多的時間。16各舉兩個例說明“業(yè)務(wù)規(guī)則”、“外部接口需求”和“數(shù)據(jù)定義”

16、、“約束”。業(yè)務(wù)規(guī)則（當客戶說只有特定用戶在特定條件下才能執(zhí)行某一動作時）：“如果一個藥劑師在危險化學制品培訓方面是可靠的，那么他就可以在一級危險藥品清單上訂購化學制品”“圖書館的借閱者最多可以同時借10本書?！蓖獠拷涌谛枨螅枋隽讼到y(tǒng)與外部世界的聯(lián)系）：“從<某些設(shè)備> 讀取信號” “以<某種格式>讀取文件”約束 （對設(shè)計和實現(xiàn)的約束合理地限制了開發(fā)人員可用的選擇）：“不能申請多于一定數(shù)量的內(nèi)存”“操作必須與<其它系統(tǒng)>相同或類似”數(shù)據(jù)定義：“郵政編碼” “物料序號” 17理解和說明用例法中的相關(guān)概念：用例、角色、主執(zhí)行者、場景。用例描述了系統(tǒng)與外部角色之

17、間的一系列交互。角色(用戶角色）指與系統(tǒng)交互以實現(xiàn)某種目的的人、軟件系統(tǒng)或硬件設(shè)備。提出請求的相關(guān)人員叫做主執(zhí)行者根據(jù)執(zhí)行者作出的請求和請求涉及的條件，系統(tǒng)將執(zhí)行不同的行為序列，每一行為序列 稱之為一個場景。第四章 結(jié)構(gòu)化的需求分析與建模思考題18 什么是需求分析模型？經(jīng)過對需求獲取的資料進行分析，并以此建立起來的模型稱之為需求分析模型。19 需求工程中，需求分析階段模型的作用有哪些？(1)幫助系統(tǒng)分析員理解系統(tǒng)的信息、功能和行為，使得需求分析任務(wù)更加容易實現(xiàn)，結(jié)果更加系統(tǒng)化。(2)它是評審焦點，是確定SRS完整性、一致性和精確性的重要依據(jù)。(3)它是設(shè)計的基礎(chǔ)，是軟件要素的表示視圖。20 理

18、解結(jié)構(gòu)化分析模型圖的組成。21 數(shù)據(jù)模型包括哪三種互相關(guān)聯(lián)的信息？數(shù)據(jù)對象、描述數(shù)據(jù)對象的屬性和數(shù)據(jù)對象相互連接的關(guān)系5-9題ppt上面有很多的實例22 掌握E-R的畫法，能根據(jù)背景編制E-R圖，或根據(jù)E-R圖描述其中的數(shù)據(jù)對象、屬性和關(guān)系。23 掌握DFD圖的畫法，能根據(jù)背景材料編制DFD圖，或根據(jù)DFD描述其數(shù)據(jù)流。24 掌握STD的畫法，能根據(jù)背景材料編制STD圖。25 能根據(jù)DFD圖的某圖形元素，編寫其數(shù)據(jù)詞典。26 理解結(jié)構(gòu)語言，能根據(jù)處理邏輯的描述，編制判定樹和判定表。第五章 面向?qū)ο蠓治雠c建模思考題11 UML是由什么構(gòu)成的？ 視圖（views）、圖（diagrams）、模型元素

19、（Model elements）、通用機制（general mechanism）等構(gòu)成。12 UML用到的圖包括哪些？理解各圖的作用。名稱 作用 用例圖描述角色與系統(tǒng)中的用例關(guān)系類圖描述類及關(guān)系對象圖類對象實例狀態(tài)圖描述類對象的狀態(tài)及引起狀態(tài)變化的事件，對類的補充。序列圖反映若干對象之間的動態(tài)協(xié)作狀態(tài)，隨時間流逝，對象間如何交互的。協(xié)作圖描述對象的關(guān)系及傳遞的消息活動圖反映一個連續(xù)活動流，顯示動作和結(jié)果，尤其能表示并發(fā)和同步組件圖反映代碼的物理結(jié)構(gòu)包圖多個組件組合成包圖。布署圖 描述系統(tǒng)軟件和硬件的物理架構(gòu)13 可以根據(jù)場景畫出活動圖和序列圖。14 用例模型是由哪些組成的？ 執(zhí)行者、用例、用例

20、與執(zhí)行者的關(guān)系（通信關(guān)聯(lián)：執(zhí)行者與執(zhí)行的用例之間存在通信路徑。）、用例與用例的關(guān)系15 用例間的關(guān)系有哪些？包含、擴展、泛化16 能夠根據(jù)背景畫出用例圖。17 理解包圖的作用。UML包圖是表示頂層架構(gòu)的適當機制。包是對類進行分組的一種機制，包的劃分是實現(xiàn)“分而治之”的重要手段，將關(guān)系比較密切的關(guān)聯(lián)類放在同一個包中。18 用例模型包括什么？用例規(guī)約由什么組成？用例模型包括用例圖和用例規(guī)約。用例規(guī)約的組成：簡要說明：介紹該用例的作用和目的。事件流：包括基本事件流和異常事件流。特殊需求：非功能性需求和設(shè)計約束前置條件：執(zhí)行用例之前系統(tǒng)必須所處的狀態(tài)。后置條件：用例執(zhí)行完畢后系統(tǒng)可能處于的狀態(tài)。19

21、軟件頂層架構(gòu)有哪四種模式？客戶/服務(wù)器模式模型視圖控制器模式分層模式流程處理模式20 什么是類圖？類圖中類的關(guān)系有哪幾種？UML類圖是表示領(lǐng)域(指業(yè)務(wù)領(lǐng)域)概念模型的適當機制類之間的關(guān)系：實現(xiàn)：如基類實現(xiàn)接口。泛化：抽象和具體，如交通工具和自行車。關(guān)聯(lián)：類之間的相關(guān)性，包括聚集和組成關(guān)系。依賴：是關(guān)聯(lián)的弱化。21 理解并能說明原型法的工作流程。用戶提出要求識別歸納問題開發(fā)系統(tǒng)原型 分析評價不可行處理不滿意處理修改試運行 第六章 需求分析文檔編制思考題（6） 需求開發(fā)的最終成果是什么？需求開發(fā)的最終成果是，在客戶和開發(fā)小組對所要開發(fā)的產(chǎn)品達成共識后，所編寫的具體文檔(這一文檔綜合了業(yè)務(wù)需求、用戶

22、需求和軟件功能需求。)（7） 表示軟件需求最常用和最普遍的方式是什么？文檔、圖形化模型、形式化規(guī)格說明（8） SRS指什么？舉例（四個以上）說明如何增強SRS的可讀性。對節(jié)、小節(jié)和單個需求的標記格式必須一致靈活地使用各種可視強調(diào)標志創(chuàng)建目錄表，也許還需要創(chuàng)建索引，這有助于讀者找到他們所需要的信息。對所有圖和表進行編號，并且給出標題，根據(jù)編號來引用這些圖和表。使用合適的模板來組織所有的必要信息（9） 需求標識方法有哪幾種？各舉一例。需求標識方法：1. 序列號 ：如UR-2,SRS13 2. 層次型編號 ：如“第3.2.5部分編輯功能”3. 層次型文本標簽 ：如“當用戶請求打印超過10個副本時，系

23、統(tǒng)必須讓用戶進行確認判斷?！北粯俗R為“”（10） 理解TBD的含義。3. 使用TBD符號（待定）作為標準指示器來強調(diào)軟件需求分析規(guī)格說明書中這些需求的缺陷。 （2）把每個TBD編號并創(chuàng)建一個TBD列表，這有助于方便地跟蹤每個項目（11） 理解軟件需求規(guī)格說明模板中每個標題的含義及說明。1. 引言 2. 總體描述 3. 系統(tǒng)特性 4. 外部接口需求 5. 其他非功能性需求6. 其他需求 7. 附錄A：術(shù)語表 8. 附錄B：分析模型 9. 附錄C：待確定問題的清單（12） 能根據(jù)軟件需求編寫原則，改進需求內(nèi)容的表述。(實例在ppt上）第七章 需求驗證與評審思考題27 軟件需求驗證活動要確定哪幾方面

24、的內(nèi)容？軟件需求規(guī)格說明正確描述（無二義性和模糊內(nèi)容）了預(yù)期的系統(tǒng)行為和特征。從系統(tǒng)需求或其它來源中得到軟件需求。需求是完整的和高質(zhì)量的。對需求的看法是一致的。需求為繼續(xù)進行產(chǎn)品設(shè)計、構(gòu)造和測試提供了足夠的基礎(chǔ)。28 兩種最重要的驗證技術(shù)是什么？正式的需求評審：遵循預(yù)先定義好的一系列步驟過程。正式評審內(nèi)容需要記錄在案，它包括確定材料、評審員、評審小組，對產(chǎn)品是否完整，對所發(fā)現(xiàn)的錯誤和所提出的問題的總結(jié)。非正式的需求評審：把工作產(chǎn)品分發(fā)給許多其它的開發(fā)人員粗略看看,或者走過場似地檢查一遍(walkthrough) ，執(zhí)行者描述產(chǎn)品，且征求意見，不需要記錄備案。優(yōu)點：培養(yǎng)其他人對產(chǎn)品的認識，并且有

25、利于獲得反饋意見缺點：非系統(tǒng)化的，不徹底的29 理解并能畫出審查過程階段圖。 重寫30 理解各種評審員的角色。作者（介紹員）、調(diào)解者（主持者）、讀者（評審員）、記錄員31 能根據(jù)案例背景，判斷評審問題的原因。（詳細的例子在ppt第七章19-22頁）32 為做好需求評審，能理解并舉出七例以上的合理建議。分層次評審 正式評審與非正式評審結(jié)合 分階段評審 精心挑選評審員對評審員進行培訓 充分利用需求評審檢查單 建立標準的評審流程 做好評審后的跟蹤工作 充分準備評審第八章 需求管理思考題33 理解需求基線的含義和內(nèi)容。典型需求開發(fā)的結(jié)果應(yīng)該有項目視圖和范圍文檔、用例文檔、軟件需求規(guī)格說明及相關(guān)分析模型。經(jīng)評審批準，這些文檔就定義了開發(fā)工作的需求基線。34 需求管理在CMM2中的目標是什么？通過什么來管理文檔？ 其目標是：(1)建立軟件需求基線，供軟件工程和管理使用。(2)軟件計劃、產(chǎn)品和活動同軟件需求保持一致。通過版本控制和變更控制來管理需求文檔。35 理解并舉例說明版本控制混亂導致的問題。版本控制的混亂，將導致項目