需求管理制度V0

1、零壹移動(dòng)互聯(lián)需求治理制度2.0版,2021年擬制人肖波日期20210630審核人日期批準(zhǔn)人日期修改記錄日期版本作者/修改者描述審核人20210701V2.0肖波修改需求開發(fā)治理流程與相關(guān)人員 分工目錄第一章總那么3第二章責(zé)任與分工3第三章需求總體說明4第四章需求提交7第五章需求評估7第六章需求開發(fā)10第七章系統(tǒng)測試11第八章需求上線13第九章生產(chǎn)問題治理14第十章需求變更限制與治理14第十一章需求進(jìn)度監(jiān)控及查詢17第十二章附那么17第一章總那么第一條 為標(biāo)準(zhǔn)零壹移動(dòng)互聯(lián)以下簡稱“零壹需求治理,明確各階段的工作內(nèi)容、處理流程、參與人員以及相關(guān)干系人的責(zé)任,在保證需求質(zhì)量的同時(shí),提升需求實(shí)現(xiàn)效率,

2、特制 訂本制度.第二條本制度適用于研發(fā)部的所有系統(tǒng)開發(fā)需求.第三條 本制度適用的讀者包括需求開發(fā)負(fù)責(zé)人、需求提交人員、需求評估人員、開發(fā)人員、測試人員、生產(chǎn)運(yùn)維人員、工程治理員等.第二章責(zé)任與分工第四條責(zé)任分工角色責(zé)任需求提交人員1 .負(fù)責(zé)需求調(diào)研與編輯、編寫業(yè)務(wù)需求申請表、提交業(yè)務(wù)需求審批.2 .根據(jù)需求評審和評估意見,及時(shí)修改業(yè)務(wù)需求,開發(fā)給需求相關(guān)干 系人.3 .配合需求開發(fā)、測試人員提供業(yè)務(wù)知識(shí)的支持.4 .協(xié)助確認(rèn)需求開發(fā)結(jié)果.5 . 負(fù)責(zé)需求上線后驗(yàn)證工作.工程治理人員1 .負(fù)責(zé)需求審批、評估、技術(shù)文檔評審、測試、上線等需求治理流程 的整體協(xié)調(diào)工作.2 .組織需求評估會(huì)議.3 .處

3、理測試申請-提交測試部門進(jìn)行分配與測試.4 .維護(hù)需求信息、跟進(jìn)需求變更以及需求處理進(jìn)展,定期向相關(guān)領(lǐng)導(dǎo)、部門匯報(bào)需求進(jìn)展.需求開發(fā)負(fù)責(zé)人1 .參與需求評審,從技術(shù)角度對需求實(shí)現(xiàn)方式、風(fēng)險(xiǎn)等進(jìn)行評估.2 .制定需求開發(fā)方案,分配需求開發(fā)人員.3 .負(fù)責(zé)需求所有工作的溝通、協(xié)調(diào)治理.4 .負(fù)責(zé)需求開發(fā)進(jìn)度、成員、變更治理.5 .負(fù)責(zé)或參與需求所有成果的審批.需求評估人員1 .從架構(gòu)、業(yè)務(wù)、技術(shù)、風(fēng)險(xiǎn)等方面對業(yè)務(wù)需求的內(nèi)容和實(shí)現(xiàn)方式進(jìn) 行全面評估,并提出評估意見.2 .審核根據(jù)評估意見修改后的業(yè)務(wù)需求.3.需求評估人員包括開發(fā)部門、測試部門、產(chǎn)品部門以及其他參與具 體需求工作的人員.開發(fā)人員1 .

4、幫助需求提交人員分析、確定業(yè)務(wù)需求.2 .編寫需求相關(guān)技術(shù)文檔.3 .組織實(shí)施軟件需求、系統(tǒng)設(shè)計(jì)等文檔評審,參與測試方案、測試案 例、測試報(bào)告文檔的評審工作.4 .負(fù)責(zé)需求的設(shè)計(jì)、開發(fā),保證代碼符合編碼標(biāo)準(zhǔn)和代碼平安標(biāo)準(zhǔn).5 .負(fù)責(zé)系統(tǒng)集成、編譯部署及單元測試.6 .提交測試申請,必要時(shí)提供技術(shù)支持,配合需求測試人員完成測試 環(huán)境的搭建.7 .配合需求測試人員處理環(huán)境問題,解決測試缺陷.8 .負(fù)責(zé)提交上線申請,參加上線評審,配合上線部署,負(fù)責(zé)上線問題 的查詢和解決、上線復(fù)核.需求測試負(fù)責(zé)人1 .參與需求評審,從業(yè)務(wù)測試角度參與對需求實(shí)現(xiàn)方式、風(fēng)險(xiǎn)等進(jìn)行 評估.2 .分配需求測試人員,對需求測試

