軟件需求工程第二部分軟件需求開發(fā)課件

軟件需求工程

SoftwareRequirementsEngineering

(SRE)

第二部分

軟件需求開發(fā)

第十七章

超越需求開發(fā)王如龍2022/12/2軟件需求工程

SoftwareRequirements學(xué)習(xí)目標在學(xué)完本章內(nèi)容之后，你應(yīng)該能夠：

了解做好從需求到項目規(guī)劃轉(zhuǎn)換的意義與方法；分析從需求到設(shè)計、編碼、測試的關(guān)系與區(qū)別；掌握從需求到設(shè)計、編碼、測試的過程控制原則與方法。

2/25學(xué)習(xí)目標在學(xué)完本章內(nèi)容之后，你應(yīng)該能夠：2/2517.0做好需求轉(zhuǎn)化的意義和作用一個軟件開發(fā)項目最終可發(fā)行的是滿足客戶需求和期望的軟件系統(tǒng)。需求是從產(chǎn)品概念通向用戶滿意之路的最本質(zhì)的一步。把軟件需求轉(zhuǎn)化為健壯的設(shè)計和合理的項目規(guī)劃是項目成功的基本保證。

3/2517.0做好需求轉(zhuǎn)化的意義和作用一個軟件開發(fā)項目最終可發(fā)17.0做好需求轉(zhuǎn)化的意義和作用

軟件開發(fā)人員與客戶、用戶對需求的理解不同、對系統(tǒng)的要求不同、甚至由于利益關(guān)系的不同，將影響轉(zhuǎn)化工作的順利進行。需求分析人員與軟件設(shè)計和編碼人員在對系統(tǒng)的理解角度、認識水平、掌握的技術(shù)，甚至在年齡、工作經(jīng)歷、和所處地位的差別，將影響轉(zhuǎn)化工作的順利進行。

4/2517.0做好需求轉(zhuǎn)化的意義和作用軟件開發(fā)人員與客戶、用17.0做好需求轉(zhuǎn)化的意義和作用基線需求項目計劃設(shè)計和代碼測試根據(jù)需求確定項目的規(guī)模根據(jù)產(chǎn)品規(guī)模進行評估當需求改變時更新計劃使用需求優(yōu)先級驅(qū)動迭代讓開發(fā)人員評審需求根據(jù)質(zhì)量屬性決定體系結(jié)構(gòu)設(shè)計將需求分配給各組件跟蹤需求到設(shè)計和代碼盡早開始測試設(shè)計用需求驅(qū)動系統(tǒng)測試讓用戶開發(fā)驗收測試跟蹤需求到測試圖17-1需求推動項目規(guī)劃、設(shè)計、編碼和測試活動P209

5/2517.0做好需求轉(zhuǎn)化的意義和作用基線項目計劃設(shè)計和代碼測17.1從需求到項目規(guī)劃由于需求定義了項目預(yù)期的成果，所以項目規(guī)劃、預(yù)測和進度安排都必須以軟件需求為基礎(chǔ)。但是，請大家牢記，最重要的項目成果是交付滿足業(yè)務(wù)目標的系統(tǒng)，而不一定是根據(jù)最初的項目規(guī)劃實現(xiàn)所有初始需求的系統(tǒng)。P210

6/2517.1從需求到項目規(guī)劃由于需求定義了項目預(yù)期的成果，所17.1從需求到項目規(guī)劃項目團隊到底應(yīng)該在需求工程中投入多少時間和精力，是一個必須解決的問題。對小型項目而言，團隊在需求工程上所發(fā)費的故障量應(yīng)該占項目的12％～15％。相當多的證據(jù)表明，花一些時間理解需求實際上可以加速項目的開發(fā)進度。P210

7/2517.1從需求到項目規(guī)劃項目團隊到底應(yīng)該在需求工程中投入17.1從需求到項目規(guī)劃歐洲的一份研究表明，產(chǎn)品開發(fā)較快的團隊，與產(chǎn)品開發(fā)較慢的團隊相比，在需求階段所投入的時間和工作量更多一些。P210投入的工作量投入的時間開發(fā)較快的項目14％17％開發(fā)較慢的項目7％9％表17-1對需求工作的投入可以加速項目的開發(fā)

