軟件過(guò)程的需求管理

軟件過(guò)程管理-Ch.4軟件過(guò)程的需求管理2021/3/111軟件過(guò)程的需求管理開(kāi)發(fā)軟件系統(tǒng)最為困難的部分就是準(zhǔn)確說(shuō)明開(kāi)發(fā)什么?！ダ椎吕锟恕げ剪斂怂?021/3/112理解1.什么是需求2.了解客戶、最終用戶、間接用戶3.需求工程基本概念4.需求開(kāi)發(fā)的主要困難與對(duì)策5.如何開(kāi)展需求調(diào)查6.如何進(jìn)行需求分析7.什么是好的需求規(guī)格說(shuō)明書8.如何定義產(chǎn)品需求9.需求管理：確認(rèn)、跟蹤、變更控制人們并不清楚應(yīng)該做什么，卻一直忙碌不停地開(kāi)發(fā)。2021/3/1131.什么是需求1.1需求的基本概念

寬泛地講，需求來(lái)源于用戶的一些“需要”，這些“需要”被分析、確認(rèn)后形成完整的文檔，該文檔詳細(xì)地說(shuō)明了產(chǎn)品“必須或應(yīng)當(dāng)”做什么。所以如果只有一些零碎的對(duì)話、資料或郵件，你就以為自己已經(jīng)掌握了需求，那是自欺欺人。1.2需求的重要性FrederickBrooks在他1987年經(jīng)典文章“NoSilverBullet”中闡述了需求的重要性：開(kāi)發(fā)軟件系統(tǒng)最困難的部分就是準(zhǔn)確說(shuō)明開(kāi)發(fā)什么。最困難的概念性工作是編寫出詳細(xì)的需求，包括所有面向用戶、面向機(jī)器和其它軟件系統(tǒng)的接口。此工作一旦做錯(cuò)，將會(huì)給系統(tǒng)帶來(lái)極大的損害，并且以后對(duì)它修改也極為困難。

需求是產(chǎn)品的根源，需求工作的優(yōu)劣對(duì)產(chǎn)品影響最大。就像一條河流，如果源頭被污染了，那么整條河流也就被污染了。

國(guó)內(nèi)軟件業(yè)的痼疾：人們并不清楚究竟該做什么，但卻一直忙碌不停地開(kāi)發(fā)。

2021/3/1142.了解客戶、最終用戶、間接用戶2.1基本概念“用戶”（user）是一種泛稱，它可細(xì)分為“客戶”（customer）、“最終用戶”（theenduser）和“間接用戶”（或稱為關(guān)系人）。掏錢買軟件的用戶稱為客戶，而真正操作軟件的用戶叫最終用戶?？蛻襞c最終用戶可能是同一個(gè)人也可能不是同一個(gè)人。2.2客戶是掏錢買軟件的人，所以他是“上帝”

某飯店經(jīng)理在解釋“先有雞還是先有蛋”這個(gè)哲學(xué)問(wèn)題時(shí)，精辟地闡述了客戶的地位：如果顧客先點(diǎn)雞，那么就先有雞；如果顧客先點(diǎn)蛋，那么就先有蛋?！艾F(xiàn)代營(yíng)銷學(xué)之父”菲利普?科特勒所著的《市場(chǎng)營(yíng)銷導(dǎo)論》是這樣描述客戶的：客戶永遠(yuǎn)是本公司的座上客?？蛻舨⒉灰蕾囄覀儯覀儏s依賴客戶?？蛻舨皇俏覀児ぷ鞯恼系K，而是我們工作的目標(biāo)。我們并不因?yàn)榉?wù)于他而對(duì)他有恩，他卻因?yàn)榻o予我們服務(wù)于他的機(jī)會(huì)而有恩于我們?？蛻舨皇俏覀円c之爭(zhēng)辯和斗智的人。從未有人曾在與客戶的爭(zhēng)辯中獲勝?？蛻羰前阉挠麕Ыo我們的人，因此我們的工作就是滿足這些欲望，從而使客戶和我們共同獲益。與客戶打交道的主要目的是：一是獲取需求，二是簽合同。不要把錢仍到水里。2021/3/1152.了解客戶、最終用戶、間接用戶2.3即使最終用戶不是上帝，也算是“上帝”的“親戚”，同樣怠慢不得。如果項(xiàng)目規(guī)模比較大，那么開(kāi)發(fā)方與最終用戶的來(lái)往就比較多。如從最終用戶那里獲取詳細(xì)的需求，請(qǐng)最終用戶試驗(yàn)軟件，對(duì)最終用戶進(jìn)行培訓(xùn)等等。公司新員工上產(chǎn)品培訓(xùn)課，有位小領(lǐng)導(dǎo)匆匆趕來(lái)作指示：“隔壁班正在給電信局的員工們進(jìn)行培訓(xùn)，他們都是上帝派來(lái)的，大家要注意形象。由于休息室空間有限，請(qǐng)大家自覺(jué)讓位。午休時(shí)他們可以躺著睡，我們只能坐在位置上打個(gè)盹兒…….?！?.4重視“間接用戶”，千萬(wàn)別“大意失荊州”

間接用戶既不掏錢買該軟件產(chǎn)品，也不使用該軟件，但是它可能對(duì)軟件產(chǎn)品有很大的影響。例如，財(cái)務(wù)軟件開(kāi)發(fā)商在把“財(cái)務(wù)軟件”賣給客戶之前，這個(gè)“財(cái)務(wù)軟件”必須得到國(guó)家財(cái)政部的批準(zhǔn)。否則即使該軟件的功能是完美的，但卻被政府認(rèn)為是非法的。所以國(guó)家財(cái)政部就是所有財(cái)務(wù)軟件的間接用戶，它不僅不付錢給財(cái)務(wù)軟件開(kāi)發(fā)商，反而要收取鑒定費(fèi)、手續(xù)費(fèi)等。同理，市面上流通的信息安全軟件、殺病毒軟件必須得到國(guó)家公安部的批準(zhǔn)，否則軟件開(kāi)發(fā)商被逮住后戴上“非法經(jīng)營(yíng)”的帽子就慘了。

2021/3/1163.需求工程基本概念3.1什么是需求工程把所有與需求直接相關(guān)的活動(dòng)通稱為需求工程。需求工程中的活動(dòng)可分為兩大類，一類屬于需求開(kāi)發(fā)，另一類屬于需求管理。需求工程的結(jié)構(gòu)圖