5、過程治理,負(fù)責(zé)需求所有工作的溝 通、協(xié)調(diào)治理.3 .制定/參與制定測試方案,參與測試案例、測試報(bào)告文檔的評審工 作.測試人員1 .參與需求評估,參與技術(shù)文檔評審.2 .制定測試方案以及方案.3 .編寫測試案例等相關(guān)測試文檔.4 .實(shí)施技術(shù)測試工作,包括但部限于集成測試、功能測試、業(yè)務(wù)流程 測試、易用性測試及用戶體驗(yàn)測試、兼容性測試、性能與壓力測試、 穩(wěn)定性測試、平安測試等.5 .測試缺陷治理,測試缺陷處理跟進(jìn).6 .組織產(chǎn)品經(jīng)理等人員體驗(yàn)預(yù)發(fā)布產(chǎn)品.7 .測試總結(jié)與相關(guān)業(yè)務(wù)知識(shí)文檔編寫與匯總.8 .負(fù)責(zé)生產(chǎn)問題的協(xié)調(diào)處理.生產(chǎn)運(yùn)維人員1 . 負(fù)責(zé)上線申請受理、組織上線需求評審.2 .負(fù)責(zé)生產(chǎn)版

6、本備份、上線、回退.預(yù)留項(xiàng)預(yù)留項(xiàng)當(dāng)需求提交部門對需求評估小組的評估結(jié)果存在爭議時(shí),由相關(guān)部門領(lǐng)導(dǎo)共同商議裁決.第三章需求總體說明第五條需求分類按需求的提交部門可以分為研發(fā)部內(nèi)部需求和業(yè)務(wù)部門需求.需求類型需求類型定義研發(fā)部內(nèi)部需求研發(fā)部內(nèi)部提出的系統(tǒng)開發(fā)、性能優(yōu)化、軟件升級等需求.產(chǎn)品部門需求研發(fā)部以為的部門提交的系統(tǒng)開發(fā)需求,主要指產(chǎn)品部.按需求的內(nèi)容可分為功能開發(fā)需求、平臺(tái)網(wǎng)站類需求、數(shù)據(jù)需求.需求類型需求類型定義功能開發(fā)需求新業(yè)務(wù)功能已有系統(tǒng)中沒有此功能,需要在原有根底上新增功能功能改良當(dāng)前系統(tǒng)已經(jīng)有此功能,因組織架構(gòu)、制度標(biāo)準(zhǔn)、業(yè)務(wù)處理流程等發(fā)生 變化,需要對現(xiàn)有系統(tǒng)的某些功能進(jìn)行優(yōu)化

7、調(diào)整參數(shù)調(diào)整已有系統(tǒng)中已經(jīng)存在該參數(shù),需研發(fā)部對參數(shù)內(nèi)容進(jìn)行維護(hù)需求變更系統(tǒng)功能上線前,要在原有需求的根底上增加、修改或刪除需求內(nèi)容, 但需求內(nèi)容的變動(dòng)會(huì)引起本錢增長過大、對現(xiàn)有業(yè)務(wù)影響較大、或可能 存在風(fēng)險(xiǎn)、合規(guī)等問題系統(tǒng)問題系統(tǒng)現(xiàn)有功能可以正常使用,但是性能、平安、底層處理邏輯和架構(gòu)等 即將或者未來可能成為業(yè)務(wù)進(jìn)一步擴(kuò)張的瓶頸AP的面類需求1 .僅涉及APP前端頁面設(shè)計(jì)、開發(fā)、更新修改及維護(hù),與其他系統(tǒng)沒 有任何交互的需求.2 .涉及APP前端頁面設(shè)計(jì)、開發(fā)、更新修改及維護(hù),且與其他系統(tǒng)有 交互的需求.數(shù)據(jù)需求1 .面向客戶數(shù)據(jù)：是指運(yùn)用于客戶、與客戶直接關(guān)聯(lián)的數(shù)據(jù),包括向 客戶發(fā)送短信、