8/2517.1從需求到項目規(guī)劃歐洲的一份研究表明，產(chǎn)品開發(fā)較快17.1從需求到項目規(guī)劃需求和預(yù)估

可以根據(jù)文本需求、分析模型、原型或用戶界面來估計軟件產(chǎn)品的規(guī)模；雖然軟件的規(guī)模沒有規(guī)定的度量標準，但可以采用如下一些方法來進行度量：需求的數(shù)量；功能點和特性點的數(shù)量；圖形用戶界面（GUI）元素的數(shù)量、類型和復(fù)雜度；用于實現(xiàn)特定需求所需的源代碼行數(shù)；對象類的數(shù)量或其他面向?qū)ο笙到y(tǒng)的衡量標準。P211

9/2517.1從需求到項目規(guī)劃可以根據(jù)文本需求、分析模型、原17.1從需求到項目規(guī)劃需求和進度安排

許多軟件工程實行“從右到左的進度安排”，這種方式常常不能按時完成項目。在做出詳細的規(guī)劃和約定之前定義軟件需求是更現(xiàn)實的。進度范圍成本需求進度范圍成本需求圖17-2兩種不同的進度安排P212

10/2517.1從需求到項目規(guī)劃許多軟件工程實行“從右到左的進17.1從需求到項目規(guī)劃需求和進度安排對于復(fù)雜的系統(tǒng)，軟件僅是最終產(chǎn)品的一部分時，只有在系統(tǒng)需求（產(chǎn)品級需求）產(chǎn)生以后，才能建立高層的進度安排。將系統(tǒng)需求分解并分配到各個不同的軟硬件子系統(tǒng)中，有利于進度的安排和執(zhí)行。必須根據(jù)市場需求、銷售計劃、客戶服務(wù)要求以及產(chǎn)品開發(fā)計劃等的為基礎(chǔ)建立起一致的產(chǎn)品發(fā)行日期。P213

11/2517.1從需求到項目規(guī)劃對于復(fù)雜的系統(tǒng)，軟件僅是最終產(chǎn)17.1從需求到項目規(guī)劃需求和進度安排正確的項目規(guī)劃需要以下元素：根據(jù)對需求的清楚理解來估計產(chǎn)品規(guī)模的大??；根據(jù)歷史記錄了解開發(fā)小組的工作效率；需要一張綜合的任務(wù)列表，以便完整地實現(xiàn)和驗證每一特性或用例；相當穩(wěn)定的需求；項目團隊的經(jīng)驗。P213

12/2517.1從需求到項目規(guī)劃正確的項目規(guī)劃需要以下元素：17.2從需求到設(shè)計和編碼

需求和設(shè)計之間存在差別，需求開發(fā)和規(guī)格說明應(yīng)該強調(diào)對預(yù)期系統(tǒng)外部行為的理解和描述。必須讓設(shè)計者和開發(fā)者參與需求審查以判斷需求是否可以作為設(shè)計的基礎(chǔ)。直接從需求規(guī)格說明跳到編碼階段，其可能的結(jié)果只能是結(jié)構(gòu)性很差的一個軟件。在構(gòu)造軟件之前，應(yīng)該仔細考慮構(gòu)造系統(tǒng)的最有效的方法。P213

13/2517.2從需求到設(shè)計和編碼需求和設(shè)計之間存在差別，需求17.2從需求到設(shè)計和編碼分析模型代表了用戶和開發(fā)小組對正在解決的問題的理解，而設(shè)計模型則描繪了應(yīng)該如何構(gòu)造系統(tǒng)。如果在需求分析之后立刻進行編碼，那么必定會出現(xiàn)代碼重復(fù)。而且設(shè)計上的返工比編碼返工可能要效率高一些。以需求為基礎(chǔ)，反復(fù)設(shè)計將產(chǎn)生優(yōu)良成果，用不同的方法進行設(shè)計可以精細化最初的概念。P213