2021/3/117軟件需求工程所有與需求直接相關(guān)的活動(dòng)統(tǒng)稱為需求工程，需求工程分為了兩個(gè)部分：需求開(kāi)發(fā)和需求管理。其中，需求開(kāi)發(fā)又分為了需求獲取、需求分析、需求定義和需求驗(yàn)證4個(gè)部分，而需求管理則包含了變更控制、版本控制、需求跟蹤和需求狀態(tài)跟蹤軟件需求包括三個(gè)不同的層次：業(yè)務(wù)需求、用戶需求和功能需求（也包括非功能需求）。2021/3/118軟件需求工程業(yè)務(wù)需求（businessrequirement）反映了組織機(jī)構(gòu)或客戶對(duì)系統(tǒng)、產(chǎn)品的概括的目標(biāo)要求，它在項(xiàng)目視圖與范圍文檔中予以說(shuō)明。主要的目的是對(duì)企業(yè)目前的業(yè)務(wù)流程進(jìn)行評(píng)估，得出一個(gè)業(yè)務(wù)前景。業(yè)務(wù)需求的確定對(duì)后面的用戶需求和功能需求起到了限制作用。用戶需求(userrequirement)文檔描述了用戶使用系統(tǒng)而完成的任務(wù)的集合，用戶需求在用戶案例（usercase）文檔或方案腳本中予以說(shuō)明。收集和分析用戶需求是不容易的，因?yàn)楹芏嘈枨笫请[形的，很難獲取，更難保證需求完整，而需求又是易變的，這就要求用戶和開(kāi)發(fā)人員進(jìn)行充分地交流。功能需求(functionalrequirement)定義了開(kāi)發(fā)人員必須實(shí)現(xiàn)的軟件功能，它源于用戶需求。功能需求是軟件需求說(shuō)明書中最重要的部分之一，它在開(kāi)發(fā)、測(cè)試、質(zhì)量保證、項(xiàng)目管理以及相關(guān)項(xiàng)目功能中都起了重要的作用。非功能需求描述了系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等，包括要遵從的業(yè)務(wù)規(guī)則、人機(jī)接口、安全性和可靠性等要求。2021/3/1193.需求工程基本概念3.4需求工程的一些感悟不論是合同項(xiàng)目還是自主研發(fā)的產(chǎn)品，都必須開(kāi)展需求開(kāi)發(fā)和需求管理活動(dòng)。開(kāi)發(fā)者對(duì)待需求工程的態(tài)度可分“被動(dòng)型”、“主動(dòng)型”和“領(lǐng)先型”三種，只有后兩種才有可能開(kāi)發(fā)出成功的產(chǎn)品?！氨粍?dòng)型”是指開(kāi)發(fā)者被動(dòng)地對(duì)待需求工程中的各項(xiàng)活動(dòng)，能少干則少干，能偷懶則偷懶。他們認(rèn)為需求是用戶的事情而不是自己的事情。開(kāi)發(fā)過(guò)程中經(jīng)常發(fā)生需求變更，導(dǎo)致產(chǎn)品迷失方向，不是半途而廢就是陷入半死不活的狀態(tài)?！爸鲃?dòng)型”是指開(kāi)發(fā)者積極地開(kāi)展需求工程中的各項(xiàng)活動(dòng)。他們把獲取準(zhǔn)確的需求當(dāng)作自己的職責(zé)，會(huì)想盡一切辦法克服需求開(kāi)發(fā)和需求管理過(guò)程中的困難，而不是找借口推卸責(zé)任。俗話說(shuō)“良好的開(kāi)端是成功的一半”，“主動(dòng)型”需求工程是開(kāi)發(fā)成功產(chǎn)品的必備條件?！邦I(lǐng)先型”是需求工程的最高境界。開(kāi)發(fā)者發(fā)掘了連用戶自己都沒(méi)有意識(shí)到的需求，導(dǎo)致用戶跟著新產(chǎn)品跑而不是新產(chǎn)品圍著用戶轉(zhuǎn)，這叫引導(dǎo)消費(fèi)。需求工程做到這個(gè)份上，才能使產(chǎn)品立于不敗之地，長(zhǎng)盛不衰。4.需求開(kāi)發(fā)的主要困難與對(duì)策4.1知識(shí)技能問(wèn)題

應(yīng)用域的知識(shí)是無(wú)邊無(wú)際的，任何人都不可能是“萬(wàn)事通”。俗話說(shuō)“隔行如隔山”，需求分析員可能是某一領(lǐng)域的專家，但當(dāng)他接手陌生的業(yè)務(wù)時(shí)，他可能是個(gè)“無(wú)知”者。一個(gè)企業(yè)要謀求發(fā)展，不能總在做老的業(yè)務(wù)。人一生中會(huì)有許多充滿挫折的“第一次”，不可以逃避。當(dāng)需求分析員缺乏應(yīng)用域知識(shí)時(shí)，他該怎么辦？首先他要有勇氣做事，否則連實(shí)踐的機(jī)會(huì)都沒(méi)有。其次他應(yīng)當(dāng)趕緊補(bǔ)習(xí)應(yīng)用域知識(shí)，不論是通過(guò)自學(xué)還是培訓(xùn)的方式，否則他很難與用戶交流。如果可能的話，開(kāi)發(fā)方最好請(qǐng)既懂軟件又懂應(yīng)用域知識(shí)的行家來(lái)幫忙。4.2態(tài)度問(wèn)題

相當(dāng)多的開(kāi)發(fā)人員習(xí)慣于被動(dòng)地對(duì)待需求開(kāi)發(fā)。每當(dāng)遇到麻煩、挫折時(shí)，他們會(huì)發(fā)牢騷，找出一堆用戶的毛病。很多開(kāi)發(fā)人員錯(cuò)誤地以為：需求是用戶的事情，不是我們的事情。我們?yōu)橛脩糸_(kāi)發(fā)軟件，難道用戶不該告訴我們應(yīng)當(dāng)開(kāi)發(fā)什么嗎？如果用戶說(shuō)不清楚需求，或者經(jīng)常變更需求，這類問(wèn)題是用戶產(chǎn)生的，應(yīng)當(dāng)由他們自己負(fù)責(zé)。

用戶說(shuō)不清楚需求或者需求發(fā)生變更，這些都是常見(jiàn)的問(wèn)題，并不是絕癥，是人們可以設(shè)法解決的?？杀氖情_(kāi)發(fā)人員把這些問(wèn)題當(dāng)成了借口，不愿主動(dòng)攻克問(wèn)題，導(dǎo)致需求問(wèn)題擴(kuò)散到整個(gè)軟件開(kāi)發(fā)過(guò)程，產(chǎn)生太多的后患。軟件企業(yè)的領(lǐng)導(dǎo)應(yīng)當(dāng)給具有錯(cuò)誤觀念的開(kāi)發(fā)人員們洗腦：需求分析員的天職就是在有限的時(shí)間內(nèi)獲取準(zhǔn)確而細(xì)致的用戶需求，如果做不到就是失職，不要找借口。

4.需求開(kāi)發(fā)的主要困難與對(duì)策4.3合作關(guān)系如果需求分析員不能與用戶建立良好的合作關(guān)系，那么他們?cè)谛枨箝_(kāi)發(fā)過(guò)程中會(huì)很疲憊。倘若用戶不能很好地配合需求分析員，那并不表示他是個(gè)壞蛋。因?yàn)橛脩粲兴约旱南敕ǎ何一卮鹆四銈兊膯?wèn)題，講了該講的。我們付錢給你們，難道還要我伺候你們不成？我還要干自己的事情，別打擾我了。你們自己想辦法把活干好吧

……。