8、贈(zèng)送積分、贈(zèng)送權(quán)益禮品等后臺(tái)數(shù)據(jù)處理需求.2 .治理數(shù)據(jù)：用于治理分析,或活動(dòng)效果監(jiān)控和效果評估的報(bào)表及明 細(xì)數(shù)據(jù).按需求的緊急程度可以分為緊急需求和普通需求.需求類型需求類型定義緊急需求需求提交人員事先確定上線時(shí)間,且按常規(guī)資源分配和進(jìn)度安排無法按時(shí)上線,必須通過領(lǐng)導(dǎo)特批增加資源,并對局部流程進(jìn)行加急處理,才 可滿足上線要求的需求.普通需求緊急需求以外的其他需求.按需求開發(fā)工時(shí)的大小可以分為大型需求、中型需求和小型需求.需求類型需求類型定義大型需求開發(fā)工時(shí)200工時(shí)的需求.中型需求開發(fā)工時(shí)100工時(shí),=200工時(shí)的需求.小型需求開發(fā)工時(shí)=100工時(shí)的需求.第六條需求開發(fā)治理流程圖需求分析價(jià)段

9、需求訂劃階段設(shè)il開發(fā)階段山壩H值理14堆等在呷13.150l|2hilllli I那Ihli ifllllh i林I一線階段田求國新,編L?需求文料?年華北目管砰員埴寫產(chǎn)局常求評估1：表.相關(guān)開發(fā).蒿:區(qū)貝貞兒隹孑*：進(jìn)人反C原日計(jì)理員如也需求評書會(huì)以,評曲需求實(shí)瑁方式、拿坎恭度.風(fēng)卷存亦爭說褥分十條人導(dǎo)'審:m需求菱型處理.更“山工h：需求定必星可乾怡在仃 幫溝通衽步后期需求費(fèi)里麴費(fèi)史內(nèi)容.需 末町瀉嗟晚犍5t以屋開發(fā),測試酎聞sr 端寫需求技木聊美工檢明確薦階段完成時(shí)T 閩康交付有1刈國前漢,臼刈!率達(dá)支配.討論山說X對能與湖試希戶期狀案例般計(jì)期泌 審£非件反便,可:7

10、涮式商力i上前詢】堆幾洲試.臂寫甲匕惻試罹占我打那么式編寫OUiAlftM?開常箱出*胎第k幃I 要通過相大入房中核, 后由期H瞥理西統(tǒng)- ftftA：涮斌耳境近調(diào)上城復(fù)核上拷沆程可用凱軍陳情比荷/相小血瞬1黑忖相片河蟹對測試輸出的諦血需求開發(fā)治理流程為：建議由工程治理員統(tǒng)一治理需求需求治理主要包括以下內(nèi)容:需求的評估、開發(fā)、測試和上線階段的治理細(xì)那么遵循本制度中相關(guān)規(guī)定.不涉及功能開發(fā)的平臺(tái)類需求和數(shù)據(jù)需求可根據(jù)實(shí)際情況對需求開發(fā)治理過程的局部工作進(jìn)行裁剪.各階段包含的活動(dòng)及流程請見以下各章節(jié)中的詳細(xì)描述.第四章需求提交第七條需求提交為提升需求質(zhì)量和處理效率,減少需求變更的次數(shù),研發(fā)部各小組

11、開發(fā)、UI、測試與產(chǎn)品部門就需求內(nèi)容和實(shí)現(xiàn)方式等達(dá)成一致,可形成會(huì)議紀(jì)要存檔,并與?需求申請表?或郵件的形式同時(shí)提交需求審批.需求提交前需確認(rèn)的內(nèi)容包括：一與開發(fā)人員溝通,確定需求類型.二需求的可行性分析.各部門小組進(jìn)行可行性分析時(shí)需關(guān)注的內(nèi)容為：1,研發(fā)部對需求的技術(shù)可行性進(jìn)行初步分析,并幫助需求提交人員識(shí)別關(guān)聯(lián)系統(tǒng).2 .需求關(guān)聯(lián)系統(tǒng)的歸屬開發(fā)人員就需求是否符合業(yè)務(wù)開展規(guī)劃,以及需求對系統(tǒng)中已有業(yè) 務(wù)功能的影響進(jìn)行評估.3 .產(chǎn)品部、開發(fā)人員、測試人員對需求的業(yè)務(wù)邏輯、風(fēng)險(xiǎn)、合規(guī)等進(jìn)行初步評估. 第八條需求會(huì)簽原那么上中、大型工程或需求,需要通過會(huì)簽流程,征求各部門相關(guān)同事或領(lǐng)導(dǎo)審批,審批