14/2517.2從需求到設(shè)計和編碼分析模型代表了用戶和開發(fā)小組17.2從需求到設(shè)計和編碼在開始實現(xiàn)產(chǎn)品之前，雖然不需要為整個產(chǎn)品開發(fā)完整的、詳細的設(shè)計，但是，應(yīng)該先對每一個組件進行設(shè)計，然后再對其進行編碼。

當項目難度很大、涉及的接口和交付復(fù)雜、開發(fā)人員經(jīng)驗不足時，最能體現(xiàn)設(shè)計規(guī)劃的好處。P215

15/2517.2從需求到設(shè)計和編碼在開始實現(xiàn)產(chǎn)品之前，雖然不需要17.2從需求到設(shè)計和編碼如下的建議對所有的項目類型都有益：

為子系統(tǒng)和組件開發(fā)一個堅固的體系結(jié)構(gòu)，這一體系結(jié)構(gòu)在產(chǎn)品改進的過程中可以保持不變；明確需要創(chuàng)建的對象類或功能模塊，定義他們的接口、職責(zé)以及與其他單元的協(xié)作；對并行處理系統(tǒng)，要理解計劃執(zhí)行的線程或?qū)Σl(fā)進程的功能分配；根據(jù)強內(nèi)聚、松耦合和信息隱藏的設(shè)計原則，定義每個代碼單元的預(yù)期功能；確保設(shè)計滿足所有的功能需求，但不包括不必要的功能；確保設(shè)計能適應(yīng)可能出現(xiàn)的異常條件；確保設(shè)計能達到所陳述的性能、健壯性、可靠性和其他一些質(zhì)量屬性的目標。P215

16/2517.2從需求到設(shè)計和編碼如下的建議對所有的項目類型都有17.3從需求到測試測試和需求工程是一種相互促進的關(guān)系，好的需求工程可以生存更好的測試，好的測試分析可以生存更好的需求。需求是系統(tǒng)測試的基礎(chǔ)，對產(chǎn)品的測試應(yīng)該根據(jù)需求文檔中所記錄的產(chǎn)品的預(yù)期行為來進行，而不應(yīng)該根據(jù)設(shè)計或編碼來測試。產(chǎn)品可以正確地展示基于代碼的測試用例所描述的所有行為，但這并不意味著產(chǎn)品正確地實現(xiàn)了用戶或功能性需求。應(yīng)該讓測試人員參與需求審查，這樣可以確保需求是可以驗證的并可以作為系統(tǒng)測試的基礎(chǔ)。P216

17/2517.3從需求到測試測試和需求工程是一種相互促進的關(guān)系，17.3從需求到測試當每個需求都穩(wěn)定之后，系統(tǒng)測試人員應(yīng)該編寫以測試用例為主的《測試計劃》，通過測試、審查，演示或分析來驗證需求。根據(jù)需求中的邏輯描述，利用諸如因果圖等分析技術(shù)來獲得測試用例，這將會揭示需求的二義性、遺漏或隱含的其它條件和其它問題。每個需求應(yīng)至少由一個測試用例來測試。有經(jīng)驗的測試人員可以根據(jù)他們對產(chǎn)品的預(yù)期功能、用法、質(zhì)量特性和特有行為的理解，概括出純粹基于需求的測試。P216

18/2517.3從需求到測試當每個需求都穩(wěn)定之后，系統(tǒng)測試人員17.3從需求到測試

基于SRS的測試適用于許多測試設(shè)計策略如動作驅(qū)動、數(shù)據(jù)驅(qū)動、邏輯驅(qū)動、事件驅(qū)動和狀態(tài)驅(qū)動等。從正式的SRS中很容易自動生成測試用例，但是對于更多的由自然語言描述的SRS，必須手工開發(fā)測試用例。比起結(jié)構(gòu)化分析圖，對象模型更易于自動生成測試用例。P216

