項目需求工程V1.

1、項目需求項目需求工程工程2-65故事故事1 131243-65故事故事1 1唯一不變的只有變化本身！ Frederick Brooks 人月神話5677用戶或市場人員很難能夠清楚地描述自己的需求，且需求在不斷變化！需求很難獲??！4-65故事故事2 21.銷售的承諾2.客戶提及的需求3.項目經(jīng)理理解的需求4.設(shè)計人員的設(shè)計5.程序員完成的代碼123456789106. 文檔7. 安裝包8. 成本9. 支持10.客戶真正需要的東西需求的理解，仁者見仁智者見智（差異）！需求很難管控！5-65需求的重要性需求的重要性軟件開發(fā)中的問題：6-65需求的重要性需求的重要性需求問題代價/p>

2、需求設(shè)計編碼單元測試驗收測試系統(tǒng)維護(hù)1個需求錯誤的代價=5個設(shè)計失誤的代價= =200個系統(tǒng)維護(hù)的代價需求如此重要-是項目成敗的重要原因！項目需求需要進(jìn)行科學(xué)的管理！7-65什么是需求？8-65需求的定義需求的定義什么是需求？IEEE軟件工程標(biāo)準(zhǔn)詞匯表 用戶解決問題或達(dá)到目標(biāo)所需要的條件或者能力。 系統(tǒng)或者系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或者其他正式規(guī)定文檔所需要的條件或者能力。 一種反應(yīng)以上 或 所描述的條件或能力的文檔說明。9-65需求層次需求層次產(chǎn)品需求規(guī)格說明書u 需求層次10-65需求層次概念需求層次概念反映了組織機(jī)構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，它們在項目視圖與范圍文檔中予以說

3、明。業(yè)務(wù)需求文檔描述了用戶使用產(chǎn)品必須要完成的任務(wù)，這在用例文檔或方案腳本說明中予以說明。用戶需求定義了開發(fā)人員必須實現(xiàn)的軟件功能，使得用戶能完成他們的任務(wù)，從而滿足了業(yè)務(wù)需求。功能需求11-65需求層次差異需求層次差異n 業(yè)務(wù)需求: 系統(tǒng)應(yīng)該做什么的高層描述說明開發(fā)軟件的目的、業(yè)務(wù)原理、戰(zhàn)略、愿景、范圍和期望的價值作為項目的指導(dǎo)和用戶需求的基礎(chǔ)n 用戶需求: 詳細(xì)的業(yè)務(wù)需求 要執(zhí)行的任務(wù)描述 需要滿足用戶的功能n 軟件需求: 高層架構(gòu)功能和非功能需求定義系統(tǒng)內(nèi)的功能和特性詳細(xì)架構(gòu)、設(shè)計和測試計劃的來源不同需求規(guī)格的重點12-65需求層次實例解釋需求層次實例解釋可能是：“用戶能夠有效地糾正文檔

4、中的拼寫錯誤”，該產(chǎn)品的包裝盒封面上可能表明“這是個滿足業(yè)務(wù)需求的拼寫檢查器”。業(yè)務(wù)需求可能是：“找出文檔中的拼寫錯誤，并通過一個提供的替換列表來供選擇替換拼寫的詞”。用戶需求還有其他功能需求，如：找到并高亮提示錯詞的操作；顯示提供替換詞的對話框，以及實現(xiàn)整個文檔范圍的替換。功能需求u 一個字處理程序例子一個字處理程序例子13-65需求開發(fā)需求開發(fā)需求收集模型需求收集模型n 無關(guān)需求:n客戶對這類需求是否實現(xiàn)不太關(guān)心。實現(xiàn)這類需求會增加不必要的成本，并且也會帶來風(fēng)險。n 基本需求:n基本需求是客戶認(rèn)為在產(chǎn)品中應(yīng)該滿足的需求。如果產(chǎn)品沒有滿足這些基本需求，顧客就很不滿意。相反，當(dāng)產(chǎn)品滿足基本需求

