對“需求分析報告”的簽名是建立在一個需求協(xié)議的基線上，因此我們對簽名應該這樣理解：“我同意這份需求文檔表述了我們對項目軟件需求的了解，進一步的變更可在此基線上通過項目定義的變更過程來進行。我知道變更可能會使我們重新協(xié)商成本、資源和項目階段任務等事宜?！睂π枨蠓治鲞_成一定的共識會使雙方易于忍受將來的摩擦，這些摩擦來源于項目的改進和需求的誤差或市場和業(yè)務的新要求等。 需求確認將迷霧撥散，顯現(xiàn)需求的真面目，給初步的需求開發(fā)工作畫上了雙方都明確的句號，并有助于形成一個持續(xù)良好的客戶與開發(fā)人員的關(guān)系，為項目的成功奠定了堅實的基礎(chǔ)。
六、點評需求分析誤區(qū)
要想說什么是好的需求分析，不如說什么是不好的需求分析，知道什么是不好的，自然也就知道了什么是好的。以下就是一些不好的情況：
（１）創(chuàng)意和求實
毋庸質(zhì)疑的，每個人都會為自己的一個新的Ｉｄｅａ而激動萬分，特別是當這個Ｉｄｅａ受到一些根本不知道你原本要干嘛的人的驚贊時。但是請注意，當你激動得意的時候，你可能已經(jīng)忘了你原本是在描述一個需求，而不是在策劃一個創(chuàng)意、創(chuàng)造一個概念。很多剛開始做需求分析的人員都或多或少的會犯這樣的錯誤，陶醉在自己的新想法和新思路中，卻違背了需求的原始客觀性和真實性原則。
永遠別忘了：需求不是空中樓閣，是實實在在的一磚一瓦。
（２）解剖的快感
幾乎所有搞軟件的人，做需求分析的時候，一上來就會把用戶告訴你的要求，完完整整的作個解剖，切開分成幾個塊，再細分成幾個子塊，然后再條分縷析?？墒钱斢脩裘曰蟮目粗阈列量嗫嘧龀鰜淼姆治鼋Y(jié)果問你：我想作一個數(shù)據(jù)備份的任務，怎么做？這時，你會發(fā)現(xiàn)，需要先后打開三個窗口才能完成這個任務。
永遠別忘了：分解是必需的，但最終的目的是為了更好的組合，而不是為了分解。
（３）角度和思維
經(jīng)常聽到這樣的抱怨：“用戶怎么可以提出這樣苛刻的要求呢？”。細細一了解，你會發(fā)現(xiàn)，用戶只不過是要求把一個需要兩次點擊的功能，改成只有一次點擊。這樣會導致需要改變需求、改變編碼、甚至重新測試，增加工作量?？墒?，如果換個角度來想想，這個功能，開發(fā)的時候只用了幾次、幾十次，可是用戶每天都要用幾百次甚 至幾千次幾萬次，改動一下就減少了一半的工作量，對他來說，這樣的需求難道會苛刻嗎？
永遠別忘了：沒有任何需求是不對的，不對的只是你的需求分析。試著站在用戶的思維角度想想，你的需求分析就會更加的貼近用戶，更加的合理。軟件應該是以人為本的。
（４）程序員邏輯
從程序員成長為系統(tǒng)分析員是一個普遍的軌跡，但并不是一個好的程序員就必然能成為一個好的系統(tǒng)分析員。一些程序員的固化邏輯，使得他們在做需求分析的時候往往鉆進了一些牛角里面。比如說１／０邏輯（或者是說黑白邏輯），認為不是這樣就是那樣，沒有第三種情況?？蓪嶋H情況往往是，在一定的時候是這樣，其它時候是那樣。又比如窮舉邏輯，喜歡上來就把所有一二三可能的情況列舉出來，然后一個一個分別處理，每個占用三分之一的時間；可是實際的情況往往是，三分之一的情況占了９９％的比例，其它兩種情況一年都不會遇到一次。實際中還有很多這樣的例子，不一一列舉了。
永遠別忘了：需求分析和程序設計不盡相同，合理、可行是才是重要的。跳出程序設計的圈子，站在系統(tǒng)的角度上來看問題，你的結(jié)論會截然不同。