是可驗證的(Verifiable)。如果需求是不可驗證的，那么用戶就無法驗收軟件，可能會發(fā)生商業(yè)糾紛。
1.9 確定優(yōu)先級
需求的優(yōu)先級其實就是需求“輕重緩急”的分級表述，例如劃分為“高、中、低”三級。一般地，由用戶和開發(fā)方共同確定需求的優(yōu)先級。
1.10 闡述“做什么”而不是“怎么做”
開發(fā)人員常常身兼數(shù)職，可能把需求開發(fā)、系統(tǒng)設(shè)計、編程等工作從頭做到尾。他們經(jīng)常在整理需求的時候習(xí)慣性將如何實現(xiàn)的信息涵蓋在需求中，導(dǎo)致需求可讀性、可驗證性無法保證。
2、需求管理過程域 [部分定義摘錄于網(wǎng)絡(luò)]
需求管理的目的是在客戶與開發(fā)方之間建立對需求的共同理解，維護需求與其它工作成果的一致性，并控制需求的變更。
需求確認是指開發(fā)方和客戶共同對需求文檔進行評審，雙方對需求達成共識后作出書面承諾，使需求文檔具有商業(yè)合同效果。
需求跟蹤是指通過比較需求文檔與后續(xù)工作成果之間的對應(yīng)關(guān)系，建立與維護“需求跟蹤矩陣”，確保產(chǎn)品依據(jù)需求文檔進行開發(fā)。
需求變更控制是指依據(jù)“變更申請-審批-更改-重新確認”的流程處理需求的變更，防止需求變更失去控制而導(dǎo)致項目發(fā)生混亂。
2.1需求跟蹤
需求跟蹤的目的是建立與維護“需求-設(shè)計-編程-測試”之間的一致性，確保所有的工作成果符合用戶需求。 需求跟蹤有兩種方式：
正向跟蹤。檢查《產(chǎn)品需求規(guī)格說明書》中的每個需求是否都能在后繼工作成果中找到對應(yīng)點。
逆向跟蹤。檢查設(shè)計文檔、代碼、測試用例等工作成果是否都能在《產(chǎn)品需求規(guī)格說明書》中找到出處。
正向跟蹤和逆向跟蹤合稱為“雙向跟蹤”。不論采用何種跟蹤方式，都要建立與維護需求跟蹤矩陣(即表格)。需求跟蹤矩陣保存了需求與后繼工作成果的對應(yīng)關(guān)系。
我們就曾經(jīng)出現(xiàn)大家埋頭于開發(fā)，最后才發(fā)現(xiàn)項目協(xié)議書中的一個小基本功能沒有開發(fā)的事故。
2.2 變更管理
需求變更通常會對項目的進度、人力資源、經(jīng)費產(chǎn)生很大的影響。
如果在項目開發(fā)的初始階段，開發(fā)人員和用戶沒有搞清楚需求或者搞錯了需求，到了項目開發(fā)后期才將需求糾正過來，會導(dǎo)致產(chǎn)品的部分內(nèi)容需要重新開發(fā)。這是要堅決避免的。
如果由于市場變化而導(dǎo)致產(chǎn)品需求發(fā)生變更，開發(fā)商大可不必為此煩惱，應(yīng)當(dāng)高興才對。倘若市場靜如死水，那么開發(fā)商吃了“上一頓”就沒有“下一頓”。正因為市場在變化，才會產(chǎn)生更多商機，聰明的開發(fā)商才會有活干，有錢賺。
其實需求變更并不可怕，可怕的是需求變更失去控制，導(dǎo)致項目混亂。所以需求變更控制是需求工程的重要活動。如果需求變更帶來的好處大于壞處，那么允許變更，但必須按照已定義的變更規(guī)程執(zhí)行，以免變更失去控制。 如果需求變更帶來的壞處大于好處，那么拒絕變更。
需求變更控制過程中最難辦的事情是莫過于“拒絕客戶提出的需求變更請求”。通常情況下開發(fā)方是不敢得罪客戶的，但是無原則地退讓將使開發(fā)小組陷入困境。解決這個問題的一個辦法是事先建立規(guī)則：如開發(fā)方與客戶方達成“事不過三”的約定，即允許客戶變更三次需求;如果客戶第四此變更需求，開發(fā)方有權(quán)提請客戶補償開發(fā)投入。
3、深入理解需求
需求的開發(fā)和管理有一些規(guī)律或經(jīng)驗可以參考，核心是溝通確認、溝通控制。
3.1認清誰才是"上帝"
我們說客戶是上帝，是