5、時，也不會提升客戶滿意度。 n 期望需求:n這類需求在產(chǎn)品中實現(xiàn)得越多，客戶就越滿意。所以這類需求實現(xiàn)得越多越好，它可能成為戰(zhàn)勝其他產(chǎn)品的決定性因素。n 魅力需求:n如果這類需求沒有被實現(xiàn)，客戶不會不滿意，但是如果產(chǎn)品滿足了這類需求，客戶就會對產(chǎn)品非常滿意。 這些需求會使產(chǎn)品與競爭對手的產(chǎn)品區(qū)分開來，并且可以提升價值和價格。需求的類型與定義功能不全卡諾圖魅力需求期望需求基本需求滿意的客戶不滿意的客戶功能完備14-65需求如何獲??？需求如何管理？15-65需求工程需求工程需求開發(fā)需求獲取需求分析需求文檔編寫需求驗證需求管理需求變更版本控制需求跟蹤需求狀態(tài)跟蹤需求工程n需求工程：指應(yīng)用已證實有效的

6、技術(shù)、方法進(jìn)行需求分析，確定客戶需求，幫助分析人員理解問題并定義目標(biāo)系統(tǒng)的所有外部特征的一門學(xué)科。需求工程，是一個不斷反復(fù)的需求定義、文檔記錄、需求演進(jìn)的過程，并最終在驗證的基礎(chǔ)上凍結(jié)需求。n需求工程分為需求開發(fā)過程和需求管理過程。u 需求獲取及管理的科學(xué)方法需求工程16-65需求開發(fā)與需求管理的關(guān)系需求開發(fā)與需求管理的關(guān)系需求開發(fā)需求管理Requirement Development（需求開發(fā)）17-65需求開發(fā)需求獲取需求分析需求文檔編寫需求驗證需求管理需求變更版本控制需求跟蹤需求狀態(tài)跟蹤需求工程18-65需求開發(fā)需求開發(fā)流程流程確認(rèn)并驗證需求通過驗證的需求軟件需求開發(fā)軟件需求業(yè)務(wù)需求記錄

7、業(yè)務(wù)需求開發(fā)用戶需求用戶需求分析需求分析后的需求19-65需求開發(fā)需求開發(fā)n 開發(fā)客戶需求收集干系人需要、期望、限制和接口的要求并翻譯成客戶需求。n 需求開發(fā)過程需求收集：在生命周期的各個階段收集干系人需要、期望、限制和接口的要求。需求轉(zhuǎn)換：將收集到的要求轉(zhuǎn)換成客戶需求。20-65需求開發(fā)需求獲取需求分析需求文檔編寫需求驗證需求管理需求變更版本控制需求跟蹤需求狀態(tài)跟蹤需求工程21-65需求獲取需求獲取 歸納和整理用戶提出的各種問題和要求； 弄清用戶企圖通過軟件達(dá)到的目的； 借助各種工具和方法，陳述用戶提出的實際需求，并標(biāo)定軟件的作用范圍。u 需求獲取主要工作最終目的弄明白要“做什么”。22-6

8、5需求獲取需求獲取 確定產(chǎn)品的不同用戶類型 確定用戶需求的來源 挑選出每一類用戶和其他涉眾的代表并與他們一起工作 分析誰是項目需求的決策者（干系人）u 獲取需求應(yīng)采用的步驟23-65需求獲取需求獲取n 客戶購買產(chǎn)品的人n 用戶使用產(chǎn)品的人n 向誰收集需求？u 干系人客戶 VS 用戶需求收集對象n 對于項目n 對于產(chǎn)品 甲方 甲方客戶、用戶 合作方 客戶、用戶 市場部門 已有產(chǎn)品的競爭對手 合作伙伴 24-65需求獲取需求獲取u 需求分析中重要內(nèi)容接口需求識別25-65需求獲取需求獲取u 引導(dǎo)需求六邊形法則26-65需求獲取需求獲取 組織結(jié)構(gòu)：企業(yè)為進(jìn)行相應(yīng)的業(yè)務(wù)流程所做的人員的組織安排。 業(yè)務(wù)

