【文章內(nèi)容簡介】 ，并重復(fù) 13步； ? 第 5步： 需求分類和組織， 以區(qū)別 功能需求、非功能需求、約束條件、業(yè)務(wù)規(guī)則、外部接口需求 、建議解決方法和附加信息； ? 第 6步： 優(yōu)先排序和沖突解決； ? 第 7步：得到最終需求清單，并與客戶做 最終簽字確認。 2023/1/30 61 “看似簡單，實際卻很難 …‖ —— ―需求獲?。坎痪褪菃枂栴}嗎？這有什么難的？” 2023/1/30 65 需求獲取技術(shù) ? 需求獲取的關(guān)鍵： – 溝通和交流 ? 所要避免的問題： – 交流障礙、溝通不全、意見沖突 ? 所要必備的條件： – 較高的技術(shù)水平、豐富的實踐經(jīng)驗、較強的人際交往能力 ? 可能采取的手段： – 用戶訪談、現(xiàn)場考察、專家咨詢、會議討論、 … 2023/1/30 66 需求獲取技術(shù) ? 面對面訪談 (facetoface interviewing) ? 專題討論會 (workshop) ? 現(xiàn)場觀察 (observing on the scene) ? 頭腦風(fēng)暴 (brain storming) ? 多種方法要復(fù)合在一起使用，效果更好 2023/1/30 67 面對面訪談 2023/1/30 68 面對面訪談 ? 需求獲取中最直接的方法：用戶面談 (interviewing) ? ―看起來很美”，但“做起來并不容易” ——需求分析者個人的偏見、事先的理解、以往的經(jīng)驗積累是導(dǎo)致面談失敗的最重要原因 ——在面談時，忘掉一切以往所作的事情，通過問題啟發(fā)，傾聽對方的陳述 ——不要把自己放在“專家”的位置上 2023/1/30 69 如何提問？ ? “每個人都能提問題，但并不等于人人都會提問題 …‖ ? 封閉式問題： – 對錯判斷或多項選擇題，回答只需要一兩個詞 ? 開放式問題： – 這種問題需要解釋和說明，同時向?qū)Ψ奖硎灸銓λ麄冋f的話很感興趣，還想了解更多的內(nèi)容。 ? 通過提問題增強你對談話進展和方向的控制 ? 問題不能過于寬泛 ? 最開始的問題不能太難 ? 不能在提問之前就已經(jīng)表示不贊同 ? 談話之前有意識的準備一些備用問題 2023/1/30 70 訪談問題的分類 ? 上下文無關(guān)的問題 (contextfree questions)：充分理解用戶的問題，不涉及具體的解決方案 – 客戶是誰？ – 最終用戶是誰？ – 不同用戶的需求是否不同？ – 這種需求目前的解決方案是什么？ ? 解決方案相關(guān)的問題 (solutioncontext questions)：通過這類問題，探尋特定的解決方案并得到用戶認可 – 你希望如何解決這個問題？ – 你覺得該問題這樣解決如何？ 2023/1/30 71 面談之前 ? 確立面談目的 ? 確定要包括的相關(guān)用戶 ? 確定參加會議的項目小組成員 ? 建立要討論的問題和要點列表 ? 復(fù)查有關(guān)文檔和資料 ? 確立時間和地點 ? 通知所有參加者有關(guān)會議的目的、時間和地點 2023/1/30 72 面談之中 ? Step 1：事先準備一系列上下文無關(guān)的問題，并將其記錄下來以便面談時參考； ? Step 2：面談前，了解一下要面談的客戶公司的背景資料，不要選擇自己能回答的問題而浪費時間； ? Step 3：面談過程中，參考事先準備的面談模板，以保證提出的問題是正確的。將答案記錄到紙面上，并指出和記錄下未回答條目和未解決問題； ? Step 4：面談之后，分析總結(jié)面談記錄。 2023/1/30 73 面談之后 ? 復(fù)查筆記的準確性、完整性和可理解性 ? 把所收集的信息轉(zhuǎn)化為適當?shù)哪Ｐ秃臀臋n ? 確定需要進一步澄清的問題域 ? 向參加會議的每一個人發(fā)出此次面談的 minutes(會議紀要 )。 2023/1/30 74 面談記錄的示例 (1) ? 第一部分：建立客戶或用戶情況表 ? 第二部分：評估問題 – 詢問用戶對哪些類型的問題缺乏好的解決方案 – 它們是什么？ (不斷的問“還有嗎？” ) ? 第三部分：理解用戶環(huán)境 – 誰是用戶？他們的經(jīng)歷和經(jīng)驗如何？用戶的預(yù)期如何？ ? 第四部分：扼要說明理解情況 – 你剛才告訴我： (用自己的話復(fù)述客戶描述的問題 ) – 這是否足以表達你現(xiàn)在的解決方案中存在的問題？ – 如果有，你還有什么問題？ 2023/1/30 75 面談記錄的示例 (2) ? 第五部分：分析人員對客戶問題的輸入 – 對每個問題進行以下提問： ? 這是一個實際的問題嗎？ ? 問題產(chǎn)生的原因是什么？ ? 現(xiàn)在如何解決的？ ? 希望如何解決？ ? 該問題的重要度如何？ ? 第六部分：評估自己的解決方案 – 總結(jié)自己建議的解決方案； – 對自己方案的優(yōu)先級排序； ? 第七部分：評估機會 ? 第八部分：評估可靠性、性能及其他需要 2023/1/30 76 面談記錄的示例 (3) ? 第九部分：其他需求 – 法律法規(guī)、環(huán)境、行業(yè)標準等； ? 第十部分：總結(jié)性提問 – 還有其他問題要問面談人嗎？ – 尚未解決的問題有哪些？ – 下次訪談的方式、地點、時間、參加人等； ? 第十一部分：分析人員的總結(jié) – 總結(jié)出客戶 /用戶確認的三條優(yōu)先級最高的需求或問題。 2023/1/30 77 面對面訪談的優(yōu)缺點分析 ? 優(yōu)點： – 人們很愿意談?wù)撟约旱墓ぷ?，并且總是很喜歡接受訪談； ? 缺點： – 大多數(shù)人都采用專業(yè)術(shù)語和“行話”，而太多的專業(yè)術(shù)語讓需求工程師難以理解，往往造成很多誤解； – 有些需求對用戶來說太普通了，以至于他們不自覺地認為這些需求太基本，不值得去提。但它們對需求工程師來說卻不是顯而易見的。這往往會造成某些需求被忽略； 2023/1/30 78 需求研討會 (Workshop) 2023/1/30 79 需求研討會 (Workshop) 2023/1/30 80 需求研討會 (Workshop) ? 通過讓所有相關(guān)人員一起參加某個單一會議來定義需求或設(shè)計系統(tǒng)，也稱聯(lián)合應(yīng)用設(shè)計會議 (Joint Application Design, JAD)。 ? 系統(tǒng)相關(guān)者在短暫而緊湊的時間段內(nèi)集中在一起，一般為1至 2天，與會者可以在應(yīng)用需求上達成共識、對操作過程盡快取得統(tǒng)一意見。 ? 協(xié)助建立一支高效團隊，圍繞一個目的：項目的成功； ? 所有人員都暢所欲言； ? 促進用戶與開發(fā)團隊之間達成共識； ? 能夠揭露和解決那些妨礙項目成功的行政問題； ? 最終很快產(chǎn)生初步的系統(tǒng)定義。 2023/1/30 81 需求研討會 (Workshop) ? 專題討論會準備 – 參加會議人員：主持人、用戶、技術(shù)人員、項目組人員 – 安排日程 – 通常在具有相應(yīng)支持設(shè)備的專用房間進行 ? 舉行會議 – 可能出現(xiàn)人員之間的責(zé)備或沖突，主持人應(yīng)掌握討論氣氛并控制會場 – 最重要的部分是自由討論階段，這種技術(shù)非常符合專題討論會的氣氛，并且營造一種創(chuàng)造性的和積極的氛圍，同時可以獲得所有相關(guān)者的意見 – 分配會議時間，記錄所有言論 2023/1/30 82 現(xiàn)場觀察 ? 用戶可能無法有效全面的表達自己的需求，通過面談和會議也難以獲得完整信息； ? 在這種情況下，現(xiàn)場觀察用戶的工作流程有助于更深入全面了解需求。 ? 兩種方式： – 被動觀察：用戶實地工作，需求分析人員在旁邊看 – 主動觀察：需求分析人員直接參與用戶的實際工作 2023/1/30 83 頭腦風(fēng)暴 (Brainstorming) 2023/1/30 84 頭腦風(fēng)暴 (Brainstorming) ? 一般以 812人最佳： – 人數(shù)太少不利于交流信息和激發(fā)思維；人數(shù)太多則不容易掌握，并且每個人發(fā)言的機會相對減少 ? 明確分工： 1名主持人、 2名記錄員 ? 成功要點： – 自由暢談 – 延遲批判、禁止批評 – 禁止批評、自我批評、自謙 – 追求數(shù)量 ? 會后：修剪、分組、排序 ? 適用場合：產(chǎn)品型系統(tǒng)，需要具有創(chuàng)新性特征，尚未投放市場，無明確的客戶。 2023/1/30 85 需求分析的任務(wù)與原則 2023/1/30 86 需求工程過程 需求工程過程分為需求開發(fā)和需求管理兩階段。 需 求 獲 取 需 求 分 析 需 求 描 述 需 求 驗 證 需 求 管 理需 求 開 發(fā) 過 程 需 求 管 理 過 程2023/1/30 87 需求分析的任務(wù)與原則 ? 需求分析的基本任務(wù)是分析與綜合已收集到的需求信息，通過分析找出需求信息內(nèi)在聯(lián)系和可能的矛盾，通過綜合找出解決問題的方法并建立系統(tǒng)的邏輯模型。 ? 具體地說，需求分析是提煉、分析和審查已收集到的需求信息，找出真正的和具體的需求，并確保所有相關(guān)人員都理解其含義。 2023/1/30 88 需求分析的任務(wù)與原則 1. 繪制系統(tǒng)關(guān)聯(lián)圖 關(guān)聯(lián)圖是用于定義系統(tǒng)與系統(tǒng)外部實體間的界限和接口的簡單模型。 2. 創(chuàng)建用戶接口原型 當開發(fā)人員或用戶不能確定軟件需求時，開發(fā)一個用戶接口原型 (可能的局部實現(xiàn) )，這樣使得許多概念和可能發(fā)生的事更為直觀明了。 2023/1/30 89 需求分析的任務(wù)與原則 3. 分析需求可行性 在允許的成本、性能要求下，分析每項需求實施的可行性。 4. 確定需求的優(yōu)先級 應(yīng)用分析方法來確定使用實例、產(chǎn)品特性或單項需求實現(xiàn)的優(yōu)先級。 5. 為需求建立模型 需求的圖形分析模型是軟件需求規(guī)格說明的補充說明。 2023/1/30 90 需求分析的任務(wù)與原則 6. 創(chuàng)建數(shù)據(jù)字典 數(shù)據(jù)字典是對系統(tǒng)用到的所有數(shù)據(jù)項和結(jié)構(gòu)的定義，以確保開發(fā)人員使用統(tǒng)一的數(shù)據(jù)定義。 7. 質(zhì)量功能調(diào)配 質(zhì)量功能調(diào)配是一種高級系統(tǒng)技術(shù)，它將產(chǎn)品特性、屬性與對客戶的重要性聯(lián)系起來。該技術(shù)提供了一種分析方法以明確那些是客戶最為關(guān)注的特性。 2023/1/30 91 需求分析的任務(wù)與原則 需求分析的原則 1． 必須能夠表達和理解問題的數(shù)據(jù)域和功能域 對于計算機程序處理的數(shù)據(jù) ， 其數(shù)據(jù)域應(yīng)包括數(shù)據(jù)流 、 數(shù)據(jù)內(nèi)容和數(shù)據(jù)結(jié)構(gòu) 。 就是將一種形式的數(shù)據(jù)轉(zhuǎn)換成另一種形式的數(shù)據(jù) 。 2023/1/30 92 需求分析的任務(wù)與原則 需求分析的原則 、 逐層分解問題 ? 分解問題是把問題以某種方式分解為幾個較易理解的部分 ， 并確定各部分間的接口 ，從而實現(xiàn)整體功能 。 ? 在需求分析階段 ， 軟件的功能域和信息域都能做進一步的分解 。 這種分解可以是同一層次上的 ， 稱為橫向分解；也可以是多層次的縱向分解 。 2023/1/30 93 需求分析的任務(wù)與原則 需求分析的原則 ? 這對系統(tǒng)滿足處理需求所提出的邏輯限制條件和系統(tǒng)中其他成分提出的物理限制條件是必不可少的 。 ? 軟件需求的邏輯視圖給出軟件要達到的功能和要處理數(shù)據(jù)之間的關(guān)系 。 ? 軟件需求的物理視圖給出處理功能和數(shù)據(jù)結(jié)構(gòu)的實際表示形式 。 2023/1/30 94 2023/1/30 95 ? 需求建模方法的共同特性 ： 1． 提供描述手段 2． 提供基本步驟 ? 建模方法主要包括結(jié)構(gòu)化的需求建模方法和面向?qū)ο蟮男枨蠼７椒? 2023/1/30 96 ? 基本特點是表達問題時盡可能使用圖形符號的形式 ， 設(shè)計數(shù)據(jù)流圖時只考慮系統(tǒng)必須完成的基本功能 ， 不必考濾如何具體實現(xiàn)這些功能 。 ? 基本思想是按照由抽象到具體 、 逐層分解的方法 ， 確定軟件系統(tǒng)內(nèi)部的數(shù)據(jù)流 、 變換關(guān)系 ， 并用數(shù)據(jù)流圖表示 。 ? 描述手段 ① 一套分層的數(shù)據(jù)流圖 ② 一本詞典 ③ 其他補充材料 2023/1/30 97 數(shù)據(jù)流圖 (DFD) ? 數(shù)據(jù)流圖 (Data Flow Diagram, DFD)： 結(jié)構(gòu)化系統(tǒng)分析的基本工具