對(duì)于一些競(jìng)標(biāo)項(xiàng)目，在合同未簽訂之前的需求開(kāi)發(fā)工作尤為困難。用戶未必會(huì)買你的產(chǎn)品，他不會(huì)投入很多精力來(lái)協(xié)助你搞需求開(kāi)發(fā)。需求分析員不是銷售人員，他們不可能象銷售人員那樣通過(guò)某些手段籠絡(luò)住用戶就能成功。出色的需求分析員不僅要有過(guò)硬的專業(yè)知識(shí)，還要具備較強(qiáng)的交流、溝通能力。開(kāi)發(fā)方與用戶的合作關(guān)系對(duì)需求開(kāi)發(fā)而言是至關(guān)重要的。對(duì)于重大的、復(fù)雜的項(xiàng)目，我們不能完全期望雙方能夠自發(fā)地建立起良好地合作關(guān)系，這樣風(fēng)險(xiǎn)太大。開(kāi)發(fā)方和用戶方在開(kāi)展需求開(kāi)發(fā)之前，雙方協(xié)商并撰寫“用戶在需求工程中的權(quán)利與義務(wù)”，即以協(xié)議的方式確定合作關(guān)系?！昂迷挕焙汀俺笤挕倍颊f(shuō)在前頭，這樣能減少今后的摩擦。如果條件允許的話，開(kāi)發(fā)方最好為用戶舉辦關(guān)于需求工程的培訓(xùn)，這樣的培訓(xùn)將使用戶明白需求的重要性以及忽視需求的危害性，從而促使他們積極友善地參加需求工程中的各項(xiàng)活動(dòng)。4.需求開(kāi)發(fā)的主要困難與對(duì)策用戶在需求工程中的“權(quán)利”1.有權(quán)要求開(kāi)發(fā)方派遣資質(zhì)合格的需求分析員和相關(guān)人員。2.有權(quán)要求開(kāi)發(fā)方采用用戶熟悉的語(yǔ)言來(lái)描述需求，即開(kāi)發(fā)方必須提供用戶看得懂得需求文檔。3.有權(quán)審查需求文檔，并對(duì)有爭(zhēng)議的需求作出決策。如果認(rèn)為需求文檔不能準(zhǔn)確地反映用戶真實(shí)的意愿，可以拒絕在需求文檔上簽字。4.如果用戶想要變更需求，有權(quán)要求開(kāi)發(fā)方對(duì)該變更將產(chǎn)生的影響作出真實(shí)可信的評(píng)估，以便用戶決定是否變更需求。用戶在需求工程中的“義務(wù)”1.以積極友善的態(tài)度與開(kāi)發(fā)方人員交流、協(xié)作，盡可能地為開(kāi)發(fā)方人員提供工作和生活上的便利。2.樂(lè)意接受需求分析員的采訪，在不泄漏機(jī)密的前提下盡可能地回答需求分析員的問(wèn)題。3.在不泄漏機(jī)密的前提下，盡可能地向需求分析員提供與需求相關(guān)的材料。4.與需求分析員共同評(píng)審需求文檔，確保需求文檔準(zhǔn)確地反映用戶真實(shí)的意愿。4.需求開(kāi)發(fā)的主要困難與對(duì)策4.4用戶說(shuō)不清楚需求用戶說(shuō)不清楚需求是普遍現(xiàn)象，這是讓開(kāi)發(fā)人員頭痛的大問(wèn)題。有些用戶真的不知道需求是什么，或者對(duì)需求只有朦朧的感覺(jué)，他當(dāng)然說(shuō)不清楚需求。例如開(kāi)發(fā)方的營(yíng)銷人員水平比較高，他能夠在用戶不清楚自己要什么的情況下引導(dǎo)用戶“消費(fèi)”。例如前些年全國(guó)各地的很多政府機(jī)構(gòu)大搞網(wǎng)絡(luò)建設(shè)。這些機(jī)構(gòu)的領(lǐng)導(dǎo)和辦公人員大多數(shù)不清楚網(wǎng)絡(luò)干什么用，就讓開(kāi)發(fā)人員替他們?cè)O(shè)想需求吧，反正是花公家的錢。有些用戶雖然心里明白想要什么，但卻說(shuō)不清楚需求。

比如說(shuō)買鞋子。我們非常了解自已的腳，但很難用語(yǔ)言說(shuō)清楚腳的大小和形狀。通常拿鞋子去試，試穿時(shí)感覺(jué)到舒服才會(huì)買鞋。需求分析員絕不能以用戶說(shuō)不清楚需求為借口而草率地對(duì)待需求開(kāi)發(fā)工作，否則會(huì)連累整個(gè)開(kāi)發(fā)團(tuán)隊(duì)的。無(wú)論是什么原因?qū)е掠脩粽f(shuō)不清楚需求，需求分析員必須設(shè)法搞清楚用戶真正的需求，這是需求分析員的職責(zé)，也是職業(yè)的挑戰(zhàn)。

4.需求開(kāi)發(fā)的主要困難與對(duì)策4.5雙方誤解需求人們?cè)诮涣鞯臅r(shí)候，經(jīng)常會(huì)發(fā)生“問(wèn)非所求，答非所問(wèn)”的事情。有時(shí)用戶會(huì)把開(kāi)發(fā)人員的建議或答復(fù)給想歪了：有一個(gè)軟件開(kāi)發(fā)人員滔滔不絕地向用戶講解在“信息高速公路上做廣告”的種種好處，用戶聽(tīng)得津津有味。最后，心動(dòng)的用戶對(duì)軟件開(kāi)發(fā)人員說(shuō)：“好得很，就讓我們馬上行動(dòng)起來(lái)吧。請(qǐng)您決定廣告牌的尺寸和放在哪條高速公路上，我立即派人去做。”而用戶表達(dá)的需求，不同的開(kāi)發(fā)人員可能有不同的理解。如果需求分析員誤解了需求，那會(huì)導(dǎo)致后續(xù)的不少開(kāi)發(fā)人員將錯(cuò)就錯(cuò)、白干活。就像作文寫跑題了，寫得再好也白搭。這類錯(cuò)誤連高智商的外星人都不能避免：有個(gè)外星人間諜潛伏到地球刺探情報(bào)，它給上司寫了一份報(bào)告：“主宰地球的是車。它們喝汽油，靠四個(gè)輪子滾動(dòng)前進(jìn)。嗓門極大，在夜里雙眼能射出強(qiáng)光。……有趣的是，車?yán)镒≈环N叫作‘人’的寄生蟲，這些寄生蟲完全控制了車?！辈徽撌菑?fù)雜的項(xiàng)目還是簡(jiǎn)單的項(xiàng)目，需求分析員和用戶都有可能誤解需求。所以需求確認(rèn)工作（屬于需求管理）必不可少。

4.需求開(kāi)發(fā)的主要困難與對(duì)策4.6開(kāi)發(fā)人員寫不好需求文檔需求調(diào)查工作不充分，獲取的需求信息太少或者太亂，以至于寫不成需求文檔。古時(shí)候，一書生在考試前補(bǔ)習(xí)“寫文章”，成天愁眉苦臉。其夫人甚為不解，問(wèn)：“相公，你寫文章比我生小孩還難嗎？”書生長(zhǎng)嘆一聲：“娘子你哪里知道我的難處??！你生小孩時(shí)肚子里有東西，可我寫文章時(shí)肚子里沒(méi)東西啊?！彼砸雽懗龊玫男枨笪臋n，前提條件是把需求調(diào)查工作做好。

開(kāi)發(fā)人員寫作能力比較差，雖然在調(diào)查過(guò)程中已經(jīng)獲得了不少需求信息，卻寫不出好的需求文檔來(lái)。可以毫不夸張地說(shuō)，國(guó)內(nèi)90％以上的軟件開(kāi)發(fā)人員，他們的寫作能力遠(yuǎn)不及開(kāi)發(fā)能力。提高開(kāi)發(fā)人員寫作能力的根本辦法就是讓他們多練習(xí)寫文檔，熟能生巧。另外，企業(yè)應(yīng)當(dāng)提供合適的文檔模板以及比較好的示例文檔，盡可能地降低寫作難度。

4.需求開(kāi)發(fā)的主要困難與對(duì)策4.7用戶經(jīng)常變更需求需求變更通常會(huì)對(duì)項(xiàng)目的進(jìn)度、人力資源、經(jīng)費(fèi)產(chǎn)生很大的影響，這是開(kāi)發(fā)商非常畏懼的問(wèn)題。如果在項(xiàng)目開(kāi)發(fā)的初始階段，開(kāi)發(fā)人員和用戶沒(méi)有搞清楚需求或者搞錯(cuò)了需求，到了項(xiàng)目開(kāi)發(fā)后期才將需求糾正過(guò)來(lái)，導(dǎo)致產(chǎn)品的部分內(nèi)容需要重新開(kāi)發(fā)。毫無(wú)疑問(wèn)，這種需求變更將使項(xiàng)目付出額外的代價(jià)。這種損失是由于雙方工作失誤造成的，雙方應(yīng)當(dāng)好好反省，認(rèn)真學(xué)習(xí)需求開(kāi)發(fā)和管理的方法，避免再犯相似的錯(cuò)誤。如果由于市場(chǎng)變化而導(dǎo)致產(chǎn)品需求發(fā)生變更，開(kāi)發(fā)商大可不必為此煩惱，應(yīng)當(dāng)高興才對(duì)。倘若市場(chǎng)靜如死水，那么開(kāi)發(fā)商吃了“上一頓”就沒(méi)有“下一頓”。正因?yàn)槭袌?chǎng)在變化，才會(huì)產(chǎn)生更多商機(jī)，聰明的開(kāi)發(fā)商才會(huì)有活干，有錢賺。