19/2517.3從需求到測試基于SRS的測試適用于許多測試設(shè)計17.3從需求到測試在開發(fā)的進展過程中，通過詳細的軟件功能需求仔細推敲來自使用實例的需求，并最終轉(zhuǎn)化成單個代碼模塊的規(guī)格說明。針對需求的測試必須在軟件結(jié)構(gòu)的每一層進行，而不只是在用戶層進行。即使有些模塊功能在整個軟件產(chǎn)品中對用戶都不可見，但是每個模塊功能必須滿足其自身的需求或規(guī)格說明要求。因此，針對用戶需求來測試系統(tǒng)是系統(tǒng)測試的必要但非充分條件。P217

20/2517.3從需求到測試在開發(fā)的進展過程中，通過詳細的軟件17.3從需求到成功如果不以高質(zhì)量的需求作為項目規(guī)劃、軟件設(shè)計和系統(tǒng)測試的基礎(chǔ)，那么在試圖開發(fā)優(yōu)秀產(chǎn)品的過程中將浪費大量的人力和物力。需求分析是項目成功的基礎(chǔ)，軟件開發(fā)的過程猶如蓋房子，如果地基沒有做好，那么房子蓋完之后的第一件事就是拆房子，而不是測試房子。所以需求到成功的關(guān)鍵是要通過規(guī)劃、軟設(shè)計和測試不斷確定需求的正確性。P217

21/2517.3從需求到成功如果不以高質(zhì)量的需求作為項目規(guī)劃、17.3從需求到成功正確把握需求開發(fā)的深度與廣度，避免陷入畸形分析的陷阱，是需求開發(fā)必須注意的另一面；必須理解到，客戶最關(guān)心的是結(jié)果，當需求開發(fā)組花費大量的時間創(chuàng)建不必要的文檔、舉行各種形式上的會議和評審，而并不解決任何實際問題時，會引起客戶甚至設(shè)計人員的困惑和不滿，最終導(dǎo)致項目被取消。努力在精確的規(guī)格說明與可將產(chǎn)品失敗的風(fēng)險降至可接受程度的編碼之間做出明智的選擇，是需求開發(fā)人員的必須掌握的基本功。P217

22/2517.3從需求到成功正確把握需求開發(fā)的深度與廣度，避免本章小結(jié)由于需求定義了項目預(yù)期的成果，所以項目規(guī)劃、預(yù)測和進度安排都必須以軟件需求為基礎(chǔ)。

軟件項目可能經(jīng)常不能達到預(yù)定的目標的主要原因不在技術(shù)上而在管理上。需求估算有多種方法，但都離不開經(jīng)驗的積累。需求和設(shè)計之間存在差別，需求開發(fā)和規(guī)格說明應(yīng)該強調(diào)對預(yù)期系統(tǒng)外部行為的理解和描述。必須讓設(shè)計者和開發(fā)者參與需求審查以判斷需求是否可以作為設(shè)計的基礎(chǔ)。必須針對SRS來測試整個軟件，而不是針對設(shè)計或編碼。把軟件需求轉(zhuǎn)化為健壯的設(shè)計和合理的項目規(guī)劃是項目成功的基本保證。

23/25本章小結(jié)由于需求定義了項目預(yù)期的成果，所以項目規(guī)劃、預(yù)測和第3次作業(yè)推薦讀物

24/25第3次作業(yè)24/25需求的開發(fā)是需求成功的基本保證。關(guān)注與開發(fā)非功能需求比功能需求更重要。需求的獲取、分析、編寫和驗證必須建立有效的過程和實用的模板。謝謝大家第二部分

軟件需求開發(fā)結(jié)束體會

25/25需求的開發(fā)是需求成功的基本保證。第二部分軟件需求開發(fā)結(jié)束軟件需求工程

SoftwareRequirementsEngineering

(SRE)

第二部分

軟件需求開發(fā)

第十七章

超越需求開發(fā)王如龍2022/12/2軟件需求工程

SoftwareRequirements學(xué)習(xí)目標在學(xué)完本章內(nèi)容之后，你應(yīng)該能夠：

