2·8把握需求評審的關(guān)鍵點(diǎn)
(1)注意對軟件需求說明書的正確性進(jìn)行評審。需求規(guī)格說明的正確性通?？梢詮娜缦路矫娴靡泽w現(xiàn):
?、偈欠裼行枨笈c其他需求相互沖突或者重復(fù)?
②是否清晰、簡潔、無二義地表達(dá)了每個需求(“清晰”是讓人能夠讀懂;“簡潔”是讓人愿意去讀;“無二義”決定“讀”的效果,是讓大家對需求描述的理解能夠達(dá)成一致)?
?、凼欠衩總€需求都通過了演示、測試、評審,分析是否得到了驗(yàn)證?
?、苁欠衩總€需求都在項(xiàng)目的范圍內(nèi)?
⑤是否每個需求都沒有內(nèi)容和語法上的錯誤?
?、拊诂F(xiàn)有的資源內(nèi),是否能實(shí)現(xiàn)所有的需求?
⑦每一條特定的錯誤信息,是否都是唯一的和具有含義的?
(2)注意對軟件需求說明書的實(shí)踐性進(jìn)行評審。所謂實(shí)踐性是指需求本身是否來源于目前企業(yè)的相關(guān)業(yè)務(wù)規(guī)則和文件制度,而非源于分析師們經(jīng)驗(yàn)主義的臆測。實(shí)踐性是判斷需求規(guī)格說明是不是理論聯(lián)系實(shí)踐、密切和用戶聯(lián)系的一個關(guān)鍵性指標(biāo)。
(3)注意對需求規(guī)格說明書的完整性進(jìn)行評審?？捎上旅娴膯栴}清單來評審需求說明書是否“完整”:
①編寫的所有需求,其詳細(xì)程度是否一致和合適?
?、谛枨笫欠衲転樵O(shè)計(jì)提供足夠的基礎(chǔ)?
?、鬯袑ζ渌枨蟮膬?nèi)部引用是否正確?
?、苁欠癜嗣總€需求的實(shí)現(xiàn)優(yōu)先級?
?、菔欠穸x了功能說明的內(nèi)在算法?
⑥是否包含了所有已知的客戶需求或系統(tǒng)需求?
?、呤欠襁z漏了必要的信息?⑧是否對所有預(yù)期的錯誤條件所產(chǎn)生的系統(tǒng)行為都編制了文檔?
需求說明的完整性主要體現(xiàn)在需求說明的詳細(xì)程度上,怎樣判斷該需求的描述是否詳細(xì)呢?筆者認(rèn)為需求需要精化,而不是僅僅提出精化功能、對象要考慮涉眾參與者、做些什么、需要什么數(shù)據(jù)信息、受什么業(yè)務(wù)規(guī)則和條件限制、系統(tǒng)會有什么響應(yīng)等。
(4)注意對需求方案的可行性和成本預(yù)算進(jìn)行評審。
(5)注意對需求的質(zhì)量屬性進(jìn)行評審。評審需求規(guī)格需要說明是否合理地確定了所有的性能目標(biāo),是否合理地確定了安全性方面要考慮到的問題。
(6)注意對需求的可實(shí)施性進(jìn)行評審:
?、偈欠駥γ總€需求都設(shè)置了唯一性并且可以正確地識別它?
?、谑欠衩總€功能需求都可以跟蹤到高層需求?
需求必須可以測試,每個需求在特定的輸入條件下應(yīng)當(dāng)能給出已知的輸出結(jié)果,同時,需求應(yīng)當(dāng)層次分明,需要把單個需求下面的相關(guān)需求綜合在一起形成一組需求功能。需求的可實(shí)施性除了可跟蹤性還包括可測試性,事實(shí)上,分析人員和測試人員在編寫代碼以前把需求模型,分析模型和測試用例綜合起來通盤考慮,檢查出遺漏的、錯誤的和不必要的需求,軟件需求在概念上的測試是一種很必要的技術(shù),它可以在項(xiàng)目早期階段發(fā)現(xiàn)需求的歧義和錯誤。
(7)注意對需求包含的用例文檔進(jìn)行評審。用例是參與者對系統(tǒng)和參與者的交互過程所達(dá)成的一種契約。需求說明書基于用例的分析方法是也是當(dāng)前較為流行的需求開發(fā)方式。用例文檔作為需求重要的成果性文檔也是需求評審主體之所在。
需求評審確認(rèn)的重點(diǎn)是對關(guān)鍵用戶的最常用和最重要的用例進(jìn)行深入和細(xì)致的評審,首先要通過測試用例的主干過程。而是否撰寫有效的用例則要從以下方面著手評審:用例的目標(biāo)或價值度量是否明確?用例是否是獨(dú)立的分散任務(wù)?
是否明確說明可用用例會給哪些參與者帶來用處?編寫用例的詳細(xì)程度是否恰當(dāng)?是否有不必要的設(shè)計(jì)和實(shí)現(xiàn)細(xì)節(jié)?所有預(yù)期的分支過程是否都編寫了文檔說明?所有預(yù)估的異常過程是否都編寫了文檔說明?是否存在一些普通的動