軟件需求工程 課件 第3章 需求獲取

第3章需求獲取

目錄確定需求開發(fā)計劃確定項目的目標和范圍確定調(diào)查對象實地收集需求信息3-13-23-33-4確定非功能需求3-5在收集需求信息中應(yīng)注意的問題3-6使用場景技術(shù)的需求獲取3-7軟件需求獲取軟件需求獲取(簡稱需求獲取)階段的任務(wù)簡單地說就是獲取用戶的需求信息。開發(fā)人員需要從用戶所提供的大量信息中分析和理解用戶真正的需求，需求獲取階段的活動可大致劃分為右圖所示的一系列工作。需求獲取3-1確定需求開發(fā)計劃基本任務(wù)需求工程的安排確定需求開發(fā)的實施步驟，并給出收集需求活動的具體安排和進度。重點：分析、理解和描述用戶的需求，著重于軟件系統(tǒng)“做什么”。需求工程是軟件開發(fā)過程中的一個階段，故其所占用的時間和費用有限，需要注意的是：只能考慮與需求開發(fā)相關(guān)的工作。安排進度時應(yīng)考慮困難性和靈活性。安排進度和時間時應(yīng)考慮書寫和整理需求規(guī)格說明及其文檔3-1確定需求開發(fā)計劃3-2確定項目的目標和范圍確定項目范圍的益處基本任務(wù)可以判斷用戶所提出的需求信息是否對項目合適。有些用戶需求信息可能是建議，這些建議是項目之外的，但可能有價值。根據(jù)項目目標把項目相關(guān)人員定位到一個共同的和明確的方向上，并決定軟件系統(tǒng)的范圍。項目目標：主要包括項目開發(fā)的目的和意義，以及軟件系統(tǒng)應(yīng)實現(xiàn)的目標(即目標需求)。項目范圍：指軟件系統(tǒng)具體應(yīng)包括和不應(yīng)包括的部分，以及軟件系統(tǒng)所涉及的各個方面。目標需求會來源于各個不同的人，需要在制定需求規(guī)格說明之前予以解決他們的目標需求的沖突。3-2確定項目的目標和范圍3-3確定調(diào)查對象基本任務(wù)根據(jù)需求層次分類用戶明確地確定來自不同層次的需求來源和用戶，并將其分類。缺乏用戶參與以及最終形成的用戶需求不完整會導(dǎo)致開發(fā)項目失敗。軟件的需求分為目標需求、業(yè)務(wù)需求和功能及非功能需求三個層次，故根據(jù)需求的層次來區(qū)分不同的用戶：提出目標需求的用戶。提出業(yè)務(wù)需求和功能需求的用戶。軟件開發(fā)人員，主要是指系統(tǒng)分析員。3-3

確定調(diào)查對象根據(jù)用戶特點分類用戶用戶代表的義務(wù)為了避免忽視和遺漏某些用戶的情況，可以根據(jù)用戶的某些方面將用戶分類：根據(jù)用戶所在的部門和職責，如計劃部門、銷售部門、財務(wù)部門等。根據(jù)用戶使用系統(tǒng)的頻繁度和優(yōu)先級等。根據(jù)用戶掌握的計算機知識和使用計算機的熟練程度。根據(jù)直接使用和非直接使用軟件系統(tǒng)的情況。每類用戶的代表或聯(lián)絡(luò)人等人代表著特定的用戶類，充當該用戶類與開發(fā)人員之間的“窗口”。用戶代表從他所代表的用戶類中收集需求信息，協(xié)調(diào)他所代表的用戶在需求表達上的不一致和矛盾，為用戶類整理成統(tǒng)一的需求信息。此外，用戶代表應(yīng)具有如右表所示的義務(wù)：3-3

確定調(diào)查對象其他軟件需求來源需求信息除了來自用戶類外，還可來自其他方面，為了不遺漏必要的需求信息，還需考慮從其他地方能收集到的需求信息，下列是幾個典型的軟件需求來源：直接和間接使用軟件系統(tǒng)的用戶。系統(tǒng)需求規(guī)格說明。市場調(diào)查和用戶問卷調(diào)查。已開發(fā)的和待開發(fā)的同類軟件系統(tǒng)的描述和文檔。對人工系統(tǒng)中存在的問題的報告。觀察正在工作的用戶。用戶工作內(nèi)容的分析。3-3