了解做好從需求到項目規(guī)劃轉(zhuǎn)換的意義與方法；分析從需求到設(shè)計、編碼、測試的關(guān)系與區(qū)別；掌握從需求到設(shè)計、編碼、測試的過程控制原則與方法。

27/25學(xué)習(xí)目標在學(xué)完本章內(nèi)容之后，你應(yīng)該能夠：2/2517.0做好需求轉(zhuǎn)化的意義和作用一個軟件開發(fā)項目最終可發(fā)行的是滿足客戶需求和期望的軟件系統(tǒng)。需求是從產(chǎn)品概念通向用戶滿意之路的最本質(zhì)的一步。把軟件需求轉(zhuǎn)化為健壯的設(shè)計和合理的項目規(guī)劃是項目成功的基本保證。

28/2517.0做好需求轉(zhuǎn)化的意義和作用一個軟件開發(fā)項目最終可發(fā)17.0做好需求轉(zhuǎn)化的意義和作用

軟件開發(fā)人員與客戶、用戶對需求的理解不同、對系統(tǒng)的要求不同、甚至由于利益關(guān)系的不同，將影響轉(zhuǎn)化工作的順利進行。需求分析人員與軟件設(shè)計和編碼人員在對系統(tǒng)的理解角度、認識水平、掌握的技術(shù)，甚至在年齡、工作經(jīng)歷、和所處地位的差別，將影響轉(zhuǎn)化工作的順利進行。

29/2517.0做好需求轉(zhuǎn)化的意義和作用軟件開發(fā)人員與客戶、用17.0做好需求轉(zhuǎn)化的意義和作用基線需求項目計劃設(shè)計和代碼測試根據(jù)需求確定項目的規(guī)模根據(jù)產(chǎn)品規(guī)模進行評估當需求改變時更新計劃使用需求優(yōu)先級驅(qū)動迭代讓開發(fā)人員評審需求根據(jù)質(zhì)量屬性決定體系結(jié)構(gòu)設(shè)計將需求分配給各組件跟蹤需求到設(shè)計和代碼盡早開始測試設(shè)計用需求驅(qū)動系統(tǒng)測試讓用戶開發(fā)驗收測試跟蹤需求到測試圖17-1需求推動項目規(guī)劃、設(shè)計、編碼和測試活動P209

30/2517.0做好需求轉(zhuǎn)化的意義和作用基線項目計劃設(shè)計和代碼測17.1從需求到項目規(guī)劃由于需求定義了項目預(yù)期的成果，所以項目規(guī)劃、預(yù)測和進度安排都必須以軟件需求為基礎(chǔ)。但是，請大家牢記，最重要的項目成果是交付滿足業(yè)務(wù)目標的系統(tǒng)，而不一定是根據(jù)最初的項目規(guī)劃實現(xiàn)所有初始需求的系統(tǒng)。P210

31/2517.1從需求到項目規(guī)劃由于需求定義了項目預(yù)期的成果，所17.1從需求到項目規(guī)劃項目團隊到底應(yīng)該在需求工程中投入多少時間和精力，是一個必須解決的問題。對小型項目而言，團隊在需求工程上所發(fā)費的故障量應(yīng)該占項目的12％～15％。相當多的證據(jù)表明，花一些時間理解需求實際上可以加速項目的開發(fā)進度。P210

32/2517.1從需求到項目規(guī)劃項目團隊到底應(yīng)該在需求工程中投入17.1從需求到項目規(guī)劃歐洲的一份研究表明，產(chǎn)品開發(fā)較快的團隊，與產(chǎn)品開發(fā)較慢的團隊相比，在需求階段所投入的時間和工作量更多一些。P210投入的工作量投入的時間開發(fā)較快的項目14％17％開發(fā)較慢的項目7％9％表17-1對需求工作的投入可以加速項目的開發(fā)

33/2517.1從需求到項目規(guī)劃歐洲的一份研究表明，產(chǎn)品開發(fā)較快17.1從需求到項目規(guī)劃需求和預(yù)估