9、流程：企業(yè)開展業(yè)務(wù)所必須的各個環(huán)節(jié)及在每個環(huán)節(jié)中的具體做法。 業(yè)務(wù)數(shù)據(jù)：企業(yè)內(nèi)部經(jīng)營信息的存儲和流動形式。 業(yè)務(wù)地點分布：反映企業(yè)在什么地方開展業(yè)務(wù)以及業(yè)務(wù)流程中的各個環(huán)節(jié)之間的地點關(guān)系。 業(yè)務(wù)應(yīng)用：企業(yè)以什么樣的應(yīng)用軟件處理業(yè)務(wù)流程中的各個環(huán)節(jié)。 技術(shù)基礎(chǔ)設(shè)施：企業(yè)在信息技術(shù)基礎(chǔ)設(shè)施上的狀況。u 需求調(diào)研的六邊形法則27-65需求獲取需求獲取n 深入淺出對企業(yè)的需求調(diào)研，要盡可能的全面、細(xì)致，調(diào)研的需求是個全集系統(tǒng)真正實現(xiàn)的各個子集。調(diào)研的細(xì)致，并不等于在分析時，面面俱到地將調(diào)研的內(nèi)容全部納入到系統(tǒng)中, 而有可能實現(xiàn)的很少。n 以流程為主線應(yīng)該用流程將所有的內(nèi)容串起來，如單據(jù)、信息、組織結(jié)構(gòu)

10、、處理規(guī)則等；流程的描述既要有宏觀，又要有微觀。28-65需求獲取需求獲取 制定并落實調(diào)研計劃 在調(diào)研前和用戶講清楚調(diào)研的意義、過程、以及需要注意的問題 發(fā)問時以一人為主,其他人注意記錄與查找問題 在用戶講解時,不要中斷用戶,使對方有充分的演說機(jī)會 對詢問的問題要有記錄，記錄要點u 需求獲取過程中的注意事項29-65需求獲取需求獲取和用戶進(jìn)行訪談和調(diào)研，通常是適用于任何環(huán)境下的最重要、最直接的方法之一。通過幾次這樣的訪談，開發(fā)人員和系統(tǒng)分析員能獲得一些問題域中的知識，對要解決的問題有進(jìn)一步的理解。u 需求獲取方法1訪談和調(diào)研30-65需求獲取需求獲取專題討論會，是一種可用于任何情況下的軟件需求

11、調(diào)研方法。專題討論會的目的：是鼓勵軟件需求調(diào)研并且在很短的時間內(nèi)對討論的問題達(dá)成一致。專題討論會一般由開發(fā)團(tuán)隊的成員主持，主要討論系統(tǒng)應(yīng)具備的特征或者評審系統(tǒng)特性。專題討論會前的準(zhǔn)備工作是能否成功的舉行會議的關(guān)鍵。u 需求獲取方法2專題討論會31-65需求獲取方法需求獲取方法3 3腦力風(fēng)暴，是一種獲取新觀點或創(chuàng)造性的解決方案，非常有用的方法。通常，專題討論會的一部分時間是用于進(jìn)行腦力風(fēng)暴，找出關(guān)于軟件系統(tǒng)的新想法和新特征。 腦力風(fēng)暴包括兩個階段：想法產(chǎn)生階段和想法精化階段。u 需求獲取方法3腦力風(fēng)暴32-65需求開發(fā)需求獲取需求分析需求文檔編寫需求驗證需求管理需求變更版本控制需求跟蹤需求狀態(tài)跟

12、蹤需求工程33-65需求分析需求分析n 需求分析包括提煉、分析和仔細(xì)審查已收集到的需求，為最終用戶所看到的系統(tǒng)建立一個概念模型，以確保所有的風(fēng)險承擔(dān)者都明白其含義并找出其中的錯誤、遺漏或其它不足的地方。n 分析用戶需求應(yīng)該執(zhí)行以下活動：繪制系統(tǒng)關(guān)聯(lián)圖分析需求可行性確定需求的優(yōu)先級別為需求建立模型創(chuàng)建用戶接口原型建立數(shù)據(jù)字典u 需求分析34-65需求分析需求分析u 分析需求準(zhǔn)則 完整性：完整描述即將交付使用的功能 正確性：經(jīng)過用戶或用戶信任的代理人審閱 可行性：在已知能力和約束條件中實現(xiàn) 必要性：每項需求記錄的功能都應(yīng)是用戶真正需要的 有優(yōu)先次序：提供了實現(xiàn)優(yōu)先級 無歧義：對所有讀者只有一種一致