其實(shí)需求變更并不可怕，可怕的是需求變更失去控制，導(dǎo)致項(xiàng)目混亂。所以需求變更控制是需求工程的重要活動(dòng)。

需求開(kāi)發(fā)需求開(kāi)發(fā)的目的是通過(guò)調(diào)查與分析，獲取用戶需求并定義產(chǎn)品需求。獲取數(shù)據(jù)分析、處理目標(biāo)系統(tǒng)模型需求獲取系統(tǒng)分析員從數(shù)據(jù)流和數(shù)據(jù)結(jié)構(gòu)出發(fā)，找出系統(tǒng)各元素之間的聯(lián)系、接口特征及設(shè)計(jì)限制、能否滿足功能需求2021/3/1118需求獲取概述需求獲取是通過(guò)各種途徑獲取用戶的需求信息（原始材料），產(chǎn)生《用戶需求說(shuō)明書》。

2021/3/1119需求獲取的方法需求研討會(huì)頭腦風(fēng)暴用例模型訪談角色扮演原型法2021/3/1120基于用例的需求獲取執(zhí)行者的識(shí)別誰(shuí)使用系統(tǒng)的主要功能？誰(shuí)將提供、使用和刪除信息？誰(shuí)負(fù)責(zé)維護(hù)、管理并保持系統(tǒng)正常運(yùn)行？誰(shuí)會(huì)對(duì)某一特定需求感興趣？系統(tǒng)的外部資源是什么？系統(tǒng)需要和哪些外部系統(tǒng)交互？用例的識(shí)別某個(gè)執(zhí)行者要求系統(tǒng)為其提供什么功能？該執(zhí)行者需要做哪些工作？執(zhí)行者需要閱讀、創(chuàng)建、銷毀、更新或存儲(chǔ)系統(tǒng)中哪些（類）信息？系統(tǒng)中的事件一定要告之執(zhí)行者嗎？執(zhí)行者需要告訴系統(tǒng)一些什么嗎？那些系統(tǒng)內(nèi)部的事件從功能的角度代表什么？由于新功能的識(shí)別，執(zhí)行者的日常工作被簡(jiǎn)化或效率提高了嗎？系統(tǒng)需要什么樣的輸入輸出？輸入在哪里？輸出去往哪里？該系統(tǒng)的當(dāng)前情況存在哪些問(wèn)題？2021/3/1121課堂案例：學(xué)生學(xué)籍處理業(yè)務(wù)學(xué)生學(xué)籍處理業(yè)務(wù)每學(xué)期開(kāi)學(xué)時(shí)，各學(xué)辦進(jìn)行注冊(cè)管理，注冊(cè)信息記錄在在校生信息卡中。學(xué)生轉(zhuǎn)專業(yè)由本人向所在系提出申請(qǐng)，教務(wù)處審批。在本系內(nèi)轉(zhuǎn)專業(yè)，由學(xué)生所在系考核同意，報(bào)教務(wù)處審批；在學(xué)校范圍內(nèi)轉(zhuǎn)專業(yè)（跨系），由學(xué)生所在系推薦，擬轉(zhuǎn)入系考核同意，報(bào)教務(wù)處審批。轉(zhuǎn)專業(yè)手續(xù)應(yīng)在每學(xué)年開(kāi)學(xué)前辦理。2021/3/1122課堂案例：學(xué)生學(xué)籍處理業(yè)務(wù)2021/3/1123需求定義需求定義指的是解釋涉眾需求,并根據(jù)需求規(guī)模整理成對(duì)要構(gòu)建系統(tǒng)的明確的說(shuō)明。前景文檔是用一般的語(yǔ)言定義系統(tǒng)特征的文檔軟件需求規(guī)格說(shuō)明書是用更專業(yè)的術(shù)語(yǔ)定義系統(tǒng)特征的文檔。

2021/3/1124軟件需求規(guī)格說(shuō)明書0.文檔介紹0.1文檔目的0.2文檔范圍0.3讀者對(duì)象0.4參考文檔0.5術(shù)語(yǔ)與縮寫解釋1.產(chǎn)品介紹提示：(1)說(shuō)明產(chǎn)品是什么，什么用途；(2)介紹產(chǎn)品的開(kāi)發(fā)背景。2.產(chǎn)品面向的用戶群體提示：(1)描述本產(chǎn)品面向的用戶(客戶、最終用戶)的特征；(2)說(shuō)明本產(chǎn)品將給他們帶來(lái)什么好處？特們選擇本產(chǎn)品的可能性有多大？3.產(chǎn)品應(yīng)當(dāng)遵循的標(biāo)準(zhǔn)或規(guī)范提示：闡述本產(chǎn)品應(yīng)當(dāng)遵循什么標(biāo)準(zhǔn)、規(guī)范或業(yè)務(wù)規(guī)則。2021/3/11254.產(chǎn)品的功能需求……FunctionC.1FeatureC……FunctionB.1FeatureB……FunctionA.1FeatureA描述功能名稱、標(biāo)識(shí)符功能類別5.產(chǎn)品的非功能需求質(zhì)量需求軟硬件需求用戶界面需求描述需求名稱、標(biāo)識(shí)符需求類別6.其他需求軟件需求規(guī)格說(shuō)明書2021/3/1126需求確認(rèn)為什么需要需求評(píng)審？在哪個(gè)階段發(fā)現(xiàn)成本率需求1設(shè)計(jì)3-6編碼10功能測(cè)試15-40驗(yàn)收測(cè)試30-70發(fā)布之后40-1000修訂一個(gè)缺陷的相關(guān)成本2021/3/1127需求確認(rèn)如何進(jìn)行需求評(píng)審？（1）分層次評(píng)審目標(biāo)性評(píng)審功能性評(píng)審操作性評(píng)審（2）分階段評(píng)審2021/3/11282需求評(píng)審面臨的困難需求評(píng)審的一個(gè)通病是“虎頭蛇尾”。需求評(píng)審的確乏味，也比較費(fèi)腦子。剛開(kāi)始評(píng)審時(shí)，大家都比較認(rèn)真，越到后頭越馬虎。

需求評(píng)審涉及的人員可能比較多，有些時(shí)候讓這么多人聚在一起花費(fèi)比較長(zhǎng)的時(shí)間開(kāi)會(huì)并不容易（例如有些人可能出差在外，有些人可能事務(wù)纏身）。沒(méi)有必要把所有事情擠在一塊做，需求開(kāi)發(fā)是循序漸進(jìn)的過(guò)程，需求評(píng)審也可以分段進(jìn)行。這樣每次評(píng)審的時(shí)間比較短，參加評(píng)審的人員也少一些，組織會(huì)議就比較容易。開(kāi)評(píng)審會(huì)議時(shí)經(jīng)常會(huì)“跑題”，導(dǎo)致評(píng)審效率很低。有時(shí)話匣子一打開(kāi)后關(guān)不上，大家越扯越遠(yuǎn)，結(jié)果評(píng)審會(huì)議變成了聊天會(huì)議。主持人應(yīng)當(dāng)控制話題，避免大家討論與主題無(wú)關(guān)的東西。

