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

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

    http://m.vanceur.cn/pmqhd/index.html