13、的解釋 可驗證性：可以設(shè)計測試方法來檢查35-65需求分析需求分析問答分析方法 問答分析方法很簡單：刨根究底地問，如果問題都被解答了，那么需求也就分析清楚了。一個人可以“自問自答”地分析需求，幾個人分析需求則稱為“研討”。 問答分析最重要的問題是：“是什么”和“為什么”。每個需求都應(yīng)當(dāng)用陳述句說明“是什么”，如果“是什么”的內(nèi)涵不夠清晰，則應(yīng)補(bǔ)充說明“不是什么”。如果“是什么”和“不是什么”并不是“理所當(dāng)然”的，那么應(yīng)當(dāng)解釋“為什么”，以便加深讀者的理解。追究“是什么”和“為什么”的目的是獲得正確、清楚的需求。 其它常見的問題有： 需求存在二義性嗎？ 需求文檔的上下文有矛盾嗎？ 需求完備嗎？

14、需求是必要的嗎？ 需求可實現(xiàn)嗎？ 需求可驗證嗎？ 需求的優(yōu)先級確定了嗎？ u 需求分析方法1問答分析法36-65需求分析需求分析軟件需求分析者利用場景或經(jīng)歷來描述用戶和軟件系統(tǒng)的交互方式，并以此來獲取軟件需求。使用用例的分析方法來源于面向?qū)ο蟮乃枷搿Ｓ美治龇椒ㄗ畲蟮奶攸c在于面向用例，在對用例的描述中引入了場景、角色的概念。u 需求分析方法2用例分析法原型法是為了快速開發(fā)系統(tǒng)而推出的一種開發(fā)模式，旨在改進(jìn)傳統(tǒng)的結(jié)構(gòu)化生命周期法的不足，縮短開發(fā)周期，減少開發(fā)風(fēng)險。u 需求分析方法3原型分析法37-65需求開發(fā)需求獲取需求分析需求文檔編寫需求驗證需求管理需求變更版本控制需求跟蹤需求狀態(tài)跟蹤需求工程

15、38-65需求規(guī)格說明書編寫需求規(guī)格說明書編寫u 需求規(guī)格說明書編寫軟件需求規(guī)格說明，是闡述一個軟件系統(tǒng)必須提供的功能和性能，以及它所要考慮的限制條件,它不僅是系統(tǒng)測試和用戶文檔的基礎(chǔ)，也是所有子系列項目規(guī)劃、設(shè)計和編碼的基礎(chǔ)。需求分析完成的標(biāo)志是提交一份完整的軟件需求規(guī)格說明書。軟件需求規(guī)格說明作為產(chǎn)品需求的最終成果必須包括所有的需求。在開發(fā)人員的組織中要為編寫軟件需求文檔定義一種標(biāo)準(zhǔn)模板。要求：正確：正確地反映用戶的真實意圖；清楚：易讀易懂；無二義性完備:沒有遺漏一些必要的需求；可實現(xiàn)： “可實現(xiàn)”意味著在技術(shù)上是可行的，并且滿足時間、費(fèi)用、質(zhì)量等約束；確定優(yōu)先級：確定高中低三個級別，將風(fēng)

16、險降到最低。闡述“做什么”而不是“怎么做”39-65需求規(guī)格說明書編寫需求規(guī)格說明書編寫u 需求規(guī)格說明書模板40-65需求開發(fā)需求獲取需求分析需求文檔編寫需求驗證需求管理需求變更版本控制需求跟蹤需求狀態(tài)跟蹤需求工程41-65需求驗證需求驗證驗證是為了確保需求說明準(zhǔn)確、無二義性，并完整地表達(dá)系統(tǒng)功能以及必要的質(zhì)量特性。需求驗證要求客戶代表和開發(fā)人員共同參與，對提交后的需求規(guī)格說明進(jìn)行驗證，分析需求的正確性，完整性以及可行性等。需求驗證中的活動一般包括：審查需求文檔以需求為依據(jù)編寫測試用例編寫用戶手冊確定合格的標(biāo)準(zhǔn)最后的簽字u 需求驗證42-65需求管理需求管理u 管理需求Manage Requ

