一、 注意對(duì)需求規(guī)格說明的正確性進(jìn)行評(píng)審
需求規(guī)格說明的正確性通?？梢詮娜缦路矫娴靡泽w現(xiàn)：
是否有需求與其他需求相互沖突或者重復(fù)？通常一份長達(dá)幾百頁的需求規(guī)格說明書都不會(huì)是一蹴而就的，它可能是系統(tǒng)分析師幾個(gè)夜晚的心血之作。正是因?yàn)樽珜戇^程的連續(xù)性，可能導(dǎo)致同一份文檔中前后名詞定義不一致，前后觀點(diǎn)上有重疊或差異的情況出現(xiàn)，這需要我們?cè)谧珜憟?bào)告前首先要在思想上形成統(tǒng)一概念， 可使術(shù)語列表貫穿整份文檔以達(dá)提綱挈領(lǐng)之效。
是否清晰、簡潔、無二義地表達(dá)了每個(gè)需求？ “清晰”是讓人能夠讀懂；“簡潔”是讓人愿意去讀；“無二義”決定”讀”的效果，是讓大家對(duì)需求描述的理解能夠達(dá)成一致。需求陳述是“三重門”，這三扇門是否開啟決定了需求說明書的質(zhì)量高低。我們尤其要拒絕“二義性”的名詞術(shù)語的出現(xiàn)， 似是而非的概念定義是需求書應(yīng)該避免的。換句話說，如果一份需求說明書沒能給人以清晰、簡潔和無二義的闡述，則需求評(píng)審是沒有進(jìn)行下去的必要，同時(shí)也無法進(jìn)行下去。需求評(píng)審的前提是用戶讀懂了需求說明，并且用戶的理解內(nèi)容就是分析師們所描述的內(nèi)容。
是否每個(gè)需求都通過了演示、測(cè)試、評(píng)審，分析是否得到了驗(yàn)證？ 需求應(yīng)該是可以測(cè)試的，通常通過測(cè)試去驗(yàn)證它是不是正確。比如我們完成了“銷售員客戶傭金提成規(guī)則”需求的撰寫，如果需求書未能經(jīng)過原型測(cè)試通過，則需求評(píng)審是不能得到通過的。面對(duì)相當(dāng)復(fù)雜的業(yè)務(wù)需求，經(jīng)過測(cè)試或演示是讓用戶信任的一個(gè)必要過程。試想一下， 如果連需求都不能很好地被確認(rèn)，則開發(fā)實(shí)現(xiàn)階段更是沒有把握控制了。
是否每個(gè)需求都在項(xiàng)目的范圍內(nèi)？ 劃分項(xiàng)目范圍和區(qū)分系統(tǒng)邊界同樣是需求說明書的一個(gè)任務(wù)，不要對(duì)需求書作出超范圍的論述和延伸，要知道需求書不是分析師賣弄概念、展示時(shí)尚的場(chǎng)所，它是軟件工程的一個(gè)重要環(huán)節(jié)。
是否每個(gè)需求都沒有內(nèi)容和語法上的錯(cuò)誤？按照傳統(tǒng)的需求列表方式，需求像菜單一樣被一條條列出來，構(gòu)成需求項(xiàng)的主要欄位包括：需求ID、 需求描述、優(yōu)先級(jí)、來源和狀態(tài)等。 通常需求首先要經(jīng)過“拼寫檢查”，保證沒有拼寫上的問題，然后通過逐行瀏覽修改那些在內(nèi)容或行文上出現(xiàn)問題的需求。
在現(xiàn)有的資源內(nèi)， 是否能實(shí)現(xiàn)所有的需求？ 需求規(guī)格說明要考慮可行性的問題。事實(shí)上，分析師的關(guān)注層面是價(jià)值驅(qū)動(dòng)和成本驅(qū)動(dòng)方面。分析師應(yīng)該明白不是所有的需求都要去實(shí)現(xiàn)，一些看上去很明顯與涉及用戶有沖突的、費(fèi)力不討好的需求應(yīng)該果斷地舍棄。國內(nèi)有專家提出，搞需求也要講“和諧”即是此中道理。
每一條特定的錯(cuò)誤信息，是否都是的和具有含義的？ 不要忽視錯(cuò)誤信息的定義， 它必須具有性。如果過于籠統(tǒng)地定義錯(cuò)誤信息則和沒有定義的效果是一樣的。
二、 注意對(duì)需求規(guī)格說明的實(shí)踐性進(jìn)行評(píng)審
所謂實(shí)踐性是指需求本身是否來源于目前企業(yè)的相關(guān)業(yè)務(wù)規(guī)則和文件制度，而非源于分析師們經(jīng)驗(yàn)主義的臆測(cè)。實(shí)踐性是判斷需求規(guī)格說明是不是理論聯(lián)系實(shí)踐、密切和用戶聯(lián)系的一個(gè)關(guān)鍵性指標(biāo)。如果需求規(guī)格說明和用戶實(shí)踐脫離，即使看上去寫得再天花亂墜，也會(huì)使需求說明如同無根之樹、無源之水，會(huì)大大減低用戶對(duì)需求報(bào)告本身的信任度。
有經(jīng)驗(yàn)的系統(tǒng)分析師通常會(huì)迷信自己的經(jīng)驗(yàn)，把從前的經(jīng)驗(yàn)嫁接到目前的企業(yè)需求分析中。也許由于行業(yè)性質(zhì)相同，但如果不經(jīng)過當(dāng)前的實(shí)踐調(diào)研則給出需求，仍然會(huì)無法體現(xiàn)出企業(yè)自身的特征。因而不能為企業(yè)帶來真正的價(jià)值，也會(huì)造成與用戶需求的鴻溝。
筆者也曾經(jīng)“輕實(shí)踐重抽象”，我認(rèn)為系統(tǒng)分析師的工作特點(diǎn)是站在具體案例上的深度抽象，前提是必須獲得本企業(yè)的一手具體業(yè)務(wù)背景、流程和規(guī)則。
我們?cè)诜治霰热纭叭蝿?wù)跟蹤”之類的系統(tǒng)時(shí)，由于系統(tǒng)的抽象模型是已知的（通過大量同類軟件的分析得知），但還是需要分析師把抽象模型演繹到企業(yè)當(dāng)前業(yè)務(wù)現(xiàn)狀。這樣的需求分析才會(huì)有“實(shí)話實(shí)說”之效，才能引發(fā)評(píng)審者的共鳴。否則，在需求評(píng)審中評(píng)審者是很難讀懂你的意圖，自然不會(huì)立即通過你的需求報(bào)告，導(dǎo)致需要重新返工撰寫需求報(bào)告。
三、 注意對(duì)需求規(guī)格說明的完整性進(jìn)行評(píng)審
我們經(jīng)常由下面的問題清單來評(píng)審需求說明書是否“完整”。
1 編寫的所有需求，其詳細(xì)程度是否一致和合適？
2 需求是否能為設(shè)計(jì)提供足夠的基礎(chǔ)？
3 所有對(duì)其他需求的內(nèi)部引用是否正確？
4 是否包含了每個(gè)需求的實(shí)現(xiàn)優(yōu)先級(jí)？
5 是否定義了功能說明的內(nèi)在算法？
6 是否包含了所有已知的客戶需求或系統(tǒng)需求？
7 是否遺漏了必要的信息？如果有遺漏的話，把他們標(biāo)記為待確定的問題（TBD）？
8 是否對(duì)所有預(yù)期的錯(cuò)誤條件所產(chǎn)生的系統(tǒng)行為都編制了文檔？
需求說明的完整性主要體現(xiàn)在需求說明的詳細(xì)程度上，我們?cè)鯓优袛嘣撔枨蟮拿枋鍪欠裨敿?xì)呢？我認(rèn)為需求需要精化，而不是僅僅提出精化功能、對(duì)象要考慮涉眾參與者、做些什么、需要什么數(shù)據(jù)信息、受什么業(yè)務(wù)規(guī)則和條件限制、系統(tǒng)會(huì)有什么響應(yīng)，等等。
四、 注意對(duì)需求方案的可行性和成本預(yù)算進(jìn)行評(píng)審
考試大－全國大教育類網(wǎng)站(www．Examda。com)
需求方案的可行性和成本預(yù)算也是需求評(píng)審中的兩個(gè)重要方面。需求方案的可行性和成本預(yù)算評(píng)審的目的，是從需求的多項(xiàng)方案中選擇優(yōu)化的或者是性價(jià)比高的方案。一般而言，需求說明書可以給出同一個(gè)問題的幾種方案，并給出各自的優(yōu)缺點(diǎn)和成本差異，經(jīng)過比較由決策者作出終選擇。當(dāng)我們理解了需求說明，我們下一步需要對(duì)其分析是否有可行性。如果可行性高，則還要考慮它需要哪些資源和預(yù)算。我們需要確定技術(shù)是否確實(shí)滿足業(yè)務(wù)需求，同時(shí)， 也要考慮整個(gè)產(chǎn)品成本，包括開發(fā)人員、服務(wù)器、許可和升級(jí)費(fèi)用，還需要考慮初始硬件、軟件和支持、基礎(chǔ)結(jié)構(gòu)和培訓(xùn)的費(fèi)用。
五、 注意對(duì)需求的質(zhì)量屬性進(jìn)行評(píng)審
我們需要評(píng)審需求規(guī)格說明是否合理地確定了所有的性能目標(biāo)，是否合理地確定了安全性方面要考慮到的問題。系統(tǒng)性能需求之所以在概念階段即被要求，是因?yàn)楝F(xiàn)實(shí)的教訓(xùn)。君不見很多功能已經(jīng)完善的系統(tǒng)因?yàn)樾阅苌喜贿_(dá)標(biāo)，而被用戶束之高閣——用戶通常難以忍受運(yùn)行或響應(yīng)速度過慢的系統(tǒng)。
系統(tǒng)的安全性也是一個(gè)很重要的指標(biāo)，尤其是作為企業(yè)級(jí)的系統(tǒng)，它的安全考量完全繼承于組織對(duì)安全的基本訴求 。除了功能權(quán)限、字段級(jí)別權(quán)限外，數(shù)據(jù)間的授權(quán)關(guān)系也是必須考慮的，這本身也是一種業(yè)務(wù)規(guī)則。在“商機(jī)管理系統(tǒng)”需求分析中，“業(yè)務(wù)員A不能夠查看業(yè)務(wù)員B下達(dá)的訂單或相關(guān)信息”。所以，諸如此類的安全性需求在需求規(guī)格說明中是否被完整的描述，也是需求評(píng)審過程的一個(gè)硬性指標(biāo)?？偟恼f來，安全性包含了身份驗(yàn)證、訪問控制、加密和審核等考慮事項(xiàng)。
六、 注意對(duì)需求的可實(shí)施性進(jìn)行評(píng)審
是否對(duì)每個(gè)需求都設(shè)置了惟一性并且可以正確地識(shí)別它？是否每個(gè)功能需求都可以跟蹤到高層需求（比如系統(tǒng)需求或用例）？
需求必須可以測(cè)試，每個(gè)需求在特定的輸入條件下應(yīng)當(dāng)能給出已知的輸出結(jié)果。同時(shí)，需求應(yīng)當(dāng)層次分明，需要把單個(gè)需求下面的相關(guān)需求綜合在一起形成一組需求功能。
需求的可實(shí)施性除了可跟蹤性還包括可測(cè)試性。事實(shí)上， 分析人員和測(cè)試人員在編寫代碼以前把需求模型，分析模型和測(cè)試用例綜合起來通盤考慮，檢查出遺漏的、錯(cuò)誤的和不必要的需求。軟件需求在概念上的測(cè)試是一種很必要的技術(shù)，它可以在項(xiàng)目早期階段發(fā)現(xiàn)需求的歧義和錯(cuò)誤。
七、 注意對(duì)需求包含的用例文檔進(jìn)行評(píng)審
用例是參與者對(duì)系統(tǒng)和參與者的交互過程所達(dá)成的一種契約。需求說明書基于用例的分析方法是也是當(dāng)前較為流行的需求開發(fā)方式。用例文檔作為需求重要的成果性文檔也是需求評(píng)審主體之所在。需求評(píng)審確認(rèn)的重點(diǎn)是對(duì)關(guān)鍵用戶的常用和重要的用例進(jìn)行深入和細(xì)致的評(píng)審，首先要通過測(cè)試用例的主干過程。
八、 注意需求評(píng)審會(huì)的過程和結(jié)束標(biāo)準(zhǔn)
通常，需求評(píng)審會(huì)都不是件容易的事情，業(yè)務(wù)審查人員分散在各個(gè)地域和時(shí)間上的不一致性是困難產(chǎn)生的所在。在很多情況下，我們可以使用分布式需求評(píng)審軟件從網(wǎng)絡(luò)上對(duì)需求文檔進(jìn)行預(yù)先評(píng)審，而在評(píng)審會(huì)中則要注意不要使評(píng)審會(huì)演變成了“業(yè)務(wù)會(huì)”或“技術(shù)研討會(huì)”。同時(shí)，需求評(píng)審會(huì)的結(jié)果是對(duì)需求規(guī)格書完成了評(píng)審過程，那我們又如何判斷審查的結(jié)束標(biāo)準(zhǔn)呢？請(qǐng)看如下幾條建議：
1、審查期間評(píng)審員們提出的所有問題都已經(jīng)解決。
2、相關(guān)文檔中的所有更改都已經(jīng)正確完成。
3、修訂過的文檔進(jìn)行了拼寫檢查。
4、所有標(biāo)識(shí)為TBD（待確定）的問題已經(jīng)全部解決， 或者已經(jīng)對(duì)每個(gè)TBD的問題的解決過程、計(jì)劃解決的目標(biāo)日期和責(zé)任解決人等編制了文檔。
5、需求文檔正式進(jìn)入了配置庫。
需求規(guī)格說明的正確性通?？梢詮娜缦路矫娴靡泽w現(xiàn)：
是否有需求與其他需求相互沖突或者重復(fù)？通常一份長達(dá)幾百頁的需求規(guī)格說明書都不會(huì)是一蹴而就的，它可能是系統(tǒng)分析師幾個(gè)夜晚的心血之作。正是因?yàn)樽珜戇^程的連續(xù)性，可能導(dǎo)致同一份文檔中前后名詞定義不一致，前后觀點(diǎn)上有重疊或差異的情況出現(xiàn)，這需要我們?cè)谧珜憟?bào)告前首先要在思想上形成統(tǒng)一概念， 可使術(shù)語列表貫穿整份文檔以達(dá)提綱挈領(lǐng)之效。
是否清晰、簡潔、無二義地表達(dá)了每個(gè)需求？ “清晰”是讓人能夠讀懂；“簡潔”是讓人愿意去讀；“無二義”決定”讀”的效果，是讓大家對(duì)需求描述的理解能夠達(dá)成一致。需求陳述是“三重門”，這三扇門是否開啟決定了需求說明書的質(zhì)量高低。我們尤其要拒絕“二義性”的名詞術(shù)語的出現(xiàn)， 似是而非的概念定義是需求書應(yīng)該避免的。換句話說，如果一份需求說明書沒能給人以清晰、簡潔和無二義的闡述，則需求評(píng)審是沒有進(jìn)行下去的必要，同時(shí)也無法進(jìn)行下去。需求評(píng)審的前提是用戶讀懂了需求說明，并且用戶的理解內(nèi)容就是分析師們所描述的內(nèi)容。
是否每個(gè)需求都通過了演示、測(cè)試、評(píng)審，分析是否得到了驗(yàn)證？ 需求應(yīng)該是可以測(cè)試的，通常通過測(cè)試去驗(yàn)證它是不是正確。比如我們完成了“銷售員客戶傭金提成規(guī)則”需求的撰寫，如果需求書未能經(jīng)過原型測(cè)試通過，則需求評(píng)審是不能得到通過的。面對(duì)相當(dāng)復(fù)雜的業(yè)務(wù)需求，經(jīng)過測(cè)試或演示是讓用戶信任的一個(gè)必要過程。試想一下， 如果連需求都不能很好地被確認(rèn)，則開發(fā)實(shí)現(xiàn)階段更是沒有把握控制了。
是否每個(gè)需求都在項(xiàng)目的范圍內(nèi)？ 劃分項(xiàng)目范圍和區(qū)分系統(tǒng)邊界同樣是需求說明書的一個(gè)任務(wù)，不要對(duì)需求書作出超范圍的論述和延伸，要知道需求書不是分析師賣弄概念、展示時(shí)尚的場(chǎng)所，它是軟件工程的一個(gè)重要環(huán)節(jié)。
是否每個(gè)需求都沒有內(nèi)容和語法上的錯(cuò)誤？按照傳統(tǒng)的需求列表方式，需求像菜單一樣被一條條列出來，構(gòu)成需求項(xiàng)的主要欄位包括：需求ID、 需求描述、優(yōu)先級(jí)、來源和狀態(tài)等。 通常需求首先要經(jīng)過“拼寫檢查”，保證沒有拼寫上的問題，然后通過逐行瀏覽修改那些在內(nèi)容或行文上出現(xiàn)問題的需求。
在現(xiàn)有的資源內(nèi)， 是否能實(shí)現(xiàn)所有的需求？ 需求規(guī)格說明要考慮可行性的問題。事實(shí)上，分析師的關(guān)注層面是價(jià)值驅(qū)動(dòng)和成本驅(qū)動(dòng)方面。分析師應(yīng)該明白不是所有的需求都要去實(shí)現(xiàn)，一些看上去很明顯與涉及用戶有沖突的、費(fèi)力不討好的需求應(yīng)該果斷地舍棄。國內(nèi)有專家提出，搞需求也要講“和諧”即是此中道理。
每一條特定的錯(cuò)誤信息，是否都是的和具有含義的？ 不要忽視錯(cuò)誤信息的定義， 它必須具有性。如果過于籠統(tǒng)地定義錯(cuò)誤信息則和沒有定義的效果是一樣的。
二、 注意對(duì)需求規(guī)格說明的實(shí)踐性進(jìn)行評(píng)審
所謂實(shí)踐性是指需求本身是否來源于目前企業(yè)的相關(guān)業(yè)務(wù)規(guī)則和文件制度，而非源于分析師們經(jīng)驗(yàn)主義的臆測(cè)。實(shí)踐性是判斷需求規(guī)格說明是不是理論聯(lián)系實(shí)踐、密切和用戶聯(lián)系的一個(gè)關(guān)鍵性指標(biāo)。如果需求規(guī)格說明和用戶實(shí)踐脫離，即使看上去寫得再天花亂墜，也會(huì)使需求說明如同無根之樹、無源之水，會(huì)大大減低用戶對(duì)需求報(bào)告本身的信任度。
有經(jīng)驗(yàn)的系統(tǒng)分析師通常會(huì)迷信自己的經(jīng)驗(yàn)，把從前的經(jīng)驗(yàn)嫁接到目前的企業(yè)需求分析中。也許由于行業(yè)性質(zhì)相同，但如果不經(jīng)過當(dāng)前的實(shí)踐調(diào)研則給出需求，仍然會(huì)無法體現(xiàn)出企業(yè)自身的特征。因而不能為企業(yè)帶來真正的價(jià)值，也會(huì)造成與用戶需求的鴻溝。
筆者也曾經(jīng)“輕實(shí)踐重抽象”，我認(rèn)為系統(tǒng)分析師的工作特點(diǎn)是站在具體案例上的深度抽象，前提是必須獲得本企業(yè)的一手具體業(yè)務(wù)背景、流程和規(guī)則。
我們?cè)诜治霰热纭叭蝿?wù)跟蹤”之類的系統(tǒng)時(shí)，由于系統(tǒng)的抽象模型是已知的（通過大量同類軟件的分析得知），但還是需要分析師把抽象模型演繹到企業(yè)當(dāng)前業(yè)務(wù)現(xiàn)狀。這樣的需求分析才會(huì)有“實(shí)話實(shí)說”之效，才能引發(fā)評(píng)審者的共鳴。否則，在需求評(píng)審中評(píng)審者是很難讀懂你的意圖，自然不會(huì)立即通過你的需求報(bào)告，導(dǎo)致需要重新返工撰寫需求報(bào)告。
三、 注意對(duì)需求規(guī)格說明的完整性進(jìn)行評(píng)審
我們經(jīng)常由下面的問題清單來評(píng)審需求說明書是否“完整”。
1 編寫的所有需求，其詳細(xì)程度是否一致和合適？
2 需求是否能為設(shè)計(jì)提供足夠的基礎(chǔ)？
3 所有對(duì)其他需求的內(nèi)部引用是否正確？
4 是否包含了每個(gè)需求的實(shí)現(xiàn)優(yōu)先級(jí)？
5 是否定義了功能說明的內(nèi)在算法？
6 是否包含了所有已知的客戶需求或系統(tǒng)需求？
7 是否遺漏了必要的信息？如果有遺漏的話，把他們標(biāo)記為待確定的問題（TBD）？
8 是否對(duì)所有預(yù)期的錯(cuò)誤條件所產(chǎn)生的系統(tǒng)行為都編制了文檔？
需求說明的完整性主要體現(xiàn)在需求說明的詳細(xì)程度上，我們?cè)鯓优袛嘣撔枨蟮拿枋鍪欠裨敿?xì)呢？我認(rèn)為需求需要精化，而不是僅僅提出精化功能、對(duì)象要考慮涉眾參與者、做些什么、需要什么數(shù)據(jù)信息、受什么業(yè)務(wù)規(guī)則和條件限制、系統(tǒng)會(huì)有什么響應(yīng)，等等。
四、 注意對(duì)需求方案的可行性和成本預(yù)算進(jìn)行評(píng)審
考試大－全國大教育類網(wǎng)站(www．Examda。com)
需求方案的可行性和成本預(yù)算也是需求評(píng)審中的兩個(gè)重要方面。需求方案的可行性和成本預(yù)算評(píng)審的目的，是從需求的多項(xiàng)方案中選擇優(yōu)化的或者是性價(jià)比高的方案。一般而言，需求說明書可以給出同一個(gè)問題的幾種方案，并給出各自的優(yōu)缺點(diǎn)和成本差異，經(jīng)過比較由決策者作出終選擇。當(dāng)我們理解了需求說明，我們下一步需要對(duì)其分析是否有可行性。如果可行性高，則還要考慮它需要哪些資源和預(yù)算。我們需要確定技術(shù)是否確實(shí)滿足業(yè)務(wù)需求，同時(shí)， 也要考慮整個(gè)產(chǎn)品成本，包括開發(fā)人員、服務(wù)器、許可和升級(jí)費(fèi)用，還需要考慮初始硬件、軟件和支持、基礎(chǔ)結(jié)構(gòu)和培訓(xùn)的費(fèi)用。
五、 注意對(duì)需求的質(zhì)量屬性進(jìn)行評(píng)審
我們需要評(píng)審需求規(guī)格說明是否合理地確定了所有的性能目標(biāo)，是否合理地確定了安全性方面要考慮到的問題。系統(tǒng)性能需求之所以在概念階段即被要求，是因?yàn)楝F(xiàn)實(shí)的教訓(xùn)。君不見很多功能已經(jīng)完善的系統(tǒng)因?yàn)樾阅苌喜贿_(dá)標(biāo)，而被用戶束之高閣——用戶通常難以忍受運(yùn)行或響應(yīng)速度過慢的系統(tǒng)。
系統(tǒng)的安全性也是一個(gè)很重要的指標(biāo)，尤其是作為企業(yè)級(jí)的系統(tǒng)，它的安全考量完全繼承于組織對(duì)安全的基本訴求 。除了功能權(quán)限、字段級(jí)別權(quán)限外，數(shù)據(jù)間的授權(quán)關(guān)系也是必須考慮的，這本身也是一種業(yè)務(wù)規(guī)則。在“商機(jī)管理系統(tǒng)”需求分析中，“業(yè)務(wù)員A不能夠查看業(yè)務(wù)員B下達(dá)的訂單或相關(guān)信息”。所以，諸如此類的安全性需求在需求規(guī)格說明中是否被完整的描述，也是需求評(píng)審過程的一個(gè)硬性指標(biāo)?？偟恼f來，安全性包含了身份驗(yàn)證、訪問控制、加密和審核等考慮事項(xiàng)。
六、 注意對(duì)需求的可實(shí)施性進(jìn)行評(píng)審
是否對(duì)每個(gè)需求都設(shè)置了惟一性并且可以正確地識(shí)別它？是否每個(gè)功能需求都可以跟蹤到高層需求（比如系統(tǒng)需求或用例）？
需求必須可以測(cè)試，每個(gè)需求在特定的輸入條件下應(yīng)當(dāng)能給出已知的輸出結(jié)果。同時(shí)，需求應(yīng)當(dāng)層次分明，需要把單個(gè)需求下面的相關(guān)需求綜合在一起形成一組需求功能。
需求的可實(shí)施性除了可跟蹤性還包括可測(cè)試性。事實(shí)上， 分析人員和測(cè)試人員在編寫代碼以前把需求模型，分析模型和測(cè)試用例綜合起來通盤考慮，檢查出遺漏的、錯(cuò)誤的和不必要的需求。軟件需求在概念上的測(cè)試是一種很必要的技術(shù)，它可以在項(xiàng)目早期階段發(fā)現(xiàn)需求的歧義和錯(cuò)誤。
七、 注意對(duì)需求包含的用例文檔進(jìn)行評(píng)審
用例是參與者對(duì)系統(tǒng)和參與者的交互過程所達(dá)成的一種契約。需求說明書基于用例的分析方法是也是當(dāng)前較為流行的需求開發(fā)方式。用例文檔作為需求重要的成果性文檔也是需求評(píng)審主體之所在。需求評(píng)審確認(rèn)的重點(diǎn)是對(duì)關(guān)鍵用戶的常用和重要的用例進(jìn)行深入和細(xì)致的評(píng)審，首先要通過測(cè)試用例的主干過程。
八、 注意需求評(píng)審會(huì)的過程和結(jié)束標(biāo)準(zhǔn)
通常，需求評(píng)審會(huì)都不是件容易的事情，業(yè)務(wù)審查人員分散在各個(gè)地域和時(shí)間上的不一致性是困難產(chǎn)生的所在。在很多情況下，我們可以使用分布式需求評(píng)審軟件從網(wǎng)絡(luò)上對(duì)需求文檔進(jìn)行預(yù)先評(píng)審，而在評(píng)審會(huì)中則要注意不要使評(píng)審會(huì)演變成了“業(yè)務(wù)會(huì)”或“技術(shù)研討會(huì)”。同時(shí)，需求評(píng)審會(huì)的結(jié)果是對(duì)需求規(guī)格書完成了評(píng)審過程，那我們又如何判斷審查的結(jié)束標(biāo)準(zhǔn)呢？請(qǐng)看如下幾條建議：
1、審查期間評(píng)審員們提出的所有問題都已經(jīng)解決。
2、相關(guān)文檔中的所有更改都已經(jīng)正確完成。
3、修訂過的文檔進(jìn)行了拼寫檢查。
4、所有標(biāo)識(shí)為TBD（待確定）的問題已經(jīng)全部解決， 或者已經(jīng)對(duì)每個(gè)TBD的問題的解決過程、計(jì)劃解決的目標(biāo)日期和責(zé)任解決人等編制了文檔。
5、需求文檔正式進(jìn)入了配置庫。