何謂需求?簡單的理解，就是用戶期望軟件達(dá)到的效果。既然是期望，一個看不見摸不到的東西，憑著客戶去想，再讓研發(fā)人員去分析，理想與現(xiàn)實的差距也就慢慢顯現(xiàn)出來。用戶的需求分析不準(zhǔn)，需求的界限又難以清除的劃定，失敗的由頭便開始埋下，畢竟需求才是軟件的始源。因此，對軟件開發(fā)我一直持悲觀的態(tài)度，在處理用戶需求方面也是謹(jǐn)慎的避免歧義的產(chǎn)生，而非單方面激進的提出過多的功能設(shè)想。
大多數(shù)情況下，在軟件未開發(fā)之前，用戶對軟件功能的要求是非常多的，用一句業(yè)內(nèi)話來說，就是他希望點一下按鈕就解決所有的問題。這是用戶的理想，當(dāng)然也是軟件供應(yīng)商的理想，但終歸是理想?，F(xiàn)實來說，這個要求很難滿足，我們惟有對用戶的要求一一分析，分清主次，量力而行。
現(xiàn)在很多管理類文檔將需求分為合理需求和不合理需求兩種類型，這種分類方式本身并沒有錯誤，但在實際判斷起來卻很難，主要是無法清晰的界定合理和不合理的屬性，用戶和研發(fā)人員的出發(fā)點是不一樣的，每個研發(fā)人員也都有各自的認(rèn)識，很難確定合理與不合理的標(biāo)準(zhǔn)。因此我更主張將需求按重要程度進行分級，需要解決用戶核心問題、必須問題的需求就是重要的，其他的就可以認(rèn)為是次要的，這就很容易區(qū)分了。而且不同的項目可以根據(jù)客戶與研發(fā)人員的共同認(rèn)識，靈活的定義重要程度的級次，可以都是重要的需求，可以分為重要的和次要的，也可以分為重要的、次要的和更次要的，每個項目都可以有自己的靈活性。需求分類好了，自然就可以在以重要需求為出發(fā)點，兼顧次要需求的基礎(chǔ)上來進行設(shè)計。
問題的關(guān)鍵開始轉(zhuǎn)移到如何具體的對用戶需求按重要程度進行分類。這個就是每個項目自己的靈活性了，如果你做的是財務(wù)系統(tǒng)，財務(wù)數(shù)據(jù)處理和票據(jù)打印就是重要需求;如果你做的是公文系統(tǒng)，文件撰寫和流程處理就是重要需求，等等。做為用戶和軟件研發(fā)人員，這方面的共識還是很容易達(dá)成的。如果要想做的更好，則可以將一個系統(tǒng)分成若干個子系統(tǒng)，每個子系統(tǒng)又分成若干個模塊，模塊再劃分成功能點，這樣每一個單元都給其標(biāo)注重要程度，一個清晰完整的需求框架就出來了。需求有了主次之分，則就容易做出取舍了。
對需求按重要程度進行分類可以認(rèn)為是需求分析在宏觀層面的東西，微觀方面則是對每一個需求點如何理解和處理。前者是項目經(jīng)理或需求負(fù)責(zé)人的責(zé)任，后者則是實際參與需求分析的團隊成員的責(zé)任。既然是微觀方面，則越詳細(xì)越好，越具體越好，模糊性的詞語一定要杜絕，如“大概”、“應(yīng)該”、“可能”等等。另外，大家還容易犯的毛病，就是文檔描述過于簡略，憑自己的感覺理解去敘述，把文檔的讀者只定義成自己，而不是完全基于需求事實，將文檔的讀者定義成所有參與項目的人。初入行者和懶于寫文檔的人都容易出現(xiàn)這種問題，但結(jié)果是，概括性的語言無限放大了大家對需求的理解，造成歧義。所以，需求越具體、詳細(xì)就越好，磨刀不誤砍柴功。
一言一蔽之，需求要先分主次，再具體分析。
需求分析是分多階段的，理想的流程是需求交流——〉分析整理——〉需求確認(rèn)——〉變更控制，實際情況下該流程會多次循環(huán)往復(fù)，這個過程當(dāng)中，變更控制顯得異常重要，它既是原需求的終止，又是新需求的開始，做好變更控制，往往事半功倍。
嚴(yán)格意義來講，在需求說明書經(jīng)過論證之后，用戶追加或補充的需求內(nèi)容才能稱為需求變更，因此需求變更貫穿了需求說明書經(jīng)過論證之后的所有軟件管理過程。
(一) 需求分析階段的需求變更
該部分的需求變更產(chǎn)生于需求分析階段的后期，也就是需求說明書論證之后。此時產(chǎn)生變更多少會影響軟件預(yù)期的進度，但由于尚未進行設(shè)計，因此對后續(xù)的過程影響不大。
(二) 系統(tǒng)設(shè)計階段的需求變更
并非所有的需求變更都會對系統(tǒng)架構(gòu)設(shè)計