模板
教程
環境
性能
功能
管理
軟件需求設計評審之八項注意
1931年，中共中央代表歐陽欽在向黨中央報告說明中央蘇區情況時，具體地說明了紅一方面軍的“三大紀律八項注意”, 此后三大紀律八項正式成為了全軍和地方武裝的紀律。本文所討論的“八項注意”是對于軟件需求設計評審工作的一些情況的說明。 現在讓我們把目光
現在讓我們把目光聚焦到軟件需求設計評審上來, 我們已經知道如何去獲取需求,也知道了撰寫需求規格說明書?，F在的問題是,我們所撰寫的需求規格說明書是否能讓用戶接受呢? 而用戶又如何對需求說明書作出理性和客觀的評審和確認呢? 事實上，當我們撰寫需求規格說明書的時候不妨站在用戶的角度去評寫，唯其如此方能事先避免一些問題。本文探討用戶應該如何去“評審”軟件需求說明書，并因此提出了需求評審的”八項注意”，以饗同仁。
需求確認是需求開發過程的第四個階段,前三個階段按順序分別為需求獲取、需求分析、編寫需求規格說明。需求確認活動要力圖確保如下幾點:
１需求規格說明正確描述了預期的、滿足各方涉眾需求的系統能力和特征。
２所述之軟件需求是由系統需求、業務規格和其他來源中正確推導而來的。
３需求是完整和高質量的。
４需求的表示在所有地方都是一致的。
５需求為產品設計和構造提供了基礎。
需求確認活動可以確保需求符合優秀需求陳述的特征，包括完整、正確、可行、必要、具有優先級、無二義性和可驗證, 同時亦符合好的需求規格說明的特征，即完整性、一致性、易修改和可跟蹤性。
一般而言，我們通過需求評審活動去實現需求確認的目標, 參與評審者應包括各級客戶、開發人員和測試人員, 在整個審查過程中，我們會有諸多“注意”。事實上,在實踐活動中,每個企業會根據自身的情況存在更多的檢查事項, 在此列出的八項亦屬于最基本的要素。
一、 注意對需求規格說明的正確性進行評審
需求規格說明的正確性通?？梢詮娜缦路矫娴靡泽w現：
1 是否有需求與其他需求相互沖突或者重復？
通常一份長達幾百頁的需求規格說明書都不會是一蹴而就的，它可能是系統分析師幾個夜晚的心血之作。正是因為撰寫過程的連續性，可能導致同一份文檔中前后名詞定義不一致，前后觀點上有重疊或差異的情況出現，這需要我們在撰寫報告前首先要在思想上形成統一概念, 可使術語列表貫穿整份文檔以達提綱挈領之效。
談及此點,讓我想起在“商機管理系統”需求評審會上，火眼金睛的用戶們發現了我的需求說明書中關于系統用戶角色定義部分出現了前后不一致的情況。在該報告前文中我定義了該系統有二種角色，即“商機成員”、“商機管理成員”,但在功能需求中我的報告中居然新生出一種“商機監理”角色，導致出現尷尬局面。 事后總結其主要原因是在撰寫報告的前期和后期階段,需求分析的思路有了明顯的異動，但卻沒有把文檔前后更新一致，這個教訓是深刻的，時至今日記憶猶新。
2 是否清晰、簡潔、無二義地表達了每個需求?
“清晰”是讓人能夠讀懂；“簡潔”是讓人愿意去讀；“無二義”決定”讀”的效果,是讓大家對需求描述的理解能夠達成一致 。
需求陳述是“三重門”,這三扇門是否開啟決定了需求說明書的質量高低。
我們尤其要拒絕“二義性”的名詞術語的出現, 似是而非的概念定義是需求書應該避免的。換句話說,如果一份需求說明書沒能給人以清晰、簡潔和無二義的闡述，則需求評審是沒有進行下去的必要，同時也無法進行下去。需求評審的前提是用戶讀懂了需求說明,并且用戶的理解內容就是分析師們所描述的內容。
3 是否每個需求都通過了演示、測試、評審，分析是否得到了驗證?
需求應該是可以測試的,通常通過測試去驗證它是不是正確。比如我們完成了“銷售員客戶傭金提成規則”需求的撰寫,如果需求書未能經過原型測試通過,則需求評審是不能得到通過的。 面對相當復雜的業務需求,經過測試或演示是讓用戶信任的一個必要過程。試想一下, 如果連需求都不能很好地被確認，則開發實現階段更是沒有把握控制了。
4 是否每個需求都在項目的范圍內?
劃分項目范圍和區分系統邊界同樣是需求說明書的一個任務，不要對需求書作出超范圍的論述和延伸，要知道需求書不是分析師賣弄概念、展示時尚的場所，它是軟件工程的一個重要環節。
5 是否每個需求都沒有內容和語法上的錯誤?
按照傳統的需求列表方式，需求像菜單一樣被一條條列出來，構成需求項的主要欄位包括：需求ID、 需求描述、優先級、來源和狀態等。 通常需求首先要經過“拼寫檢查”，保證沒有拼寫上的問題，然后通過逐行瀏覽修改那些在內容或行文上出現問題的需求。
6 在現有的資源內, 是否能實現所有的需求?
需求規格說明要考慮可行性的問題。事實上，分析師的關注層面是價值驅動和成本驅動方面。分析師應該明白不是所有的需求都要去實現，一些看上去很明顯與涉及用戶有沖突的、費力不討好的需求應該果斷地舍棄。國內有專家提出，搞需求也要講“和諧”即是此中道理。
舉例而言，企業中的用戶可分為三種類型：決策層用戶、管理層用戶、操作層用戶。每種用戶所代表的價值取向是不同的，決策和管理層希望系統處理業務是業務安全優先的，而操作系統用戶則是更多地考慮方便性的。國內某電子貿易公司，從自身業務安全考慮，規定了系統不允許“借貨”,意即代理商的產品直接發到客戶根本不經過本貿易公司的物流部門。如果操作層用戶提出了這樣的“借貨”需求,倒是可以方便他的日常處理,但卻違背了公司的根本利益。很顯然，這樣的需求肯定是有所不為的。
7 每一條特定的錯誤信息，是否都是唯一的和具有含義的?
不要忽視錯誤信息的定義, 它必須具有唯一性。如果過于籠統地定義錯誤信息則和沒有定義的效果是一樣的。
二、 注意對需求規格說明的實踐性進行評審
所謂實踐性是指需求本身是否來源于目前企業的相關業務規則和文件制度,而非源于分析師們經驗主義的臆測。實踐性是判斷需求規格說明是不是理論聯系實踐、密切和用戶聯系的一個關鍵性指標。如果需求規格說明和用戶實踐脫離,即使看上去寫得再天花亂墜,也會使需求說明如同無根之樹、無源之水,會大大減低用戶對需求報告本身的信任度。
有經驗的系統分析師通常會迷信自己的經驗,把從前的經驗嫁接到目前的企業需求分析中。也許由于行業性質相同,但如果不經過當前的實踐調研則給出需求，仍然會無法體現出企業自身的特征。因而不能為企業帶來真正的價值,也會造成與用戶需求的鴻溝。
筆者也曾經“輕實踐重抽象”，我認為系統分析師的工作特點是站在具體案例上的深度抽象，前提是必須獲得本企業的一手具體業務背景、流程和規則。
我們在分析比如“任務跟蹤”之類的系統時，由于系統的抽象模型是已知的(通過大量同類軟件的分析得知)，但還是需要分析師把抽象模型演繹到企業當前業務現狀。這樣的需求分析才會有“實話實說”之效,才能引發評審者的共鳴。否則，在需求評審中評審者是很難讀懂你的意圖，自然不會立即通過你的需求報告，導致需要重新返工撰寫需求報告。
這使我想到毛主席當年倡導“理論聯系實際”的深刻內涵。任何時刻,我們都要記住一個原則，即密切聯系用戶。誠然，需求分析需要方法也要理論支持,但最關鍵點仍然在于它本身是一種實踐,需求分析實踐直接來源于和用戶的直接溝通和互動。
所謂實踐性是指需求本身是否來源于目前企業的相關業務規則和文件制度,而非源于分析師們經驗主義的臆測。實踐性是判斷需求規格說明是不是理論聯系實踐、密切和用戶聯系的一個關鍵性指標。如果需求規格說明和用戶實踐脫離,即使看上去寫得再天花亂墜,也會使需求說明如同無根之樹、無源之水,會大大減低用戶對需求報告本身的信任度。
有經驗的系統分析師通常會迷信自己的經驗,把從前的經驗嫁接到目前的企業需求分析中。也許由于行業性質相同,但如果不經過當前的實踐調研則給出需求，仍然會無法體現出企業自身的特征。因而不能為企業帶來真正的價值,也會造成與用戶需求的鴻溝。
筆者也曾經“輕實踐重抽象”，我認為系統分析師的工作特點是站在具體案例上的深度抽象，前提是必須獲得本企業的一手具體業務背景、流程和規則。
我們在分析比如“任務跟蹤”之類的系統時，由于系統的抽象模型是已知的(通過大量同類軟件的分析得知)，但還是需要分析師把抽象模型演繹到企業當前業務現狀。這樣的需求分析才會有“實話實說”之效,才能引發評審者的共鳴。否則，在需求評審中評審者是很難讀懂你的意圖，自然不會立即通過你的需求報告，導致需要重新返工撰寫需求報告。
這使我想到毛主席當年倡導“理論聯系實際”的深刻內涵。任何時刻,我們都要記住一個原則，即密切聯系用戶。誠然，需求分析需要方法也要理論支持,但最關鍵點仍然在于它本身是一種實踐,需求分析實踐直接來源于和用戶的直接溝通和互動。
三、 注意對需求規格說明的完整性進行評審
我們經常由下面的問題清單來評審需求說明書是否”完整” 。
1 編寫的所有需求，其詳細程度是否一致和合適?
2 需求是否能為設計提供足夠的基礎?
3 所有對其他需求的內部引用是否正確?
4 是否包含了每個需求的實現優先級?
5 是否定義了功能說明的內在算法?
6 是否包含了所有已知的客戶需求或系統需求?
7 是否遺漏了必要的信息?如果有遺漏的話,把他們標記為待確定的問題(TBD) ?
8 是否對所有預期的錯誤條件所產生的系統行為都編制了文檔?
需求說明的完整性主要體現在需求說明的詳細程度上，我們怎樣判斷該需求的描述是否詳細呢?我認為需求需要精化，而不是僅僅提出精化功能、對象要考慮涉眾參與者、做些什么、需要什么數據信息、受什么業務規則和條件限制、系統會有什么響應，等等。
讓我們看一個功能需求例子,“FR1: 銷售出貨要考慮到信用額度”。
乍看顯得過于簡單和含糊,我們把它修改成”FR1: 1 銷售出貨的前提是該客戶擁有超過出貨價值的信用額度, 否則,系統提示‘該客戶信用額度不足,不予出貨!’ 2 正式出貨后系統將扣減其信用額度” 。
很顯然,修改后的需求把出貨和信用額度的來由去向和系統的具體反應都說明清楚了。
當然傳統的需求描述也能夠與用例中的參與者和系統響應等內容映射的。
我們經常由下面的問題清單來評審需求說明書是否”完整” 。
1 編寫的所有需求，其詳細程度是否一致和合適?
2 需求是否能為設計提供足夠的基礎?
3 所有對其他需求的內部引用是否正確?
4 是否包含了每個需求的實現優先級?
5 是否定義了功能說明的內在算法?
6 是否包含了所有已知的客戶需求或系統需求?
7 是否遺漏了必要的信息?如果有遺漏的話,把他們標記為待確定的問題(TBD) ?
8 是否對所有預期的錯誤條件所產生的系統行為都編制了文檔?
需求說明的完整性主要體現在需求說明的詳細程度上，我們怎樣判斷該需求的描述是否詳細呢?我認為需求需要精化，而不是僅僅提出精化功能、對象要考慮涉眾參與者、做些什么、需要什么數據信息、受什么業務規則和條件限制、系統會有什么響應，等等。
讓我們看一個功能需求例子,“FR1: 銷售出貨要考慮到信用額度”。
乍看顯得過于簡單和含糊,我們把它修改成”FR1: 1 銷售出貨的前提是該客戶擁有超過出貨價值的信用額度, 否則,系統提示‘該客戶信用額度不足,不予出貨!’ 2 正式出貨后系統將扣減其信用額度” 。
很顯然,修改后的需求把出貨和信用額度的來由去向和系統的具體反應都說明清楚了。
當然傳統的需求描述也能夠與用例中的參與者和系統響應等內容映射的。
四、 注意對需求方案的可行性和成本預算進行評審
需求方案的可行性和成本預算也是需求評審中的兩個重要方面。
需求方案的可行性和成本預算評審的目的，是從需求的多項方案中選擇最優化的或者是性價比最高的方案。一般而言,需求說明書可以給出同一個問題的幾種方案，并給出各自的優缺點和成本差異,經過比較由決策者作出最終選擇。
當我們理解了需求說明,我們下一步需要對其分析是否有可行性。
如果可行性高,則還要考慮它需要哪些資源和預算。我們需要確定技術是否確實滿足業務需求,同時, 也要考慮整個產品成本,包括開發人員、服務器、許可和升級費用,還需要考慮初始硬件、軟件和支持、基礎結構和培訓的費用。
五、 注意對需求的質量屬性進行評審
我們需要評審需求規格說明是否合理地確定了所有的性能目標，是否合理地確定了安全性方面要考慮到的問題。
系統性能需求之所以在概念階段即被要求,是因為現實的教訓。君不見很多功能已經完善的系統因為性能上不達標,而被用戶束之高閣——用戶通常難以忍受運行或響應速度過慢的系統。
系統的安全性也是一個很重要的指標,尤其是作為企業級的系統,它的安全考量完全繼承于組織對安全的基本訴求 。除了功能權限、字段級別權限外,數據間的授權關系也是必須考慮的,這本身也是一種業務規則。在”商機管理系統”需求分析中,“業務員A不能夠查看業務員B下達的訂單或相關信息”。所以,諸如此類的安全性需求在需求規格說明中是否被完整的描述，也是需求評審過程的一個硬性指標?？偟恼f來,安全性包含了身份驗證、訪問控制、加密和審核等考慮事項。
需求方案的可行性和成本預算也是需求評審中的兩個重要方面。
需求方案的可行性和成本預算評審的目的，是從需求的多項方案中選擇最優化的或者是性價比最高的方案。一般而言,需求說明書可以給出同一個問題的幾種方案，并給出各自的優缺點和成本差異,經過比較由決策者作出最終選擇。
當我們理解了需求說明,我們下一步需要對其分析是否有可行性。
如果可行性高,則還要考慮它需要哪些資源和預算。我們需要確定技術是否確實滿足業務需求,同時, 也要考慮整個產品成本,包括開發人員、服務器、許可和升級費用,還需要考慮初始硬件、軟件和支持、基礎結構和培訓的費用。
五、 注意對需求的質量屬性進行評審
我們需要評審需求規格說明是否合理地確定了所有的性能目標，是否合理地確定了安全性方面要考慮到的問題。
系統性能需求之所以在概念階段即被要求,是因為現實的教訓。君不見很多功能已經完善的系統因為性能上不達標,而被用戶束之高閣——用戶通常難以忍受運行或響應速度過慢的系統。
系統的安全性也是一個很重要的指標,尤其是作為企業級的系統,它的安全考量完全繼承于組織對安全的基本訴求 。除了功能權限、字段級別權限外,數據間的授權關系也是必須考慮的,這本身也是一種業務規則。在”商機管理系統”需求分析中,“業務員A不能夠查看業務員B下達的訂單或相關信息”。所以,諸如此類的安全性需求在需求規格說明中是否被完整的描述，也是需求評審過程的一個硬性指標?？偟恼f來,安全性包含了身份驗證、訪問控制、加密和審核等考慮事項。
六、 注意對需求的可實施性進行評審
是否對每個需求都設置了惟一性并且可以正確地識別它？是否每個功能需求都可以跟蹤到高層需求（比如系統需求或用例）?
需求必須可以測試,每個需求在特定的輸入條件下應當能給出已知的輸出結果。同時,需求應當層次分明,需要把單個需求下面的相關需求綜合在一起形成一組需求功能。
需求的可實施性除了可跟蹤性還包括可測試性。事實上, 分析人員和測試人員在編寫代碼以前把需求模型,分析模型和測試用例綜合起來通盤考慮，檢查出遺漏的、錯誤的和不必要的需求。軟件需求在概念上的測試是一種很必要的技術，它可以在項目早期階段發現需求的歧義和錯誤。
正如Ross Collard所言：“用例和測試用例以兩種方式協同作, 如果系統用例是完整的,準確而清晰的。那么測試用例的衍生過程就簡明易懂。如果系統用例條理不清,那么要從中測試出來測試用例這一做法本身也將會幫助我們排除用例中的錯誤” 。
七、 注意對需求包含的用例文檔進行評審
用例是參與者對系統和參與者的交互過程所達成的一種契約。需求說明書基于用例的分析方法是也是當前較為流行的需求開發方式。用例文檔作為需求重要的成果性文檔也是需求評審主體之所在。需求評審確認的重點是對關鍵用戶的最常用和最重要的用例進行深入和細致的評審,首先要通過測試用例的主干過程。而我們是否撰寫有效的用例則要從以下方面著手評審。
1 用例的目標或價值度量是否明確?
這一點是考察用例的編寫是從用戶角度還是從系統角度出發的。必須保證用例從用戶角度出發,用例才有正確的目標。也就是說用例實際上是把用戶作為參與者，以第一人稱“我”與系統做種種交互的過程。而其中對過程的描述要讓用戶看上去很熟悉,如果用戶看上去是如此的陌生，則說明你和用戶的溝通還沒能達成“契約”。
2 用例是否是獨立的分散任務?
3 是否明確說明可用用例會給哪些參與者帶來用處?
不要以為用例能給所有的涉眾者帶來用戶,它只對當前的參與者和相關參與者帶來價值,這就是用例的范圍。事實上，分析師應該清楚所有涉眾者對系統和用例的主要價值態度及其約束條件。
4 編寫用例的詳細程度是否恰當?是否有不必要的設計和實現細節?
用例不應該有任何的設計細節,更不能出現UI設計。 我們要確保參與者是以黑盒子看系統的,這樣化繁為簡的思路,正是系統分析分層次目的所在。
5 所有預期的分支過程是否都編寫了文檔說明?
參與者的動作和系統的響應構成用例過程的主題,所以必須是盡可能的客觀和詳細的。
6 所有預估的異常過程是否都編寫了文檔說明?
參與者異常過程將轉化成設計的異常處理機制,所以是必不可少的,我們絕對不敢使用沒有任何異常處理的應用程序的。
7 是否存在一些普通的動作序列可以分解成獨立的用例?
用例之間也有可復用的,能夠把公共的動作序列獨立出來，用例達到可復用的目標也是用例撰寫要考慮的。
8 每個路徑的步驟是否都清晰明了,無歧義而且完整?
用例中的主干過程、分支過程、異常處理的每個步驟都建議使用主動結構來陳述,即參與者要干什么、系統要響應什么,一步一步地描述直到完成整個用例流程。這個用例通常會是參與者完成了一個業務或任務流程。
9 用例中的每個參與者和步驟是否都與所執行的任務有關?
要防止用例目標和用例描述出現了文不對題或牛頭馬面的現象。
10 用例中定義的每個可選路徑是否都可行和可驗證?
用例描述與用例圖的每個動作序列保持一致，是可以經過驗證和系統執行通過的。
11用例的前置條件和后置條件是否合理?
分析師必須確認用例的前置條件和后置條件準確界定了用例的邊界范圍,區分了用例和用例之間的界限。
分析師經常會發現在檢查一個包含九個步驟的用例時,發現執行完第六個步驟就滿足了后置條件,第七、八、九在用例的邊界之外,很顯然是不必要的。同樣,用例的前置條件必須是啟動在第一個步驟就已經滿足。
六、 注意對需求的可實施性進行評審
是否對每個需求都設置了惟一性并且可以正確地識別它？是否每個功能需求都可以跟蹤到高層需求（比如系統需求或用例）?
需求必須可以測試,每個需求在特定的輸入條件下應當能給出已知的輸出結果。同時,需求應當層次分明,需要把單個需求下面的相關需求綜合在一起形成一組需求功能。
需求的可實施性除了可跟蹤性還包括可測試性。事實上, 分析人員和測試人員在編寫代碼以前把需求模型,分析模型和測試用例綜合起來通盤考慮，檢查出遺漏的、錯誤的和不必要的需求。軟件需求在概念上的測試是一種很必要的技術，它可以在項目早期階段發現需求的歧義和錯誤。
正如Ross Collard所言：“用例和測試用例以兩種方式協同作, 如果系統用例是完整的,準確而清晰的。那么測試用例的衍生過程就簡明易懂。如果系統用例條理不清,那么要從中測試出來測試用例這一做法本身也將會幫助我們排除用例中的錯誤” 。
七、 注意對需求包含的用例文檔進行評審
用例是參與者對系統和參與者的交互過程所達成的一種契約。需求說明書基于用例的分析方法是也是當前較為流行的需求開發方式。用例文檔作為需求重要的成果性文檔也是需求評審主體之所在。需求評審確認的重點是對關鍵用戶的最常用和最重要的用例進行深入和細致的評審,首先要通過測試用例的主干過程。而我們是否撰寫有效的用例則要從以下方面著手評審。
1 用例的目標或價值度量是否明確?
這一點是考察用例的編寫是從用戶角度還是從系統角度出發的。必須保證用例從用戶角度出發,用例才有正確的目標。也就是說用例實際上是把用戶作為參與者，以第一人稱“我”與系統做種種交互的過程。而其中對過程的描述要讓用戶看上去很熟悉,如果用戶看上去是如此的陌生，則說明你和用戶的溝通還沒能達成“契約”。
2 用例是否是獨立的分散任務?
3 是否明確說明可用用例會給哪些參與者帶來用處?
不要以為用例能給所有的涉眾者帶來用戶,它只對當前的參與者和相關參與者帶來價值,這就是用例的范圍。事實上，分析師應該清楚所有涉眾者對系統和用例的主要價值態度及其約束條件。
4 編寫用例的詳細程度是否恰當?是否有不必要的設計和實現細節?
用例不應該有任何的設計細節,更不能出現UI設計。 我們要確保參與者是以黑盒子看系統的,這樣化繁為簡的思路,正是系統分析分層次目的所在。
5 所有預期的分支過程是否都編寫了文檔說明?
參與者的動作和系統的響應構成用例過程的主題,所以必須是盡可能的客觀和詳細的。
6 所有預估的異常過程是否都編寫了文檔說明?
參與者異常過程將轉化成設計的異常處理機制,所以是必不可少的,我們絕對不敢使用沒有任何異常處理的應用程序的。
7 是否存在一些普通的動作序列可以分解成獨立的用例?
用例之間也有可復用的,能夠把公共的動作序列獨立出來，用例達到可復用的目標也是用例撰寫要考慮的。
8 每個路徑的步驟是否都清晰明了,無歧義而且完整?
用例中的主干過程、分支過程、異常處理的每個步驟都建議使用主動結構來陳述,即參與者要干什么、系統要響應什么,一步一步地描述直到完成整個用例流程。這個用例通常會是參與者完成了一個業務或任務流程。
9 用例中的每個參與者和步驟是否都與所執行的任務有關?
要防止用例目標和用例描述出現了文不對題或牛頭馬面的現象。
10 用例中定義的每個可選路徑是否都可行和可驗證?
用例描述與用例圖的每個動作序列保持一致，是可以經過驗證和系統執行通過的。
11用例的前置條件和后置條件是否合理?
分析師必須確認用例的前置條件和后置條件準確界定了用例的邊界范圍,區分了用例和用例之間的界限。
分析師經常會發現在檢查一個包含九個步驟的用例時,發現執行完第六個步驟就滿足了后置條件,第七、八、九在用例的邊界之外,很顯然是不必要的。同樣,用例的前置條件必須是啟動在第一個步驟就已經滿足。
六、 注意對需求的可實施性進行評審
是否對每個需求都設置了惟一性并且可以正確地識別它？是否每個功能需求都可以跟蹤到高層需求（比如系統需求或用例）?
需求必須可以測試,每個需求在特定的輸入條件下應當能給出已知的輸出結果。同時,需求應當層次分明,需要把單個需求下面的相關需求綜合在一起形成一組需求功能。
需求的可實施性除了可跟蹤性還包括可測試性。事實上, 分析人員和測試人員在編寫代碼以前把需求模型,分析模型和測試用例綜合起來通盤考慮，檢查出遺漏的、錯誤的和不必要的需求。軟件需求在概念上的測試是一種很必要的技術，它可以在項目早期階段發現需求的歧義和錯誤。
正如Ross Collard所言：“用例和測試用例以兩種方式協同作, 如果系統用例是完整的,準確而清晰的。那么測試用例的衍生過程就簡明易懂。如果系統用例條理不清,那么要從中測試出來測試用例這一做法本身也將會幫助我們排除用例中的錯誤” 。
七、 注意對需求包含的用例文檔進行評審
用例是參與者對系統和參與者的交互過程所達成的一種契約。需求說明書基于用例的分析方法是也是當前較為流行的需求開發方式。用例文檔作為需求重要的成果性文檔也是需求評審主體之所在。需求評審確認的重點是對關鍵用戶的最常用和最重要的用例進行深入和細致的評審,首先要通過測試用例的主干過程。而我們是否撰寫有效的用例則要從以下方面著手評審。
1 用例的目標或價值度量是否明確?
這一點是考察用例的編寫是從用戶角度還是從系統角度出發的。必須保證用例從用戶角度出發,用例才有正確的目標。也就是說用例實際上是把用戶作為參與者，以第一人稱“我”與系統做種種交互的過程。而其中對過程的描述要讓用戶看上去很熟悉,如果用戶看上去是如此的陌生，則說明你和用戶的溝通還沒能達成“契約”。
2 用例是否是獨立的分散任務?
3 是否明確說明可用用例會給哪些參與者帶來用處?
不要以為用例能給所有的涉眾者帶來用戶,它只對當前的參與者和相關參與者帶來價值,這就是用例的范圍。事實上，分析師應該清楚所有涉眾者對系統和用例的主要價值態度及其約束條件。
4 編寫用例的詳細程度是否恰當?是否有不必要的設計和實現細節?
用例不應該有任何的設計細節,更不能出現UI設計。 我們要確保參與者是以黑盒子看系統的,這樣化繁為簡的思路,正是系統分析分層次目的所在。
5 所有預期的分支過程是否都編寫了文檔說明?
參與者的動作和系統的響應構成用例過程的主題,所以必須是盡可能的客觀和詳細的。
6 所有預估的異常過程是否都編寫了文檔說明?
參與者異常過程將轉化成設計的異常處理機制,所以是必不可少的,我們絕對不敢使用沒有任何異常處理的應用程序的。
7 是否存在一些普通的動作序列可以分解成獨立的用例?
用例之間也有可復用的,能夠把公共的動作序列獨立出來，用例達到可復用的目標也是用例撰寫要考慮的。
8 每個路徑的步驟是否都清晰明了,無歧義而且完整?
用例中的主干過程、分支過程、異常處理的每個步驟都建議使用主動結構來陳述,即參與者要干什么、系統要響應什么,一步一步地描述直到完成整個用例流程。這個用例通常會是參與者完成了一個業務或任務流程。
9 用例中的每個參與者和步驟是否都與所執行的任務有關?
要防止用例目標和用例描述出現了文不對題或牛頭馬面的現象。
10 用例中定義的每個可選路徑是否都可行和可驗證?
用例描述與用例圖的每個動作序列保持一致，是可以經過驗證和系統執行通過的。
11用例的前置條件和后置條件是否合理?
分析師必須確認用例的前置條件和后置條件準確界定了用例的邊界范圍,區分了用例和用例之間的界限。
分析師經常會發現在檢查一個包含九個步驟的用例時,發現執行完第六個步驟就滿足了后置條件,第七、八、九在用例的邊界之外,很顯然是不必要的。同樣,用例的前置條件必須是啟動在第一個步驟就已經滿足。
八、 注意需求評審會的過程和結束標準
通常，需求評審會都不是件容易的事情,業務審查人員分散在各個地域和時間上的不一致性是困難產生的所在。在很多情況下,我們可以使用分布式需求評審軟件從網絡上對需求文檔進行預先評審,而在評審會中則要注意不要使評審會演變成了“業務會”或“技術研討會”。
同時,需求評審會的結果是對需求規格書完成了評審過程,那我們又如何判斷審查的結束標準呢?請看如下幾條建議:
1 審查期間評審員們提出的所有問題都已經解決。
2 相關文檔中的所有更改都已經正確完成。
3 修訂過的文檔進行了拼寫檢查。
4 所有標識為TBD(待確定)的問題已經全部解決, 或者已經對每個TBD的問題的解決過程、計劃解決的目標日期和責任解決人等編制了文檔。
5 需求文檔正式進入了配置庫。
本文闡述了需求評審和確認的一些”注意”事項，一旦完成需求評審將表示進入了需求設計階段，欲知需求設計如何實現，且聽下文為您分解。
是否對每個需求都設置了惟一性并且可以正確地識別它？是否每個功能需求都可以跟蹤到高層需求（比如系統需求或用例）?
需求必須可以測試,每個需求在特定的輸入條件下應當能給出已知的輸出結果。同時,需求應當層次分明,需要把單個需求下面的相關需求綜合在一起形成一組需求功能。
需求的可實施性除了可跟蹤性還包括可測試性。事實上, 分析人員和測試人員在編寫代碼以前把需求模型,分析模型和測試用例綜合起來通盤考慮，檢查出遺漏的、錯誤的和不必要的需求。軟件需求在概念上的測試是一種很必要的技術，它可以在項目早期階段發現需求的歧義和錯誤。
正如Ross Collard所言：“用例和測試用例以兩種方式協同作, 如果系統用例是完整的,準確而清晰的。那么測試用例的衍生過程就簡明易懂。如果系統用例條理不清,那么要從中測試出來測試用例這一做法本身也將會幫助我們排除用例中的錯誤” 。
七、 注意對需求包含的用例文檔進行評審
用例是參與者對系統和參與者的交互過程所達成的一種契約。需求說明書基于用例的分析方法是也是當前較為流行的需求開發方式。用例文檔作為需求重要的成果性文檔也是需求評審主體之所在。需求評審確認的重點是對關鍵用戶的最常用和最重要的用例進行深入和細致的評審,首先要通過測試用例的主干過程。而我們是否撰寫有效的用例則要從以下方面著手評審。
1 用例的目標或價值度量是否明確?
這一點是考察用例的編寫是從用戶角度還是從系統角度出發的。必須保證用例從用戶角度出發,用例才有正確的目標。也就是說用例實際上是把用戶作為參與者，以第一人稱“我”與系統做種種交互的過程。而其中對過程的描述要讓用戶看上去很熟悉,如果用戶看上去是如此的陌生，則說明你和用戶的溝通還沒能達成“契約”。
2 用例是否是獨立的分散任務?
3 是否明確說明可用用例會給哪些參與者帶來用處?
不要以為用例能給所有的涉眾者帶來用戶,它只對當前的參與者和相關參與者帶來價值,這就是用例的范圍。事實上，分析師應該清楚所有涉眾者對系統和用例的主要價值態度及其約束條件。
4 編寫用例的詳細程度是否恰當?是否有不必要的設計和實現細節?
用例不應該有任何的設計細節,更不能出現UI設計。 我們要確保參與者是以黑盒子看系統的,這樣化繁為簡的思路,正是系統分析分層次目的所在。
5 所有預期的分支過程是否都編寫了文檔說明?
參與者的動作和系統的響應構成用例過程的主題,所以必須是盡可能的客觀和詳細的。
6 所有預估的異常過程是否都編寫了文檔說明?
參與者異常過程將轉化成設計的異常處理機制,所以是必不可少的,我們絕對不敢使用沒有任何異常處理的應用程序的。
7 是否存在一些普通的動作序列可以分解成獨立的用例?
用例之間也有可復用的,能夠把公共的動作序列獨立出來，用例達到可復用的目標也是用例撰寫要考慮的。
8 每個路徑的步驟是否都清晰明了,無歧義而且完整?
用例中的主干過程、分支過程、異常處理的每個步驟都建議使用主動結構來陳述,即參與者要干什么、系統要響應什么,一步一步地描述直到完成整個用例流程。這個用例通常會是參與者完成了一個業務或任務流程。
9 用例中的每個參與者和步驟是否都與所執行的任務有關?
要防止用例目標和用例描述出現了文不對題或牛頭馬面的現象。
10 用例中定義的每個可選路徑是否都可行和可驗證?
用例描述與用例圖的每個動作序列保持一致，是可以經過驗證和系統執行通過的。
11用例的前置條件和后置條件是否合理?
分析師必須確認用例的前置條件和后置條件準確界定了用例的邊界范圍,區分了用例和用例之間的界限。
分析師經常會發現在檢查一個包含九個步驟的用例時,發現執行完第六個步驟就滿足了后置條件,第七、八、九在用例的邊界之外,很顯然是不必要的。同樣,用例的前置條件必須是啟動在第一個步驟就已經滿足。
六、 注意對需求的可實施性進行評審
是否對每個需求都設置了惟一性并且可以正確地識別它？是否每個功能需求都可以跟蹤到高層需求（比如系統需求或用例）?
需求必須可以測試,每個需求在特定的輸入條件下應當能給出已知的輸出結果。同時,需求應當層次分明,需要把單個需求下面的相關需求綜合在一起形成一組需求功能。
需求的可實施性除了可跟蹤性還包括可測試性。事實上, 分析人員和測試人員在編寫代碼以前把需求模型,分析模型和測試用例綜合起來通盤考慮，檢查出遺漏的、錯誤的和不必要的需求。軟件需求在概念上的測試是一種很必要的技術，它可以在項目早期階段發現需求的歧義和錯誤。
正如Ross Collard所言：“用例和測試用例以兩種方式協同作, 如果系統用例是完整的,準確而清晰的。那么測試用例的衍生過程就簡明易懂。如果系統用例條理不清,那么要從中測試出來測試用例這一做法本身也將會幫助我們排除用例中的錯誤” 。
七、 注意對需求包含的用例文檔進行評審
用例是參與者對系統和參與者的交互過程所達成的一種契約。需求說明書基于用例的分析方法是也是當前較為流行的需求開發方式。用例文檔作為需求重要的成果性文檔也是需求評審主體之所在。需求評審確認的重點是對關鍵用戶的最常用和最重要的用例進行深入和細致的評審,首先要通過測試用例的主干過程。而我們是否撰寫有效的用例則要從以下方面著手評審。
1 用例的目標或價值度量是否明確?
這一點是考察用例的編寫是從用戶角度還是從系統角度出發的。必須保證用例從用戶角度出發,用例才有正確的目標。也就是說用例實際上是把用戶作為參與者，以第一人稱“我”與系統做種種交互的過程。而其中對過程的描述要讓用戶看上去很熟悉,如果用戶看上去是如此的陌生，則說明你和用戶的溝通還沒能達成“契約”。
2 用例是否是獨立的分散任務?
3 是否明確說明可用用例會給哪些參與者帶來用處?
不要以為用例能給所有的涉眾者帶來用戶,它只對當前的參與者和相關參與者帶來價值,這就是用例的范圍。事實上，分析師應該清楚所有涉眾者對系統和用例的主要價值態度及其約束條件。
4 編寫用例的詳細程度是否恰當?是否有不必要的設計和實現細節?
用例不應該有任何的設計細節,更不能出現UI設計。 我們要確保參與者是以黑盒子看系統的,這樣化繁為簡的思路,正是系統分析分層次目的所在。
5 所有預期的分支過程是否都編寫了文檔說明?
參與者的動作和系統的響應構成用例過程的主題,所以必須是盡可能的客觀和詳細的。
6 所有預估的異常過程是否都編寫了文檔說明?
參與者異常過程將轉化成設計的異常處理機制,所以是必不可少的,我們絕對不敢使用沒有任何異常處理的應用程序的。
7 是否存在一些普通的動作序列可以分解成獨立的用例?
用例之間也有可復用的,能夠把公共的動作序列獨立出來，用例達到可復用的目標也是用例撰寫要考慮的。
8 每個路徑的步驟是否都清晰明了,無歧義而且完整?
用例中的主干過程、分支過程、異常處理的每個步驟都建議使用主動結構來陳述,即參與者要干什么、系統要響應什么,一步一步地描述直到完成整個用例流程。這個用例通常會是參與者完成了一個業務或任務流程。
9 用例中的每個參與者和步驟是否都與所執行的任務有關?
要防止用例目標和用例描述出現了文不對題或牛頭馬面的現象。
10 用例中定義的每個可選路徑是否都可行和可驗證?
用例描述與用例圖的每個動作序列保持一致，是可以經過驗證和系統執行通過的。
11用例的前置條件和后置條件是否合理?
分析師必須確認用例的前置條件和后置條件準確界定了用例的邊界范圍,區分了用例和用例之間的界限。
分析師經常會發現在檢查一個包含九個步驟的用例時,發現執行完第六個步驟就滿足了后置條件,第七、八、九在用例的邊界之外,很顯然是不必要的。同樣,用例的前置條件必須是啟動在第一個步驟就已經滿足。
六、 注意對需求的可實施性進行評審
是否對每個需求都設置了惟一性并且可以正確地識別它？是否每個功能需求都可以跟蹤到高層需求（比如系統需求或用例）?
需求必須可以測試,每個需求在特定的輸入條件下應當能給出已知的輸出結果。同時,需求應當層次分明,需要把單個需求下面的相關需求綜合在一起形成一組需求功能。
需求的可實施性除了可跟蹤性還包括可測試性。事實上, 分析人員和測試人員在編寫代碼以前把需求模型,分析模型和測試用例綜合起來通盤考慮，檢查出遺漏的、錯誤的和不必要的需求。軟件需求在概念上的測試是一種很必要的技術，它可以在項目早期階段發現需求的歧義和錯誤。
正如Ross Collard所言：“用例和測試用例以兩種方式協同作, 如果系統用例是完整的,準確而清晰的。那么測試用例的衍生過程就簡明易懂。如果系統用例條理不清,那么要從中測試出來測試用例這一做法本身也將會幫助我們排除用例中的錯誤” 。
七、 注意對需求包含的用例文檔進行評審
用例是參與者對系統和參與者的交互過程所達成的一種契約。需求說明書基于用例的分析方法是也是當前較為流行的需求開發方式。用例文檔作為需求重要的成果性文檔也是需求評審主體之所在。需求評審確認的重點是對關鍵用戶的最常用和最重要的用例進行深入和細致的評審,首先要通過測試用例的主干過程。而我們是否撰寫有效的用例則要從以下方面著手評審。
1 用例的目標或價值度量是否明確?
這一點是考察用例的編寫是從用戶角度還是從系統角度出發的。必須保證用例從用戶角度出發,用例才有正確的目標。也就是說用例實際上是把用戶作為參與者，以第一人稱“我”與系統做種種交互的過程。而其中對過程的描述要讓用戶看上去很熟悉,如果用戶看上去是如此的陌生，則說明你和用戶的溝通還沒能達成“契約”。
2 用例是否是獨立的分散任務?
3 是否明確說明可用用例會給哪些參與者帶來用處?
不要以為用例能給所有的涉眾者帶來用戶,它只對當前的參與者和相關參與者帶來價值,這就是用例的范圍。事實上，分析師應該清楚所有涉眾者對系統和用例的主要價值態度及其約束條件。
4 編寫用例的詳細程度是否恰當?是否有不必要的設計和實現細節?
用例不應該有任何的設計細節,更不能出現UI設計。 我們要確保參與者是以黑盒子看系統的,這樣化繁為簡的思路,正是系統分析分層次目的所在。
5 所有預期的分支過程是否都編寫了文檔說明?
參與者的動作和系統的響應構成用例過程的主題,所以必須是盡可能的客觀和詳細的。
6 所有預估的異常過程是否都編寫了文檔說明?
參與者異常過程將轉化成設計的異常處理機制,所以是必不可少的,我們絕對不敢使用沒有任何異常處理的應用程序的。
7 是否存在一些普通的動作序列可以分解成獨立的用例?
用例之間也有可復用的,能夠把公共的動作序列獨立出來，用例達到可復用的目標也是用例撰寫要考慮的。
8 每個路徑的步驟是否都清晰明了,無歧義而且完整?
用例中的主干過程、分支過程、異常處理的每個步驟都建議使用主動結構來陳述,即參與者要干什么、系統要響應什么,一步一步地描述直到完成整個用例流程。這個用例通常會是參與者完成了一個業務或任務流程。
9 用例中的每個參與者和步驟是否都與所執行的任務有關?
要防止用例目標和用例描述出現了文不對題或牛頭馬面的現象。
10 用例中定義的每個可選路徑是否都可行和可驗證?
用例描述與用例圖的每個動作序列保持一致，是可以經過驗證和系統執行通過的。
11用例的前置條件和后置條件是否合理?
分析師必須確認用例的前置條件和后置條件準確界定了用例的邊界范圍,區分了用例和用例之間的界限。
分析師經常會發現在檢查一個包含九個步驟的用例時,發現執行完第六個步驟就滿足了后置條件,第七、八、九在用例的邊界之外,很顯然是不必要的。同樣,用例的前置條件必須是啟動在第一個步驟就已經滿足。
八、 注意需求評審會的過程和結束標準
通常，需求評審會都不是件容易的事情,業務審查人員分散在各個地域和時間上的不一致性是困難產生的所在。在很多情況下,我們可以使用分布式需求評審軟件從網絡上對需求文檔進行預先評審,而在評審會中則要注意不要使評審會演變成了“業務會”或“技術研討會”。
同時,需求評審會的結果是對需求規格書完成了評審過程,那我們又如何判斷審查的結束標準呢?請看如下幾條建議:
1 審查期間評審員們提出的所有問題都已經解決。
2 相關文檔中的所有更改都已經正確完成。
3 修訂過的文檔進行了拼寫檢查。
4 所有標識為TBD(待確定)的問題已經全部解決, 或者已經對每個TBD的問題的解決過程、計劃解決的目標日期和責任解決人等編制了文檔。
5 需求文檔正式進入了配置庫。
本文闡述了需求評審和確認的一些”注意”事項，一旦完成需求評審將表示進入了需求設計階段，欲知需求設計如何實現，且聽下文為您分解。
