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

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

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