可以根據(jù)文本需求、分析模型、原型或用戶界面來估計軟件產(chǎn)品的規(guī)模；雖然軟件的規(guī)模沒有規(guī)定的度量標準，但可以采用如下一些方法來進行度量：需求的數(shù)量；功能點和特性點的數(shù)量；圖形用戶界面（GUI）元素的數(shù)量、類型和復(fù)雜度；用于實現(xiàn)特定需求所需的源代碼行數(shù)；對象類的數(shù)量或其他面向?qū)ο笙到y(tǒng)的衡量標準。P211

34/2517.1從需求到項目規(guī)劃可以根據(jù)文本需求、分析模型、原17.1從需求到項目規(guī)劃需求和進度安排

許多軟件工程實行“從右到左的進度安排”，這種方式常常不能按時完成項目。在做出詳細的規(guī)劃和約定之前定義軟件需求是更現(xiàn)實的。進度范圍成本需求進度范圍成本需求圖17-2兩種不同的進度安排P212

35/2517.1從需求到項目規(guī)劃許多軟件工程實行“從右到左的進17.1從需求到項目規(guī)劃需求和進度安排對于復(fù)雜的系統(tǒng)，軟件僅是最終產(chǎn)品的一部分時，只有在系統(tǒng)需求（產(chǎn)品級需求）產(chǎn)生以后，才能建立高層的進度安排。將系統(tǒng)需求分解并分配到各個不同的軟硬件子系統(tǒng)中，有利于進度的安排和執(zhí)行。必須根據(jù)市場需求、銷售計劃、客戶服務(wù)要求以及產(chǎn)品開發(fā)計劃等的為基礎(chǔ)建立起一致的產(chǎn)品發(fā)行日期。P213

36/2517.1從需求到項目規(guī)劃對于復(fù)雜的系統(tǒng)，軟件僅是最終產(chǎn)17.1從需求到項目規(guī)劃需求和進度安排正確的項目規(guī)劃需要以下元素：根據(jù)對需求的清楚理解來估計產(chǎn)品規(guī)模的大??；根據(jù)歷史記錄了解開發(fā)小組的工作效率；需要一張綜合的任務(wù)列表，以便完整地實現(xiàn)和驗證每一特性或用例；相當穩(wěn)定的需求；項目團隊的經(jīng)驗。P213

37/2517.1從需求到項目規(guī)劃正確的項目規(guī)劃需要以下元素：17.2從需求到設(shè)計和編碼

需求和設(shè)計之間存在差別，需求開發(fā)和規(guī)格說明應(yīng)該強調(diào)對預(yù)期系統(tǒng)外部行為的理解和描述。必須讓設(shè)計者和開發(fā)者參與需求審查以判斷需求是否可以作為設(shè)計的基礎(chǔ)。直接從需求規(guī)格說明跳到編碼階段，其可能的結(jié)果只能是結(jié)構(gòu)性很差的一個軟件。在構(gòu)造軟件之前，應(yīng)該仔細考慮構(gòu)造系統(tǒng)的最有效的方法。P213

38/2517.2從需求到設(shè)計和編碼需求和設(shè)計之間存在差別，需求17.2從需求到設(shè)計和編碼分析模型代表了用戶和開發(fā)小組對正在解決的問題的理解，而設(shè)計模型則描繪了應(yīng)該如何構(gòu)造系統(tǒng)。如果在需求分析之后立刻進行編碼，那么必定會出現(xiàn)代碼重復(fù)。而且設(shè)計上的返工比編碼返工可能要效率高一些。以需求為基礎(chǔ)，反復(fù)設(shè)計將產(chǎn)生優(yōu)良成果，用不同的方法進行設(shè)計可以精細化最初的概念。P213

39/2517.2從需求到設(shè)計和編碼分析模型代表了用戶和開發(fā)小組17.2從需求到設(shè)計和編碼在開始實現(xiàn)產(chǎn)品之前，雖然不需要為整個產(chǎn)品開發(fā)完整的、詳細的設(shè)計，但是，應(yīng)該先對每一個組件進行設(shè)計，然后再對其進行編碼。