12、通過方可進(jìn)入到后續(xù)開發(fā)流程.此條制度視公司具體情況需要,靈活運(yùn)用.第五章需求評估第九條需求評估流程需求評估流程說明及責(zé)任分工：一需求調(diào)研,需求文檔完成開發(fā)后,產(chǎn)品經(jīng)理需將需求提交至工程治理人員統(tǒng)一治理,工程治理人員需要將需求文檔發(fā)送至研發(fā)部想干的各分部門會(huì)簽.會(huì)簽通過后組織需求評估會(huì)議.二工程治理員審核相關(guān)要素,包括：參與會(huì)簽審批的干系人是否齊全,各干系人是否審批通過.附：緊急需求另行處理待完善,可劃分為業(yè)務(wù)需求、緊急需求、生產(chǎn)QC等三種類型三需求評估會(huì)上要評估的內(nèi)容包括：1 .確認(rèn)需求內(nèi)容,分析需求合理性：需求開發(fā)負(fù)責(zé)人從技術(shù)層面對需求的技術(shù)可行性、性 能等進(jìn)行初步評估；測試部及其他相關(guān)產(chǎn)品

13、部門從業(yè)務(wù)角度,對需求的業(yè)務(wù)邏輯、業(yè)務(wù)流程、業(yè) 務(wù)目的、風(fēng)險(xiǎn)、合規(guī)等方面內(nèi)容進(jìn)行評估.2 .初步確認(rèn)需求的實(shí)現(xiàn)方式.3 .初步評估需求的開發(fā)工作量.4 .明確需求系統(tǒng)設(shè)計(jì)、編碼、測試、上線階段的里程碑以及各階段的交付物和負(fù)責(zé)人.5 .確定需求評估結(jié)論.四需求評估完成后,填寫?需求評估表?待設(shè)計(jì)表格,需填寫的內(nèi)容包括：1 .不予開發(fā)或者有變更的事項(xiàng)；2 .該需求對其他關(guān)聯(lián)系統(tǒng)的影響；3 .需求所需人力、工時(shí)、里程碑以及整體評估結(jié)論等.五評估表填寫完畢后,評估人員需當(dāng)場簽字確認(rèn),工程治理員檢查需求評估表的信息是 否填寫完整、準(zhǔn)確.第十條需求評估考慮層面需求評估主要從技術(shù)角度和業(yè)務(wù)角度進(jìn)行考慮.假設(shè)

14、需求評估通過,會(huì)后需求提交人員根據(jù)需求評估的結(jié)論更新需求,更新后的需求將作為研 發(fā)部開發(fā)的最終依據(jù)防止需求屢次變更.假設(shè)出現(xiàn)以下情形之一的,評估組出具意見后可退回需求至產(chǎn)品部重新更新需求或需要征得各 部門領(lǐng)導(dǎo)審批.一技術(shù)層面1 .需對系統(tǒng)結(jié)構(gòu)進(jìn)行大規(guī)模改造的.2 .涉及系統(tǒng)架構(gòu)變更的.3 .與其他需求有重復(fù)的.4 .需求中有不合理事項(xiàng)的.5 .需求不明確需做補(bǔ)充的.6 .當(dāng)前技術(shù)無法實(shí)現(xiàn)的.7 .評估時(shí)發(fā)生重大變更,且變更審批未通過的.二業(yè)務(wù)層面1 .與目前的業(yè)務(wù)操作流程、運(yùn)營有矛盾的.2 .需大規(guī)模的更改原有的業(yè)務(wù)流程,增加大量人工后續(xù)處理本錢.3 .業(yè)務(wù)需求與業(yè)務(wù)目的不符的.4 .新需求引