確定調(diào)查對象需求的決策者大量需求信息會包含一些不一致和含糊的需求，需要確定誰是需求的決策者來根據(jù)具體情況，對存在問題的需求信息做出決定。在處理有問題的需求信息時，決策者并不是固定不變的，而是根據(jù)實際中可能發(fā)生的具體問題來確定。例如：當開發(fā)人員想象中的系統(tǒng)與用戶需求不一致時，決策者為用戶。3-4實地收集需求信息3-4-1實地收集需求信息面臨的困難實地收集需求信息并不簡單，軟件開發(fā)人員需要與用戶進行充分的交流，聽取用戶對軟件系統(tǒng)的看法和意見，需要用戶花費時間來講解他們的業(yè)務(wù)流程和工作內(nèi)容。因此，開發(fā)人員往往會遇到如下一些困難:能提出軟件需求的用戶可能覺得沒有充分的時間與開發(fā)人員進行交流和討論。有時用戶希望通過簡單的方法和說明，或者通過簡單回答開發(fā)人員的詢問后，軟件開發(fā)人員就能清楚地理解他們的需求。用戶和開發(fā)人員只考慮自己的利益。用戶本身不能提出明確的需求。開發(fā)人員缺乏用戶的業(yè)務(wù)知識，而用戶也缺乏計算機方面的知識。3-4

實地收集需求信息3-4-2實地調(diào)查的步驟為獲得充分的用戶需求信息，須實地進行調(diào)查并與用戶交流，因此，有步驟地進行實地調(diào)查相當重要的。實地調(diào)查通常分為三個步驟：向掌握“全局”的負責人調(diào)查。掌握“全局”的負責人包括組織機構(gòu)的負責人和高層管理人員。向部門負責人調(diào)查。部門負責人不但熟悉本部門的各項業(yè)務(wù)和業(yè)務(wù)流程，也熟悉部門之間的相互關(guān)系。向業(yè)務(wù)人員調(diào)查。業(yè)務(wù)人員熟悉自身工作的處理細節(jié)，如具體數(shù)據(jù)或表格的作用、來源和去向、類型、精度、處理要求和輸人/輸出的格式等。上述調(diào)查步驟中，步驟2和步驟3是一個反復(fù)的過程，每次調(diào)查之前要制定調(diào)查提綱并作記錄，交由用戶審查核實，以保證需求信息的可靠和準確。3-4

實地收集需求信息3-4-3實地收集需求信息的方式獲取需求的工作只能通過用戶和開發(fā)人員間有效的合作和交流才能成功。為了提高合作和交流的效率，需要有較好的交流方式和手段。開發(fā)人員與用戶的交流可采取如下幾種方式：座談會的方式。通過會議獲得用戶需求信息是用戶與開發(fā)人員交流的一種很好的方式，也是相當常見的方式。書面咨詢的方式。書面咨詢的方式是由軟件開發(fā)人員將所關(guān)心的和有待澄清的問題以書面形式提交給用戶。利用用例表示方法。用例是了解用戶的業(yè)務(wù)流程和澄清含糊細節(jié)的好方法，用于描述軟件系統(tǒng)與一個外部“執(zhí)行者”的交互順序，主要體現(xiàn)執(zhí)行者完成一次任務(wù)的過程。3-4

實地收集需求信息3-4-4需求信息的分類對于一個復(fù)雜的軟件系統(tǒng)，通過收集而得到的用戶需求信息是相當龐大和復(fù)雜的，開發(fā)人員必須把收集到的全部需求信息分成不同的類型后，一方面為編制需求規(guī)格說明和其他文檔等提供基本材料，另一方面也為刪除一些不是真正需求的信息提供依據(jù)。因此，給出需求信息的類型是一項重要的工作，需求信息可大致分類如下：目標需求:描述用戶或開發(fā)機構(gòu)通過產(chǎn)品可獲得的利益和利潤，以及與產(chǎn)品相關(guān)的發(fā)展規(guī)劃等方面的信息。用例說明：有關(guān)利用系統(tǒng)完成業(yè)務(wù)任務(wù)或如何實現(xiàn)用戶目標的陳述可能就是用例。業(yè)務(wù)規(guī)則：一些活動只能在特定的條件下由一些特定的人來完成。功能需求：客戶要求系統(tǒng)具有哪些功能和行為。外部接口需求：這類需求描述了系統(tǒng)與外部的聯(lián)系。限制：指一些合理限制設(shè)計者和程序員選擇的條件。數(shù)據(jù)定義：描述一個數(shù)據(jù)項或一個復(fù)雜的業(yè)務(wù)數(shù)據(jù)結(jié)構(gòu)的格式、允許值或默認值。解決方案：描述了用戶與系統(tǒng)交互的特定方法，使系統(tǒng)產(chǎn)生一系列活動。3-4

