計(jì)、編程、測試會(huì)與需求不一致，因此可以省略需求跟蹤。那么，需要指正的是，按照軟件生命周期嚴(yán)格線性順序的開發(fā)模型并不能保證各個(gè)開發(fā)階段的工作產(chǎn)品與需求保持一致。因?yàn)殚_發(fā)者是人而不是機(jī)器。而且，大多數(shù)開發(fā)人員也都深有體會(huì)。
    生活中“以訛傳訛”的例子，想必大家都很熟悉。學(xué)生甲在精工實(shí)習(xí)時(shí)被機(jī)器弄破了手指，于是到醫(yī)院包扎。同學(xué)乙路過醫(yī)院時(shí)看到甲的手血跡斑斑，以為甲的手指被機(jī)器割斷，于是將這個(gè)壞消息告訴同學(xué)丙。丙急忙轉(zhuǎn)告同學(xué)丁，說甲的手被機(jī)器割斷，正躺在醫(yī)院里。丁十萬火急地告訴全班同學(xué)，大家陷入悲痛之中，都以為“甲的胳膊被機(jī)器割斷了，正躺在醫(yī)院里，人快不行了?！?
    由于人們的表達(dá)能力、理解能力不可能完全相同，人與人之間的協(xié)作很難達(dá)到天衣無縫的境界。而使用需求追溯的本身也是一種傳遞的過程。
    需求追溯本身并不是一件復(fù)雜的事，而是我們的本身一種理念在支配著我們。也許就有人認(rèn)為這本身就是在浪費(fèi)時(shí)間，主要麻煩是，當(dāng)需求或工作產(chǎn)品發(fā)生變更時(shí)，開發(fā)人員要及時(shí)更新需求跟蹤矩陣。然而沒想到的事，如果后來再花時(shí)間來做同樣的事的時(shí)候，將會(huì)付出更多。也時(shí)也就丟去了本身做這件事的意義。
需求變更控制(Requirement Change Control)
    需求變更通常會(huì)對(duì)項(xiàng)目的進(jìn)度、人力資源產(chǎn)生很大的影響，這是開發(fā)商非常畏懼的問題。也是必須面臨與需要處理的問題。作為軟件項(xiàng)目，特別在外地實(shí)施的工程軟件項(xiàng)目而言，需求發(fā)生若干次變更似乎是不可避免的。需求發(fā)生變更的起因主要有：
隨著項(xiàng)目生命周期的不斷往前推進(jìn)，人們（包括開發(fā)方和客戶方）對(duì)需求的了解越來越深入。原先的提出的需求可能存在著一定的缺陷，因此要變更需求。
    市場業(yè)務(wù)需求發(fā)生了變化，原先的需求可能跟不上當(dāng)前的市場業(yè)務(wù)發(fā)展，因此要變更需求。由于市場變化而導(dǎo)致需求發(fā)生變更，開發(fā)商大可不必為此煩惱，應(yīng)當(dāng)高興才對(duì)。倘若市場靜如死水，那么開發(fā)商吃了“上一頓”就沒有“下一頓”。正因?yàn)槭袌鲈谧兓艜?huì)產(chǎn)生更多商機(jī)，聰明的開發(fā)商才會(huì)有活干，有錢賺。
    如果在項(xiàng)目開發(fā)的初始階段，開發(fā)人員和用戶沒有搞清楚需求或者搞錯(cuò)了需求，到了項(xiàng)目開發(fā)后期才將需求糾正過來，導(dǎo)致產(chǎn)品的部分內(nèi)容需要重新開發(fā)。毫無疑問，這種需求變更將使項(xiàng)目付出額外的代價(jià)。這種損失是由于雙方工作失誤造成的，雙方應(yīng)當(dāng)好好反省，認(rèn)真學(xué)習(xí)需求開發(fā)和管理的方法，避免再犯相似的錯(cuò)誤。
    總的而言，人們提出需求變更，本就是出于能夠是產(chǎn)品更加符合市場或客戶需求，出發(fā)點(diǎn)本身是好的。但對(duì)于開發(fā)小組而言，需求的變更則意味著要需要重新進(jìn)行估計(jì)，調(diào)整資源、重新分配任務(wù)、修改前期工作產(chǎn)品等，而作為開發(fā)商，需要增預(yù)算與投資，開發(fā)組要為此付出較重的代價(jià)。假定每次需求變更請(qǐng)求都被接受的話，那么這個(gè)項(xiàng)目將會(huì)成為一個(gè)連環(huán)式的工程。
需求變更控制的動(dòng)機(jī)是：
    如果需求變更帶來的好處大于壞處，那么允許變更，但必須按照已定義的變更規(guī)程執(zhí)行，以免變更失去控制。
    如果需求變更帶來的壞處大于好處，那么拒絕變更。
    當(dāng)然，好處與壞處并不是主觀的，而是通過客觀的分析與評(píng)價(jià)而得出的。
    對(duì)于需求的變更，在某一個(gè)程度上來說，也就是項(xiàng)目的范圍進(jìn)行了變化。而需求同時(shí)又是項(xiàng)目進(jìn)行的基礎(chǔ)。是非常得要的基石。通常對(duì)于需求的變更需要客戶與開發(fā)方共同參與，包括負(fù)責(zé)人及市場人員。當(dāng)然，我們需要根據(jù)變更的內(nèi)容來靈活運(yùn)用。
    需求變更控制過程中最難辦的事情是莫過于“拒絕客戶提出的需求變更請(qǐng)求”?？蛻魰?huì)想當(dāng)然地以為變更需求是他的權(quán)利，因?yàn)樗跺X給開發(fā)方。通常情況下開發(fā)方是不敢得罪客戶的，但是無原則地退讓將使開發(fā)小組陷入困境。怎么解決這個(gè)問題呢，通常情況下，每一類“游戲”都有一定的游戲規(guī)

    項(xiàng)目經(jīng)理勝任力免費(fèi)測評(píng)PMQ上線啦！快來測測你排多少名吧~

    http://m.opto-elec.com.cn/pmqhd/index.html