15、起的新業(yè)務(wù)流程未在需求內(nèi)一并表達(dá)的.5 .業(yè)務(wù)流程未理順,業(yè)務(wù)規(guī)那么未明確或者沒有表達(dá),有可能導(dǎo)致上線后,無法正常進(jìn)行業(yè)務(wù)運(yùn)作,或者存在運(yùn)營風(fēng)險(xiǎn)的.因以上原因被退回的需求,需求提交部門如對需求評估小組的評估結(jié)果存在爭議,可提交各部門領(lǐng)導(dǎo)進(jìn)行仲裁.第六章需求開發(fā)第十一條需求開發(fā)流程略,具體流程有開發(fā)部門制定第十二條 設(shè)計(jì)開發(fā)：需求評估通過后,由需求開發(fā)負(fù)責(zé)人安排、協(xié)調(diào)需求的設(shè)計(jì)和開發(fā)工作.一開發(fā)人員根據(jù)需求評估會(huì)上通過的業(yè)務(wù)需求進(jìn)行設(shè)計(jì)開發(fā),同時(shí)完成?需求技術(shù)文檔?c二技術(shù)文檔通過需求開發(fā)負(fù)責(zé)人的審核后,開發(fā)人員提交工程治理人員.此技術(shù)文檔有必要從架構(gòu)、環(huán)境、平安、性能等層面對技術(shù)文檔進(jìn)行評審,

16、及時(shí)提出評審意見.三工程治理員審核相關(guān)要素,包括：技術(shù)文檔是否符合要求、評審人員參與度、是否評審?fù)ㄟ^.審核通過后需求進(jìn)入開發(fā)階段.如審核不通過,工程治理員將技術(shù)文檔退回給開發(fā)人員,開發(fā)人員處理完畢后再提交相關(guān)干系人評審.四技術(shù)文檔評審?fù)ㄟ^后,開發(fā)人員將評審?fù)ㄟ^后的技術(shù)文檔更新到SVN中并開展開發(fā)工作.緊急需求必須通過需求評估后,才可開展設(shè)計(jì)開發(fā)工作.設(shè)計(jì)開發(fā)階段的局部工作在工程管理員審批通過后,可根據(jù)實(shí)際情況進(jìn)行裁剪.第十三條單元測試8集成測試一編碼完成后,開發(fā)人員需進(jìn)行單元測試、系統(tǒng)集成、編譯部署、及主功能測試.測試通過后編寫?單元測試報(bào)告?、版本部署操作文檔,并提交需求開發(fā)負(fù)責(zé)人審核.二需

17、求開發(fā)負(fù)責(zé)人審核通過后,開發(fā)人員將源代碼、?單元測試報(bào)告?、版本部署操作文檔更新到SVN需求開發(fā)負(fù)責(zé)人將?單元測試報(bào)告?、版本部署操作文檔上傳到 SVN第七章系統(tǒng)測試第十四條 系統(tǒng)測試：單元測試包含系統(tǒng)集成通過后進(jìn)入系統(tǒng)測試階段,系統(tǒng)測試流程為：產(chǎn)總經(jīng)理11淤死京巾1K1 U.認(rèn)米；r需求開發(fā)他識(shí)人項(xiàng)II治理心輸III測試經(jīng)理測試人詁:i叫II映不林Ml卜巾導(dǎo)加產(chǎn)中商捏結(jié)耳推七池it十濡助皿雨區(qū)續(xù).節(jié) 先敗彳人事件可返HJF發(fā) 了雌程* 愧4*片后國疵M字注注版本EK判 h-K前試口通系統(tǒng)測試流程說明:學(xué)如次申仄勵(lì):淺虺行通過：分配試人M M'根嶺tf忐麗而 能楣口就式:長,此不加雷：

18、拗試想小忖1口.一 ,巾 I 1 r.l.通過口 J飛廉府號(hào)情況,遍HTT 町M松杓k幅代瑪、#認(rèn)相關(guān),檔一需求開發(fā)負(fù)責(zé)人向工程治理員提交系統(tǒng)測試申請.二工程治理員審核相關(guān)要素,包括：需求是否通過評估、技術(shù)文檔是否通過評審、單元測試是否通過、?需求技術(shù)文檔?、?單元測試報(bào)告?及版本部署操作文檔是否上傳SVN審核通過后工程治理員向研發(fā)部質(zhì)量治理部測試經(jīng)理下系統(tǒng)測試通知單.如審核不通過,返回開發(fā)子流程.三測試經(jīng)理分配系統(tǒng)測試人員.四系統(tǒng)測試人員驗(yàn)證 SVN中的技術(shù)文檔、版本部署及需求主功能.驗(yàn)證通過后制定測試 方案,如驗(yàn)證不通過,返回開發(fā)子流程.五系統(tǒng)測試方案、測試案例、測試報(bào)告由系統(tǒng)測試人員編寫