17、irements（ 管理需求）獲取和理解需求獲取對需求的承諾管理需求變更維護(hù)需求的雙向可跟蹤性識別工作產(chǎn)品和需求的跟蹤跟蹤距陣需求43-65需求管理需求管理n 獲取對需求的理解與需求提供者就需求的含義，對系統(tǒng)開發(fā)的需求進(jìn)行理解n 獲取對需求的承諾從項目的參與者處獲取承諾n 管理需求變更當(dāng)需求在項目中逐漸被開發(fā)時，管理需求變更n 維護(hù)雙向的需求跟蹤在需求和工作產(chǎn)品之間維護(hù)雙向的可跟蹤性n 識別項目工作和需求之間的不一致識別存在與項目計劃、工作產(chǎn)品和需求之間的不一致u 需求管理44-65需求管理需求管理u 需求管理的原則及主線n 建立需求基線n 控制對需求基線的變更n 保持項目計劃與需求一致n 控

18、制單個需求及需求文檔的版本情況n 管理需求和聯(lián)系鏈之間的聯(lián)系或管理單個需求和其它項目可交付品之間的依賴關(guān)系。n 跟蹤基線中需求的狀態(tài)（已實現(xiàn)、已驗證、已刪除等）注釋：基線，是在軟件工程環(huán)境中，基線是指在軟件開發(fā)過程中的里程碑，這些里程碑的標(biāo)志是一項或多項經(jīng)過正式的技術(shù)評審并一致認(rèn)同的軟件制品的提交。45-65需求管理需求管理u 需求管理版本控制n 版本控制是管理需求的一個必要方面。n 需求文檔的每一個版本必須被統(tǒng)一確定。n 組內(nèi)每個成員必須能夠得到需求的當(dāng)前版本，必須清楚地將變更寫成文檔，并及時通知到項目開發(fā)所涉及的人員。例： 一位開發(fā)人員在項目的每周例會上說：“我終于實現(xiàn)了庫存報告中重排序的

19、功能?！表椖抗芾碚哒f：“噢，用戶在兩周前就取消這個功能了。你沒看改過的軟件需求規(guī)格說明嗎？”46-65需求管理需求管理u 需求管理需求變更管理n 是否給予變更，誰來判斷n 明確變更緊急程度，緊急變更立即處理n 變更影響分析n 不緊急變更批量處理，建議分三批需求形成基線前設(shè)計完成前試運(yùn)行完成前47-65需求管理需求管理u 需求管理需求跟蹤n 目的：建立和維護(hù)從用戶需求到測試的一致性與完整性，確保實現(xiàn)都以客戶需求為基礎(chǔ)，實現(xiàn)的需求覆蓋了預(yù)期的需求，并確保輸出與用戶需求的符合性。n 作用：在需求驗證中，便于確保所有需求被應(yīng)用有助于變更影響分析便于需求的維護(hù)便于測試時找出問題所在便于項目跟蹤和減少項目

20、風(fēng)險簡化了系統(tǒng)再設(shè)計，易于軟件重用48-65需求管理需求管理u 需求管理需求狀態(tài)跟蹤n 在整個開發(fā)過程中，跟蹤每個需求的狀態(tài)是需求管理的一個重要方面。n 建議的需求狀態(tài)表：狀態(tài)值定義已建議該需求已被有權(quán)提出需求的人建議已批準(zhǔn)該需求已被分析，估計了其對項目余下部分的影響（包括成本和對項目其余部分的干擾），已用一個確定的產(chǎn)品版本號或創(chuàng)建編號分配到相關(guān)的基線中，軟件開發(fā)團(tuán)隊已同意實現(xiàn)該項需求。已實現(xiàn)已實現(xiàn)需求代碼的設(shè)計、編寫和單元測試已驗證使用所選擇的方法驗證了實現(xiàn)的需求，例如測試和檢測，審查該需求跟蹤與測試用例相符。該需求現(xiàn)在被認(rèn)為完成。已刪除計劃的需求已從基線中刪除，但包括一個原因說明和做出刪除

21、決定的人員49-65案例分析50-65案例分析案例分析本節(jié)以本節(jié)以HRMS（Human Resource Manage System）的系統(tǒng)為例，介紹需求的開發(fā)和管理過程。的系統(tǒng)為例，介紹需求的開發(fā)和管理過程。51-65案例分析案例分析HRMSHRMS系統(tǒng)中的需求分類系統(tǒng)中的需求分類52-65案例分析案例分析 以用例分析方法進(jìn)行需求分析，對于每個Use Case，創(chuàng)建用戶接口說明文檔和Use case報告，同時建立這個用例的原型。u 需求分析53-65案例分析案例分析 角色1: 員工（Employee） 角色2: 雇用經(jīng)理（Hiring Manager） 角色3: 部門經(jīng)理（Departmen