實地收集需求信息3-5確定非功能需求非功能需求指的是衡量軟件能否良好運行的定性指標。非功能需求很難定義，由于缺乏定量指標，因此很難根據(jù)這些需求來評價軟件系統(tǒng)，這也是開發(fā)出來的軟件系統(tǒng)與用戶所需的軟件系統(tǒng)之間存在差異的主要原因。對軟件系統(tǒng)的非功能需求有很多，此處僅列舉一些用戶所關(guān)心的非功能需求：可靠性：指軟件系統(tǒng)能夠在給定的時間和環(huán)境條件下完成所需功能的概率?？蓴U充性：軟件系統(tǒng)能夠方便和容易地增加新功能的能力。安全性：涉及防止非法訪問系統(tǒng)功能，防止數(shù)據(jù)丟失，防止病毒感染和防止私人數(shù)據(jù)進入系統(tǒng)等。健壯性：指軟件系統(tǒng)與其他系統(tǒng)交換數(shù)據(jù)和服務(wù)的難易程度。易使用性：指用戶學(xué)習和使用軟件系統(tǒng)功能的簡易程度，可維護性：指在軟件系統(tǒng)中發(fā)現(xiàn)并糾正一個故障或進行一次更改的簡易程度?？梢浦残裕褐笇⒁粋€軟件系統(tǒng)從一個運行環(huán)境移植到另一個運行環(huán)境所需的工作量的度量?？芍赜眯裕褐附M成軟件系統(tǒng)中的某個部件除了在最初開發(fā)的系統(tǒng)中能使用外，還可以在其他應(yīng)用系統(tǒng)中使用的程度。3-5

確定非功能需求收集非功能需求的方法在收集需求信息時，必須根據(jù)用戶對系統(tǒng)的期望來確定非功能需求。大多數(shù)用戶并不可能提出具體的和量化的非功能需求。開發(fā)人員在收集非功能需求信息時，要注意使用一些方法，例如:將不同用戶類代表提出的可能很重要的非功能需求進行綜合，并根據(jù)其中的每個需求設(shè)計出許多方法，然后根據(jù)用戶的回答，使這些需求更明確化。開發(fā)人員與用戶一起對每一個非功能需求制定可測試和可驗證的具體標準。設(shè)計與非功能需求相沖突的假設(shè)示例，利用反例來提示用戶。3-5