19、并組織評審,系統(tǒng)測試主管 和需求開發(fā)負(fù)責(zé)人必須參加評審.六補(bǔ)充：測試方案、測試方案、測試案例等測試文檔,設(shè)計(jì)時(shí)間參考第六條需求開發(fā) 治理流程圖；測試工作遵循盡早參與的原那么,遇特殊情況,測試文檔也可在測試啟動(dòng)時(shí)執(zhí)行.第八章需求上線第十五條 需求上線：測試驗(yàn)收工作結(jié)束后,進(jìn)入需求上線階段.需求上線主要分為業(yè)務(wù)上線、技術(shù)上線.第十六條需求上線流程需求上線流程說明：一需求上線申請需求測試通過后,測試經(jīng)理檢查測試負(fù)責(zé)人提交的測試工件,審核通過后提交工程治理員協(xié)調(diào)開發(fā)安排上線時(shí)間.二上線實(shí)施后,需求相關(guān)人員需進(jìn)行上線驗(yàn)證：三假設(shè)上線復(fù)核或驗(yàn)證失敗,那么開發(fā)人員將上線版本從生產(chǎn)環(huán)境中回退,需求轉(zhuǎn)入開發(fā)流程

20、.第十七條試運(yùn)行為了對系統(tǒng)的功能、性能、可靠性、穩(wěn)定性、需求涉及業(yè)務(wù)和系統(tǒng)的影響情況進(jìn)行驗(yàn)證,需 求上線后,由研發(fā)部、產(chǎn)品部,以及其他領(lǐng)導(dǎo)共同商榷,根據(jù)工程實(shí)際情況實(shí)行產(chǎn)品試運(yùn)行.試 運(yùn)行的時(shí)間、方案、通過標(biāo)準(zhǔn)暫未制定.第九章生產(chǎn)問題治理第十八條 生產(chǎn)問題：指存在于生產(chǎn)系統(tǒng)中的異常現(xiàn)象或缺陷,不包括辦公設(shè)備、網(wǎng)絡(luò)故 障等非生產(chǎn)系統(tǒng)引起的故障.生產(chǎn)問題處理流程說明：一技術(shù)人員收到生產(chǎn)問題后,對問題根源進(jìn)行深入分析,并對系統(tǒng)問題進(jìn)行處理.如不 屬于非系統(tǒng)問題,技術(shù)人員拒絕報(bào)障并說明原因,測試人員需整理歸檔.二生產(chǎn)問題修復(fù)完畢后部署到測試環(huán)境,提交測試流程.三技術(shù)人員提交測試申請,工程治理員審核通過

21、后下測試通知單.四生產(chǎn)問題測試通過后,上線流程與需求上線流程一致.第十章需求變更限制與治理第十九條 需求變更：指研發(fā)部受理需求后,需增加、修改、刪除需求內(nèi)容,或?qū)⑿枨髵?起、退回、取消的現(xiàn)象.需求變更限制與治理流程：需求變更限制與治理流程說明及責(zé)任分工：一需求變更申請人填寫?需求變更申請表?待設(shè)計(jì)表格,詳細(xì)說明需求變更的類型、變更原因及變更內(nèi)容.二需求變更申請人通過郵件或其他部門間工作聯(lián)系函將需求變更申請?zhí)峤恍枨箝_發(fā)負(fù)責(zé)人、相關(guān)測試負(fù)責(zé)人及關(guān)聯(lián)系統(tǒng)負(fù)責(zé)人審批.審批通過后需求開發(fā)負(fù)責(zé)人判斷是否為重大變 更.如審批不通過,評審組說明原因后將需求變更申請退回申請人.三需求變更屬于重大變更時(shí),需求變更申請人組織需求變更評審會(huì),由評審組成員共同 確定是否允許變更.如果不屬于重大變更,需求開發(fā)負(fù)責(zé)人有權(quán)決定是否允許需求變更.滿足以下任一條件的需求變更都屬于重大變更.1