開(kāi)評(píng)審會(huì)議時(shí)經(jīng)常會(huì)發(fā)生爭(zhēng)議。適當(dāng)?shù)臓?zhēng)議有利于澄清問(wèn)題，比什么東西都一致贊成要好。然而當(dāng)爭(zhēng)議變?yōu)闋?zhēng)吵時(shí)就壞事了，爭(zhēng)吵不僅對(duì)評(píng)審工作沒(méi)有好處，而且會(huì)無(wú)意中傷害同事們的感情。人們?cè)诤芏鄷r(shí)候分不清楚自己究竟是“堅(jiān)持真理”還是“固執(zhí)己見(jiàn)”。毫不妥協(xié)或者輕易妥協(xié)都不是好辦法。我們應(yīng)當(dāng)養(yǎng)成良好的習(xí)慣：不要一棍子打死異己的觀點(diǎn)，嘗試著讓自己站在他人的立場(chǎng)思考問(wèn)題，這樣你會(huì)找到比較滿意的答案。

需求確認(rèn)如何保證需求規(guī)格說(shuō)明書的質(zhì)量？正確性完備性易理解性一致性可行性健壯性易修改性易測(cè)試性和可修改性易追溯性兼容性2021/3/1130.什么是好的需求規(guī)格說(shuō)明書.1正確

需求規(guī)格說(shuō)明書應(yīng)當(dāng)正確地反映用戶的真實(shí)意圖，“正確”是《產(chǎn)品需求規(guī)格說(shuō)明書》最重要的屬性。如果“不正確”僅僅是由于錯(cuò)別字造成的，那么多檢查幾遍文檔就能解決問(wèn)題。真正的困難是開(kāi)發(fā)者和用戶自己都不明白用戶究竟“想要什么”和“不要什么”。為確保需求是正確的，開(kāi)發(fā)方和用戶必須對(duì)《需求規(guī)格說(shuō)明書》進(jìn)行確認(rèn)。.2清楚

清楚的需求讓人易讀易懂。清楚的反義詞是“難讀”、“難理解”。你可以采用反問(wèn)的方式來(lái)判斷需求文檔是否清楚：文檔的結(jié)構(gòu)、段落是否亂七八糟？上下文是否不連貫？文檔的語(yǔ)句是否含糊其詞、羅里羅嗦？看了半天是否還不明白需求究竟是什么？.3無(wú)二義性

“無(wú)二義性”是指每個(gè)需求只有唯一的含義。如果一個(gè)人說(shuō)的話，不同的人可能有不同的理解，那么這句話就有二義性。如果需求存在二義性，將會(huì)導(dǎo)致人們誤解需求而開(kāi)發(fā)出偏離需求的產(chǎn)品。為了使需求無(wú)二義性，人們?cè)趯憽懂a(chǎn)品需求規(guī)格說(shuō)明書》時(shí)措詞應(yīng)當(dāng)準(zhǔn)確，切勿模棱兩可。什么是好的需求規(guī)格說(shuō)明書.4一致

“一致”（Consistent）是指《產(chǎn)品需求規(guī)格說(shuō)明書》中各個(gè)需求之間不會(huì)發(fā)生矛盾。矛盾常常潛伏在需求文檔的上下文中。.5必要

《產(chǎn)品需求規(guī)格說(shuō)明書》中的各項(xiàng)需求對(duì)用戶而言應(yīng)當(dāng)都是必要的?？梢园选氨匾北扔鳛椤把┲兴吞俊薄！氨匾蓖耙徊?，要么是“畫蛇添足”要么是“錦上添花”?！爱嬌咛碜恪憋@然是壞事，會(huì)導(dǎo)致開(kāi)發(fā)人員多干一些吃力不討好的工作。所以要盡量剔除需求規(guī)格說(shuō)明書中“畫蛇添足”的那些需求?！板\上添花”是好事，可能會(huì)讓用戶獲得比期望更多的喜悅，但是眼前用戶不會(huì)為此多付錢。開(kāi)發(fā)者應(yīng)當(dāng)集中精力先完成必要的需求，如果條件允許則再做“錦上添花”的需求。為了避免主次顛倒，應(yīng)當(dāng)在《產(chǎn)品需求規(guī)格說(shuō)明書》中將那些“錦上添花”的需求設(shè)置為較低的優(yōu)先級(jí)。.6完備“完備”（Complete）是指《產(chǎn)品需求規(guī)格說(shuō)明書》中沒(méi)有遺漏一些必要的需求。人們往往傾向于關(guān)注系統(tǒng)的特色功能，而忽視了其它一些不起眼的但卻是必需的功能。不完備的《產(chǎn)品需求規(guī)格說(shuō)明書》將導(dǎo)致產(chǎn)生功能不完整的軟件，用戶在使用該軟件時(shí)可能無(wú)法完成預(yù)期的任務(wù)。.什么是好的需求規(guī)格說(shuō)明書7可實(shí)現(xiàn)

《產(chǎn)品需求規(guī)格說(shuō)明書》中的各項(xiàng)需求對(duì)開(kāi)發(fā)方而言應(yīng)當(dāng)都是可實(shí)現(xiàn)的（Attainable）?！翱蓪?shí)現(xiàn)”意味著在技術(shù)上是可行的，并且滿足時(shí)間、費(fèi)用、質(zhì)量等約束。營(yíng)銷人員和用戶談生意時(shí)，為了能拿到“單子”，他們往往對(duì)用戶提出的需求“來(lái)者不拒”。吹牛皮雖然不犯法，但是《產(chǎn)品需求規(guī)格說(shuō)明書》可是白紙黑字啊。經(jīng)過(guò)雙方確認(rèn)的《產(chǎn)品需求規(guī)格說(shuō)明書》相當(dāng)于商業(yè)合同，如果開(kāi)發(fā)方不能夠?qū)崿F(xiàn)《產(chǎn)品需求規(guī)格說(shuō)明書》中的內(nèi)容，那就是違約，可能會(huì)被罰款的。對(duì)于合同項(xiàng)目，如果開(kāi)發(fā)方不能確信某些需求是否可實(shí)現(xiàn)，則應(yīng)事先與用戶協(xié)商，達(dá)成一致的處理意見(jiàn)，避免將來(lái)發(fā)生商業(yè)糾紛。.8可驗(yàn)證