確定非功能需求3-6在收集需求信息中應(yīng)注意的問題收集信息過程中的問題收集需求信息中會遇到許多的困難。這些困難有些是發(fā)生在與用戶的交流方面，有些則屬技術(shù)問題，需由軟件開發(fā)人員給予注意和解決。在收集過程中，要注意如下問題:應(yīng)能適當?shù)卣{(diào)整收集范圍。盡量把用戶所做的假設(shè)解釋清楚，特別是發(fā)生沖突的部分。盡量理解用戶用于表達他們需求的思維過程。在收集需求信息時，應(yīng)盡量避免受不熟悉細節(jié)的影響。應(yīng)盡量避免討論一些具體的解決方案。需求信息收集工作的結(jié)束。決定收集工作的結(jié)束并沒有一個簡單和嚴格的標準，需根據(jù)實際情況進行判斷。例如:用戶不可能再提供更多新的需求信息。用戶重復(fù)提出以前已提出的需求信息。與用戶的討論開始進入設(shè)計方面的工作。開發(fā)人員本身已提不出更多的問題。安排收集工作的結(jié)束時間已到。3-6在收集需求信息中應(yīng)注意的問題3-7使用場景技術(shù)的需求獲取3-7-1場景的定義及構(gòu)成場景是指用戶與軟件系統(tǒng)為實現(xiàn)某個目標而進行交互活動過程的描述，可視為是對使用系統(tǒng)經(jīng)歷的解釋。場景的構(gòu)成可以有不同的形式，應(yīng)由如下幾個方面的內(nèi)容構(gòu)成：執(zhí)行者(用戶)。進入場景前系統(tǒng)狀態(tài)的描述。執(zhí)行者的目的。動作和事件系列(包括正?；蚍钦Ｊ录?。通常，場景應(yīng)具有下述特征:場景代表某些用戶可見的功能，可用于描述一個具體的系統(tǒng)功能。場景總是被參與者啟動，并向參與者提供可識別的信息。場景必須是完整的。下圖表示了一個用自然語言描述的某人切斷PC電源的場景。3-7使用場景技術(shù)的需求獲取3-7-2場景的表示除了可用自然語言表示場景外，也可使用圖形、動漫畫等其他表示形式。場景也可與快速原型方法結(jié)合使用。此外，也可利用一些已有的半形式化的圖形表示方法和技術(shù)(如流程圖、狀態(tài)圖、時序圖)以及形式化的方法和技術(shù)(如CCS、CSP、Z語言等)來表示場景。場景的一些典型表示形式如下表所示。3-7使用場景技術(shù)的需求獲取場景的使用者可以根據(jù)具體情況有選擇地使用上述表示形式，也可組合使用幾種表示形式。對于某些水平較高的專業(yè)技術(shù)人員，可以使用更加適合的特殊人工語言來描述場景。在需求信息的獲取中，由于用戶的參與相當重要，使用非形式化的表示形式是合適的，形式化的表示形式對于用戶來說難以理解。3-7-3場景的種類場景描述執(zhí)行者的目標，分為正常場景和失敗場景，正常場景注重目標實現(xiàn)過程和效率，失敗場景注重分析失敗原因。找到執(zhí)行者不能達到目標的理由可以成為改進軟件系統(tǒng)的參考因素。場景進一步可分為正向場景和逆向場景，前者描述所希望實現(xiàn)的目標，后者描述用戶不希望的需求。逆向場景是有效的需求信息收集工具，可避免混入無用的需求信息。場景之間可以建立關(guān)系和精化處理，如擴展關(guān)系和使用關(guān)系。若干場景中的相同動作可以提取出來構(gòu)成一個單獨的場景。大部分場景在項目需求獲取階段產(chǎn)生，并隨著需求分析的深入不斷發(fā)現(xiàn)。此外新發(fā)現(xiàn)的場景應(yīng)及時補充進已有的場景集合中。3-7使用場景技術(shù)的需求獲取3-7-4場景技術(shù)的特點場景技術(shù)把軟件系統(tǒng)的需求信息文本化，有助于在實現(xiàn)軟件系統(tǒng)前明確用戶與軟件系統(tǒng)的相互作用。此外，場景技術(shù)還具有如下特點：可以把當前系統(tǒng)存在的問題作為實例記錄下來。可以成為項目相關(guān)人員間的共同語言。由于場景描述了軟件系統(tǒng)的操作，比較具體，易理解性較好。通過場景使得提出和獲得需求的雙方之間能建立起相應(yīng)的理解。另一方面，在使用場景技術(shù)時，也要注意如下問題:場景的數(shù)量，即一個軟件項目應(yīng)該寫多少個場景沒有限制標準。場景的冗余問題。應(yīng)盡量避免場景描述的內(nèi)容發(fā)生重疊。應(yīng)防止場景描述內(nèi)容的冗長。3-7使用場景技術(shù)的需求獲取3-8基于用例的需求獲取用例的定義Jacobson：用例用于描述軟件系統(tǒng)與一個外部“執(zhí)行者”(actor)的交互順序用例與前述的場景并不是同一概念。用例通常用于描述可發(fā)生的所有事件序列，而場景則是描述其中的一部分。用例也可以說是場景的集合，一個場景是用例的實例。體現(xiàn)了執(zhí)行者完成一項任務(wù)的過程。執(zhí)行者可為一個人或一個應(yīng)用軟件系統(tǒng)，也可以是硬件或者某些與軟件系統(tǒng)交互以實現(xiàn)某些目標的外部實體。在利用用例建立系統(tǒng)模型時，軟件系統(tǒng)被視為一個黑盒子，并可使用自然語言順序地描述軟件系統(tǒng)與外部執(zhí)行者的相互作用。3-8

基于用例的需求獲取3-8

基于用例的需求獲取ATM