當項目難度很大、涉及的接口和交付復(fù)雜、開發(fā)人員經(jīng)驗不足時，最能體現(xiàn)設(shè)計規(guī)劃的好處。P215

40/2517.2從需求到設(shè)計和編碼在開始實現(xiàn)產(chǎn)品之前，雖然不需要17.2從需求到設(shè)計和編碼如下的建議對所有的項目類型都有益：

為子系統(tǒng)和組件開發(fā)一個堅固的體系結(jié)構(gòu)，這一體系結(jié)構(gòu)在產(chǎn)品改進的過程中可以保持不變；明確需要創(chuàng)建的對象類或功能模塊，定義他們的接口、職責(zé)以及與其他單元的協(xié)作；對并行處理系統(tǒng)，要理解計劃執(zhí)行的線程或?qū)Σl(fā)進程的功能分配；根據(jù)強內(nèi)聚、松耦合和信息隱藏的設(shè)計原則，定義每個代碼單元的預(yù)期功能；確保設(shè)計滿足所有的功能需求，但不包括不必要的功能；確保設(shè)計能適應(yīng)可能出現(xiàn)的異常條件；確保設(shè)計能達到所陳述的性能、健壯性、可靠性和其他一些質(zhì)量屬性的目標。P215

41/2517.2從需求到設(shè)計和編碼如下的建議對所有的項目類型都有17.3從需求到測試測試和需求工程是一種相互促進的關(guān)系，好的需求工程可以生存更好的測試，好的測試分析可以生存更好的需求。需求是系統(tǒng)測試的基礎(chǔ)，對產(chǎn)品的測試應(yīng)該根據(jù)需求文檔中所記錄的產(chǎn)品的預(yù)期行為來進行，而不應(yīng)該根據(jù)設(shè)計或編碼來測試。產(chǎn)品可以正確地展示基于代碼的測試用例所描述的所有行為，但這并不意味著產(chǎn)品正確地實現(xiàn)了用戶或功能性需求。應(yīng)該讓測試人員參與需求審查，這樣可以確保需求是可以驗證的并可以作為系統(tǒng)測試的基礎(chǔ)。P216

42/2517.3從需求到測試測試和需求工程是一種相互促進的關(guān)系，17.3從需求到測試當每個需求都穩(wěn)定之后，系統(tǒng)測試人員應(yīng)該編寫以測試用例為主的《測試計劃》，通過測試、審查，演示或分析來驗證需求。根據(jù)需求中的邏輯描述，利用諸如因果圖等分析技術(shù)來獲得測試用例，這將會揭示需求的二義性、遺漏或隱含的其它條件和其它問題。每個需求應(yīng)至少由一個測試用例來測試。有經(jīng)驗的測試人員可以根據(jù)他們對產(chǎn)品的預(yù)期功能、用法、質(zhì)量特性和特有行為的理解，概括出純粹基于需求的測試。P216

43/2517.3從需求到測試當每個需求都穩(wěn)定之后，系統(tǒng)測試人員17.3從需求到測試

基于SRS的測試適用于許多測試設(shè)計策略如動作驅(qū)動、數(shù)據(jù)驅(qū)動、邏輯驅(qū)動、事件驅(qū)動和狀態(tài)驅(qū)動等。從正式的SRS中很容易自動生成測試用例，但是對于更多的由自然語言描述的SRS，必須手工開發(fā)測試用例。比起結(jié)構(gòu)化分析圖，對象模型更易于自動生成測試用例。P216

44/2517.3從需求到測試基于SRS的測試適用于許多測試設(shè)計17.3從需求到測試在開發(fā)的進展過程中，通過詳細的軟件功能需求仔細推敲來自使用實例的需求，并最終轉(zhuǎn)化成單個代碼模塊的規(guī)格說明。針對需求的測試必須在軟件結(jié)構(gòu)的每一層進行，而不只是在用戶層進行。即使有些模塊功能在整個軟件產(chǎn)品中對用戶都不可見，但是每個模塊功能必須滿足其自身的需求或規(guī)格說明要求。因此，針對用戶需求來測試系統(tǒng)是系統(tǒng)測試的必要但