22、t Manager） 角色4: 上級（Superior） 角色5: 分區(qū)經(jīng)理（Division Manager） 角色6: 運(yùn)行官（Operation Head） 角色7: 申請人（Applicant） 角色8: 人力資源經(jīng)理（HR Manager） 角色9: 培訓(xùn)經(jīng)理（Training Administrator） 角色10: 培訓(xùn)中心經(jīng)理（Training Center）u 需求分析HRMS中的角色54-65案例分析案例分析 用例1：招聘員工（Recruit Employee） 用例2：候選人分類（Categorize Candidate） 用例3：更新面試信息（Update Interv

23、iew） 用例4：確認(rèn)候選人（Confirm Candidate） 用例5：管理申請（Manage Requisition） 用例6：記錄申請者信息（Register Applicant Data） 用例7：修改申請者信息（Modify Applicant Data） 用例8：確認(rèn)申請信息（Validate Application）u 需求分析分析用例55-65案例分析案例分析n 為系統(tǒng)中的每個用例編寫Use Case報告，則系統(tǒng)分析與設(shè)計人員可以更加清晰的掌握系統(tǒng)架構(gòu)。u 需求分析編寫Use Case報告n 格式如下：創(chuàng)建員工記錄簡短描述場景事件流特殊需求執(zhí)行前條件執(zhí)行后結(jié)果Use case

24、圖56-65案例分析案例分析u 需求管理n 需求變更管理建立需求基準(zhǔn)版本和需求控制版本文檔。所有的需求文檔都要進(jìn)行版本控制，文檔要包含文檔類型、名稱、創(chuàng)建者、創(chuàng)建時間、修改者、修改時間、版本號、評審人員等信息。在開發(fā)HRMS中，提交的需求文檔包括用戶界面說明文檔、Use Case報告、Glossary文檔、軟件開發(fā)計劃、Use Case模型調(diào)研以及補(bǔ)充說明。所有的文檔采用統(tǒng)一的編號規(guī)則和命名規(guī)則。n 文檔編號規(guī)則系統(tǒng)名縮寫“_”文檔類型縮寫_模塊名縮寫“_”編號版本號（后文沒有+版本號）。n 文檔命名規(guī)則文檔類型“_”文檔名“_”版本號。 57-65需求工程總結(jié)58-65需求工程總結(jié)需求工程總

25、結(jié)1 1u 需求開發(fā)和需求管理的分界線59-65需求工程總結(jié)需求工程總結(jié)2 2u 國內(nèi)項目面臨的最主要問題n 客戶普遍不成熟：項目范圍定義不確切，缺乏對項目范圍、進(jìn)度、成本、質(zhì)量的平衡需求頻繁變更主要人員的變動是項目最大風(fēng)險n 項目團(tuán)隊不成熟：項目經(jīng)理多為技術(shù)出身，普遍缺乏管理意識和管理方法培訓(xùn)不能正確識別項目相關(guān)干系人并管理其參與項目組成員工作勤奮但普遍缺乏正確方法人員變動是項目經(jīng)理最頭疼的問題60-65需求工程總結(jié)需求工程總結(jié)3 3u 我們需要客戶方如何做n 調(diào)查前需要客戶方落實調(diào)研計劃，確定參加調(diào)研人員，時間，地點，并通知其調(diào)研內(nèi)容（同時要考慮人員變動的備選方案）n 需要甲方確立內(nèi)部項目組需求負(fù)責(zé)人n 準(zhǔn)備調(diào)研所用資源會議室白板投影儀n 及時組織內(nèi)部人員與乙方確認(rèn)調(diào)研成果61-65需求工程總結(jié)需求工程總結(jié)4 4u 需要客戶方如何配合n 作為客戶方，如何做？了解乙方需求變更流程，并與乙方就此流程達(dá)成一致；指定專人負(fù)責(zé)需求變更；內(nèi)部形成一個需求變更流程；針對內(nèi)部提交的需求變更，在提交乙方之前橫向分析對業(yè)務(wù)的影響；在提交乙方之前，內(nèi)部達(dá)成一致意見；需求變更必將導(dǎo)致乙方開發(fā)成本的增加，為保證項目