《產(chǎn)品需求規(guī)格說(shuō)明書》中的各項(xiàng)需求對(duì)用戶方而言應(yīng)當(dāng)都是可驗(yàn)證的（Verifiable）。如果需求是不可驗(yàn)證的，那么用戶就無(wú)法驗(yàn)收軟件，可能會(huì)發(fā)生商業(yè)糾紛。例如，摩天大樓的一項(xiàng)需求是“抗十二級(jí)臺(tái)風(fēng)”，這個(gè)需求看起來(lái)堂而皇之，但是如何驗(yàn)證呢？當(dāng)摩天大樓完工后驗(yàn)收時(shí)，用戶又不是巫師，他怎能造個(gè)十二級(jí)臺(tái)風(fēng)來(lái)試驗(yàn)？如果雙方都認(rèn)可“采用計(jì)算機(jī)模擬十二級(jí)臺(tái)風(fēng)”等效于實(shí)際測(cè)試，那么這項(xiàng)需求就是“可驗(yàn)證”的。.什么是好的需求規(guī)格說(shuō)明書.9確定優(yōu)先級(jí)為什么要確定需求的“優(yōu)先級(jí)”？理論上講，軟件的所有需求都應(yīng)當(dāng)被實(shí)現(xiàn)。但是在現(xiàn)實(shí)之中，項(xiàng)目存在“進(jìn)度、費(fèi)用、人力資源”等限制。在項(xiàng)目剛開(kāi)始的時(shí)候，開(kāi)發(fā)方和客戶比較樂(lè)觀，什么都要做，可是做著做著，人們常常會(huì)面臨“進(jìn)度延誤、費(fèi)用超支、人員不足”等問(wèn)題，這時(shí)就亂套了。人們想出了“取舍”辦法：先做優(yōu)先級(jí)高的需求，后做（甚至放棄）優(yōu)先級(jí)低的需求，這樣可以將風(fēng)險(xiǎn)降到最低。需求的優(yōu)先級(jí)其實(shí)就是需求“輕重緩急”的分級(jí)表述，例如劃分為“高、中、低”三級(jí)。一般地，由用戶和開(kāi)發(fā)方共同確定需求的優(yōu)先級(jí)。10闡述“做什么”而不是“怎么做”《產(chǎn)品需求規(guī)格說(shuō)明書》的重點(diǎn)是闡述“做什么”，而不是闡述“怎么做”?！霸趺醋觥笔窍到y(tǒng)設(shè)計(jì)和實(shí)現(xiàn)階段的事情。國(guó)內(nèi)的很多軟件公司里，開(kāi)發(fā)人員常常身兼數(shù)職，可能把需求開(kāi)發(fā)、系統(tǒng)設(shè)計(jì)、編程等工作從頭做到尾。所以他們?cè)谡{(diào)查、分析、定義需求時(shí)，自然會(huì)想到“怎么做”，這并沒(méi)有什么過(guò)錯(cuò)。如果在調(diào)查、定義需求時(shí)想好了“怎么做”，當(dāng)然應(yīng)該寫下來(lái)，否則豈不浪費(fèi)！關(guān)鍵是不要將“怎么做”寫到需求規(guī)格說(shuō)明書里面，記錄在其它文檔里就行了。良好的需求規(guī)格說(shuō)明的例子-1例子：“產(chǎn)品應(yīng)在不少于每60秒的正常周期內(nèi)提供狀態(tài)信息”分析：這個(gè)需求是不完整的：狀態(tài)信息是什么，如何顯示給用戶。這個(gè)需求有幾處含糊。我們?cè)谡務(wù)摦a(chǎn)品的哪部分？狀態(tài)信息間隔真的假定為不少于60秒？，甚者每10年顯示一條新的狀態(tài)信息也可以？也許它的意圖是消息間隔不應(yīng)超過(guò)60秒，那么1毫秒是不是太短？“每”這個(gè)詞導(dǎo)致了不確定性。問(wèn)題的后果，就是需求的不可證實(shí)。彌補(bǔ)缺陷，重寫需求的一種方法：n后臺(tái)任務(wù)管理器因以誤差上下不超過(guò)10秒的60秒間隔，在用戶界面的指定位置顯示狀態(tài)信息；n如果后臺(tái)進(jìn)程處理正常，那么應(yīng)該顯示任務(wù)已完成的百分?jǐn)?shù)/比；n任務(wù)完成時(shí)，應(yīng)顯示相關(guān)的信息；n后臺(tái)任務(wù)出錯(cuò)應(yīng)該顯示錯(cuò)誤信息；為了測(cè)試和追蹤，將需求分解多個(gè)子需求。使在構(gòu)造和測(cè)試時(shí)，被易于分別執(zhí)行。良好的需求規(guī)格說(shuō)明的例子-2例子：“產(chǎn)品應(yīng)瞬間在文本中的顯示和隱藏不可打印字符間切換”

計(jì)算機(jī)在瞬間不能做任何事，所以這個(gè)需求不切實(shí)可行。它的不完整性表現(xiàn)在沒(méi)有聲明觸發(fā)狀態(tài)切換的條件。軟件要在某些條件下更改自己？或者用戶為了模仿更改要做一些什么動(dòng)作？而且，在文檔中改變顯示的范圍是多大：選中的文本？整個(gè)的文檔，或其他的？這也是個(gè)模糊的問(wèn)題。不可打印字符和隱藏字符一樣嗎？或者是一些屬性標(biāo)志或一些控制字符？問(wèn)題的后果，就是需求的不可證實(shí)。像這樣編寫需求也許更好一些：用戶能夠在一個(gè)由特定觸發(fā)條件激活處于編輯的文檔中在顯示和隱藏所有HTML標(biāo)記間切換。現(xiàn)在就很清楚，不可打印字符是HTML標(biāo)記。由于沒(méi)有定義觸發(fā)條件，需求對(duì)設(shè)計(jì)沒(méi)有約束力。只有設(shè)計(jì)人員選定了觸發(fā)條件后，你才能編寫測(cè)試驗(yàn)證觸發(fā)的正確操作。良好的需求規(guī)格說(shuō)明的例子-3例子：“HTML分析器可以產(chǎn)生HTML標(biāo)記錯(cuò)誤報(bào)告，幫助HTML入門者快速解決錯(cuò)誤”。單詞“快速”使其模糊，沒(méi)有加進(jìn)錯(cuò)誤報(bào)告的定義也是不完整的。我不知道，你怎么驗(yàn)證這個(gè)需求。找一個(gè)自稱為HTML的入門者，看看能不能根據(jù)錯(cuò)誤報(bào)告快速解決錯(cuò)誤？試試這個(gè)：“HTML分析器可以產(chǎn)生一個(gè)錯(cuò)誤報(bào)告，錯(cuò)誤報(bào)告包含有在被分析文件中出錯(cuò)的HTML文本和行號(hào)以及錯(cuò)誤的描述。如果沒(méi)有錯(cuò)誤，就不會(huì)產(chǎn)生錯(cuò)誤報(bào)告”?，F(xiàn)在我們知道了，什么會(huì)被加到出錯(cuò)報(bào)告中，但是出錯(cuò)報(bào)告是個(gè)什么樣子，則留由設(shè)計(jì)人員決定。我們還指定了一個(gè)例外：如果沒(méi)有發(fā)現(xiàn)錯(cuò)誤，不產(chǎn)生錯(cuò)誤報(bào)告。需求跟蹤1.需求的標(biāo)識(shí)<需求類型><需求#>需求類型可以是：F=功能需求，D=數(shù)據(jù)需求，B=行為需求，I=接口需求；O=輸出需求。

例：需求標(biāo)識(shí)為F03的需求表示編號(hào)為3的功能需求。2021/3/1138需求跟蹤2.需求的屬性創(chuàng)建需求的時(shí)間需求的版本號(hào)創(chuàng)建需求的作者負(fù)責(zé)認(rèn)可該需求的人員需求狀態(tài)需求的原因或根據(jù)（或信息的出處）需求涉及的子系統(tǒng)需求涉及的產(chǎn)品版本號(hào)……2021/3/1139需求跟蹤3.需求狀態(tài)

已建議——該需求已被有權(quán)提出需求的人建議

已批準(zhǔn)——該需求已被分析，估計(jì)了其對(duì)項(xiàng)目余下部分的影響（包括成本和對(duì)項(xiàng)目其余部分的干擾），已有一個(gè)確定的產(chǎn)品版本號(hào)或編號(hào)，軟件開(kāi)發(fā)團(tuán)隊(duì)已同意實(shí)現(xiàn)該項(xiàng)需求

已實(shí)現(xiàn)——使用所選擇的方法已驗(yàn)證了實(shí)現(xiàn)的需求，例如測(cè)試和檢測(cè)，審查該需求跟蹤與測(cè)試用例相符。該需求現(xiàn)在被認(rèn)為完成

