已知的（通過大量同類軟件的分析得知），但還是需要分析師把抽象模型演繹到企業(yè)當前業(yè)務現(xiàn)狀。這樣的需求分析才會有“實話實說”之效，才能引發(fā)評審者的共鳴。否則，在需求評審中評審者是很難讀懂你的意圖，自然不會立即通過你的需求報告，導致需要重新返工撰寫需求報告。
三、 注意對需求規(guī)格說明的完整性進行評審
　　我們經(jīng)常由下面的問題清單來評審需求說明書是否“完整”。
1 編寫的所有需求，其詳細程度是否一致和合適？
2 需求是否能為設(shè)計提供足夠的基礎(chǔ)？
3 所有對其他需求的內(nèi)部引用是否正確？
4 是否包含了每個需求的實現(xiàn)優(yōu)先級？
5 是否定義了功能說明的內(nèi)在算法？
6 是否包含了所有已知的客戶需求或系統(tǒng)需求？
7 是否遺漏了必要的信息？如果有遺漏的話，把他們標記為待確定的問題（TBD）？
8 是否對所有預期的錯誤條件所產(chǎn)生的系統(tǒng)行為都編制了文檔？
　　需求說明的完整性主要體現(xiàn)在需求說明的詳細程度上，我們怎樣判斷該需求的描述是否詳細呢？我認為需求需要精化，而不是僅僅提出精化功能、對象要考慮涉眾參與者、做些什么、需要什么數(shù)據(jù)信息、受什么業(yè)務規(guī)則和條件限制、系統(tǒng)會有什么響應，等等。
四、 注意對需求方案的可行性和成本預算進行評審
　　需求方案的可行性和成本預算也是需求評審中的兩個重要方面。需求方案的可行性和成本預算評審的目的，是從需求的多項方案中選擇最優(yōu)化的或者是性價比最高的方案。一般而言，需求說明書可以給出同一個問題的幾種方案，并給出各自的優(yōu)缺點和成本差異，經(jīng)過比較由決策者作出最終選擇。當我們理解了需求說明，我們下一步需要對其分析是否有可行性。如果可行性高，則還要考慮它需要哪些資源和預算。我們需要確定技術(shù)是否確實滿足業(yè)務需求，同時， 也要考慮整個產(chǎn)品成本，包括開發(fā)人員、服務器、許可和升級費用，還需要考慮初始硬件、軟件和支持、基礎(chǔ)結(jié)構(gòu)和培訓的費用。
五、 注意對需求的質(zhì)量屬性進行評審
　　我們需要評審需求規(guī)格說明是否合理地確定了所有的性能目標，是否合理地確定了安全性方面要考慮到的問題。系統(tǒng)性能需求之所以在概念階段即被要求，是因為現(xiàn)實的教訓。君不見很多功能已經(jīng)完善的系統(tǒng)因為性能上不達標，而被用戶束之高閣——用戶通常難以忍受運行或響應速度過慢的系統(tǒng)。
　　系統(tǒng)的安全性也是一個很重要的指標，尤其是作為企業(yè)級的系統(tǒng)，它的安全考量完全繼承于組織對安全的基本訴求 。除了功能權(quán)限、字段級別權(quán)限外，數(shù)據(jù)間的授權(quán)關(guān)系也是必須考慮的，這本身也是一種業(yè)務規(guī)則。在“商機管理系統(tǒng)”需求分析中，“業(yè)務員A不能夠查看業(yè)務員B下達的訂單或相關(guān)信息”。所以，諸如此類的安全性需求在需求規(guī)格說明中是否被完整的描述，也是需求評審過程的一個硬性指標?？偟恼f來，安全性包含了身份驗證、訪問控制、加密和審核等考慮事項。
六、 注意對需求的可實施性進行評審
　　是否對每個需求都設(shè)置了惟一性并且可以正確地識別它？是否每個功能需求都可以跟蹤到高層需求（比如系統(tǒng)需求或用例）？
　　需求必須可以測試，每個需求在特定的輸入條件下應當能給出已知的輸出結(jié)果。同時，需求應當層次分明，需要把單個需求下面的相關(guān)需求綜合在一起形成一組需求功能。
　　需求的可實施性除了可跟蹤性還包括可測試性。事實上， 分析人員和測試人員在編寫代碼以前把需求模型，分析模型和測試用例綜合起來通盤考慮，檢查出遺漏的、錯誤的和不必要的需求。軟件需求在概念上的測試是一種很必要的技術(shù)，它可以在項目早期階段發(fā)現(xiàn)需求的歧義和錯誤。
七、 注意對需求包含的用例文檔進行評審
　　用例是參與者對系統(tǒng)和參與者的交互過程所達成的一種契約。需求說明書基于用例的分析方法是也是當前較為流行的需求開發(fā)方式。用例文檔作為需

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

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