已刪除——計(jì)劃的需求已被刪除，并包含一個(gè)原因說(shuō)明和作出刪除決定的人員2021/3/11404.3.2需求狀態(tài)的變化在需求獲取、分析、處理、驗(yàn)證階段，我們已經(jīng)得到了獲得用戶和項(xiàng)目組達(dá)成共識(shí)的需求，并且，已經(jīng)建立了需求數(shù)據(jù)庫(kù)，建立了需求基線。從需求實(shí)現(xiàn)階段來(lái)看，需求在這個(gè)階段，仍然受各種因素的影響，產(chǎn)生不可預(yù)料的變化。狀態(tài)定義被建議根據(jù)需求來(lái)源，責(zé)任、相關(guān)人提出了需求。被拒絕在一系列需求開(kāi)發(fā)過(guò)程后，該需求沒(méi)有被認(rèn)可。被批準(zhǔn)在需求（特別是變更需求）被分析，評(píng)估了合理、可行、成本、影響等要素，被確認(rèn)可接受，被標(biāo)注了新的版本號(hào)、給出了新的標(biāo)號(hào)等需求屬性、被加入到需求基線庫(kù)中，進(jìn)入實(shí)現(xiàn)過(guò)程。被實(shí)現(xiàn)已實(shí)現(xiàn)設(shè)計(jì)、編碼、單元測(cè)試。被驗(yàn)證根據(jù)驗(yàn)收標(biāo)準(zhǔn)，已經(jīng)通過(guò)集成以上的測(cè)試，被驗(yàn)證實(shí)現(xiàn)了需求的要求，被放置進(jìn)配置基線庫(kù)。表明需求已經(jīng)被實(shí)現(xiàn)。被丟棄被批準(zhǔn)的需求已從基線庫(kù)中被丟棄。記錄下丟棄的原因和決定責(zé)任人。被交付通過(guò)用戶的驗(yàn)收測(cè)試，需求以交付物的形式，向用戶提交。2021/3/1141需求實(shí)現(xiàn)過(guò)程——需求狀態(tài)變化在需求狀態(tài)的變化中，軟件項(xiàng)目經(jīng)理第一位需要關(guān)注的是那些被拒絕、被丟棄的需求。因?yàn)槿绻皇峭ㄟ^(guò)有管理的處理過(guò)程，這些需求有可能是應(yīng)該被接受、并被實(shí)現(xiàn)的需求，而成為系統(tǒng)的疏忽而遺漏？項(xiàng)目經(jīng)理也應(yīng)該關(guān)注被交付的需求，因?yàn)樽鳛轫?xiàng)目經(jīng)理，他的主要責(zé)任是項(xiàng)目階段的里程碑控制。項(xiàng)目階段里程碑是應(yīng)交付成果，交付成果最主要的內(nèi)容，就是需求的實(shí)現(xiàn)。（其他的交付物還有：文檔、培訓(xùn)、服務(wù)等）。2021/3/11424.3.3需求狀態(tài)變化的追蹤如果我們能夠做到軟件需求的定義，那么，通過(guò)跟蹤定義了的需求，我們就能夠知道需求在實(shí)現(xiàn)過(guò)程中的具體實(shí)現(xiàn)細(xì)節(jié)與目標(biāo)的距離。在可追蹤的需求實(shí)現(xiàn)過(guò)程中，項(xiàng)目經(jīng)理才能夠有把握地說(shuō)，需求被正確地實(shí)現(xiàn)了。2021/3/1143需求跟蹤正向跟蹤：以用戶需求為切入點(diǎn)，檢查《用戶需求說(shuō)明書》或《需求規(guī)格說(shuō)明書》中的每個(gè)需求是否都能在后繼工作產(chǎn)品中找到對(duì)應(yīng)點(diǎn)。逆向跟蹤：檢查設(shè)計(jì)文檔、代碼、測(cè)試用例等工作產(chǎn)品是否都能在《需求規(guī)格說(shuō)明書》中找到出處。正向跟蹤和逆向跟蹤合稱為“雙向跟蹤”。2021/3/1144需求跟蹤

正向跟蹤和逆向跟蹤合稱為“雙向跟蹤”。不論采用何種跟蹤方式，都要建立與維護(hù)需求跟蹤矩陣（即表格）。需求跟蹤矩陣保存了需求與后繼工作成果的對(duì)應(yīng)關(guān)系。

2021/3/1145需求發(fā)生變更的起因主要有：隨著項(xiàng)目的進(jìn)展，人們（包括開(kāi)發(fā)方和客戶方）對(duì)需求的了解越來(lái)越深入。原先的需求文檔可能存在這樣那樣的錯(cuò)誤或不足，因此要變更需求。市場(chǎng)發(fā)生了變化，原先的需求文檔可能跟不上當(dāng)前的市場(chǎng)需求，因此要變更需求。提出需求變更的動(dòng)機(jī)是好的，目的是希望產(chǎn)品更加符合用戶的需求。對(duì)項(xiàng)目開(kāi)發(fā)小組而言，變更需求意味著要調(diào)整資源、重新分配任務(wù)、修改前期工作成果等，開(kāi)發(fā)小組要為此付出較重的代價(jià)。如果每次需求變更請(qǐng)求都被采納的話，這個(gè)項(xiàng)目也許永遠(yuǎn)不能按時(shí)完成。需求變更控制的目的：如果需求變更帶來(lái)的好處大于壞處，那么允許變更，但必須按照已定義的變更規(guī)程執(zhí)行，以免變更失去控制。如果需求變更帶來(lái)的壞處大于好處，那么拒絕變更。需求變更控制過(guò)程中最難辦的事情是莫過(guò)于“拒絕客戶提出的需求變更請(qǐng)求”。通常情況下開(kāi)發(fā)方是不敢得罪客戶的，但是無(wú)原則地退讓將使開(kāi)發(fā)小組陷入困境。解決這個(gè)問(wèn)題最好的辦法是事先建立“游戲規(guī)則”：開(kāi)發(fā)方與客戶方達(dá)成“事不過(guò)三”的約定（符合中國(guó)人的習(xí)慣），即允許客戶變更三次需求；如果客戶第四此變更需求，開(kāi)發(fā)方有權(quán)拒絕，除非客戶愿意補(bǔ)償開(kāi)發(fā)方的損失。如果事先沒(méi)有“游戲規(guī)則”的話，開(kāi)發(fā)方需要一些社交技巧來(lái)減緩矛盾。例如建議在開(kāi)發(fā)該產(chǎn)品新版本時(shí)修改需求。需求變更控制4.4.1需求變更管理的重要性需求變更的原因多種多樣，但管理變更，應(yīng)確立以下原則：（1）認(rèn)識(shí)到變更是不可避免的，為變更指定計(jì)劃；（2）確定需求基線；（3）建立控制變更的唯一渠道（4）使用變更控制系統(tǒng)來(lái)控制變更過(guò)程；（5）分層次地管理變更。2021/3/11474.4.2需求變更控制活動(dòng)6大需求變更控制活動(dòng)

（1）確定需求變更控制過(guò)程：確定需求變更的選擇、分析、決策、記錄的過(guò)程，所有需求的變更，都要在選擇、分析、決策、記錄環(huán)節(jié)上，受到機(jī)制和責(zé)任的保證。（2）建立需求變更控制委員會(huì)：組織公司、項(xiàng)目組內(nèi)部和用戶利益和風(fēng)險(xiǎn)承擔(dān)人員，成立需求變更控制委員會(huì)，由他們來(lái)決定要變更哪些需求，是否在項(xiàng)目范圍之內(nèi)（包括：項(xiàng)目范圍和合同范圍。因?yàn)橛袝r(shí)，在項(xiàng)目范圍，但不在合同范圍，需要項(xiàng)目進(jìn)行二期合同開(kāi)發(fā)），評(píng)估變更的波及，最后決定變更是可以接受，還是放棄。對(duì)變更的需求設(shè)置優(yōu)先級(jí)、制定版本規(guī)定等。

2021/3/1148需求變更——6大需求變更控制活動(dòng)（3）進(jìn)行需求變更影響分析：波及分析有利于對(duì)需求變更要求，進(jìn)行更深入、精確的理解，幫助變更控制委員會(huì)做出科學(xué)的決策。波及分析還可以幫助項(xiàng)目組對(duì)現(xiàn)有系統(tǒng)做出合理的、有前瞻性的調(diào)整，使面對(duì)日后新的需求變更，有充足的技術(shù)準(zhǔn)備。波及分析完全依賴于需求的跟蹤能力。沒(méi)有需求形式化記錄、沒(méi)有需求跟蹤鏈，就沒(méi)有波及分析的可能。如果有，也是主觀的、非定量的。由此對(duì)項(xiàng)目計(jì)劃、成本、質(zhì)量控制的影響分析，其可信度是有疑問(wèn)的。系統(tǒng)分析師和架構(gòu)師應(yīng)評(píng)估變更對(duì)系統(tǒng)技術(shù)實(shí)現(xiàn)的影響。項(xiàng)目經(jīng)理應(yīng)根據(jù)新需求，明確相關(guān)任務(wù)，評(píng)估新的工作量和相應(yīng)的要求變化。新需求不但導(dǎo)致分析、編碼、測(cè)試的工作量增加，項(xiàng)目管理有關(guān)的各環(huán)節(jié)（需求管理、計(jì)劃管理、成本管理、配置管理、質(zhì)量管理等）都會(huì)有所變化。在需求變更評(píng)估分析中，也要做需求穩(wěn)定性評(píng)估。頻繁地需求變更，應(yīng)該超出了需求變化的范圍。項(xiàng)目經(jīng)理要考慮項(xiàng)目組織管理方面，是不是發(fā)生了什么問(wèn)題。

2021/3/1149需求變更——6大需求變更控制活動(dòng)（4）跟蹤所有受需求變更影響的工作產(chǎn)品：當(dāng)確定某一需求發(fā)生變更時(shí)，根據(jù)需求跟蹤矩陣，找到與變更需求有關(guān)的各層、各環(huán)節(jié)需求項(xiàng)。例如：涉及需求項(xiàng)的設(shè)計(jì)模型、代碼模塊、測(cè)試用例等。這些部分全部必須做相應(yīng)的修改。依據(jù)需求跟蹤矩陣，可以完整地追蹤到需求變更所影響到的所有地方，可以不會(huì)發(fā)生遺漏，而產(chǎn)生系統(tǒng)BUG，或產(chǎn)品缺陷。甚至包括對(duì)軟件產(chǎn)品本身以外的影響，如：因需求變更，版本控制沒(méi)有相應(yīng)的記錄、產(chǎn)品使用手冊(cè)沒(méi)有做相應(yīng)修改等。因?yàn)樾枨笞兏?，需求狀態(tài)記錄應(yīng)相應(yīng)地發(fā)生變化。每一條記錄，反映了需求的現(xiàn)實(shí)情況。

（5）調(diào)整需求基線：需求變化以后，需求變更控制委員會(huì)要決定是否調(diào)整需求基線。新需求是反映為基線的調(diào)整，還是版本的變化?；€是產(chǎn)品的標(biāo)準(zhǔn)，基線變化可以作為產(chǎn)品標(biāo)準(zhǔn)的變化，也可以理解為將發(fā)行一個(gè)新版本的產(chǎn)品。2021/3/1150需求變更——6大需求變更控制活動(dòng)但是，版本并不一定就是新產(chǎn)品。因?yàn)?，?dāng)產(chǎn)品面對(duì)不同地區(qū)、不同用戶群的時(shí)候，也可以確定不同的版本。因此，需求變更控制委員會(huì)要做的工作，是對(duì)新需求，決定是全面升版，還是局部更改。是基線變化，還是個(gè)別版本變化。有時(shí)，這是一個(gè)比較難于做出的決定，他依賴于對(duì)新需求的分析，評(píng)估它對(duì)市場(chǎng)、用戶和產(chǎn)品本身的影響。

（6）維護(hù)需求變更記錄和文檔：決定變更基線或提升版本以后，就要做好記錄，修改相應(yīng)的文檔。變更記錄要記錄變更原因、變更內(nèi)容、變更影響、變更實(shí)現(xiàn)過(guò)程、其他相應(yīng)變更等。變更記錄越完整，對(duì)于追溯，甚至以后可能發(fā)生的回退，就越有幫助。有一些版本控制工具，可以幫助項(xiàng)目經(jīng)理來(lái)做到記錄相應(yīng)的信息。2021/3/11514.4.3需求變更波及分析變更波及分析的意義對(duì)于項(xiàng)目組來(lái)說(shuō)，一個(gè)新的需求提出來(lái)以后，這個(gè)需求如果接受，可能對(duì)系統(tǒng)造成多大的影響？系統(tǒng)結(jié)構(gòu)上的、數(shù)據(jù)結(jié)構(gòu)上的、涉及的模塊、版本上的變更影響有多大？需求波動(dòng)在技術(shù)上有潛伏性，在工程上，也表現(xiàn)為不可預(yù)知性。工作量不可預(yù)知、成本不可預(yù)知。項(xiàng)目經(jīng)理往往受市場(chǎng)人員的壓力，對(duì)用戶宣稱“免費(fèi)維護(hù)”，但在項(xiàng)目組內(nèi)部，對(duì)于需求變更的成本，甚至可能是“巨大”的。這種不理智的“反差”，正好說(shuō)明了我們軟件項(xiàng)目管理的水平，是處在原始和粗放的狀態(tài)。需求波及分析是軟件項(xiàng)目管理的需求管理比較重要的組成部分，在需求變更決策前，通過(guò)波及分析，可以達(dá)到精確理解需求、評(píng)估系統(tǒng)對(duì)需求變更要求的接納程度、變更的代價(jià)、變更對(duì)系統(tǒng)總體架構(gòu)、甚至產(chǎn)品發(fā)展的影響等。這樣的分析，對(duì)需求變更委員會(huì)做出變更批準(zhǔn)還是放棄的決策，具有重要的意義。一旦變更控制委員會(huì)批準(zhǔn)需求變更的要求，就能比較清晰地知道相應(yīng)變更的內(nèi)容、工作范圍、需要的時(shí)間等。需求變更波及分析也是保證項(xiàng)目組在需求變更以后，可以做到“在計(jì)劃、成本、質(zhì)量（不是降低質(zhì)量標(biāo)準(zhǔn)為代價(jià)）范圍的變更”。2021/3/1152需求變更——變更波及的內(nèi)部分析系統(tǒng)元素波及分析包括：（1）

所有涉及到的輸入界面有關(guān)部分；（2）

所有涉及到的報(bào)表等輸出界面有關(guān)部分；（3）

所有涉及到的外部接口部分；（4）

所有涉及到的內(nèi)部接口部分；（5）

所有涉及到的數(shù)據(jù)庫(kù)表結(jié)構(gòu)；（6）

所有涉及到的系統(tǒng)數(shù)據(jù)定義；（7）

所有涉及到的公用模塊定義、公用子程序庫(kù)、控件庫(kù)；（8）

所有涉及到的系統(tǒng)常量、宏定義；（9）

所有涉及到的已經(jīng)實(shí)現(xiàn)的代碼；（10）

所有涉