【正文】 經(jīng)驗(yàn)、較強(qiáng)的人際交往能力 ? 可能采取的手段： – 用戶訪談、現(xiàn)場(chǎng)考察、專家咨詢、會(huì)議討論、 … 2023/1/30 66 需求獲取技術(shù) ? 面對(duì)面訪談 (facetoface interviewing) ? 專題討論會(huì) (workshop) ? 現(xiàn)場(chǎng)觀察 (observing on the scene) ? 頭腦風(fēng)暴 (brain storming) ? 多種方法要復(fù)合在一起使用，效果更好 2023/1/30 67 面對(duì)面訪談 2023/1/30 68 面對(duì)面訪談 ? 需求獲取中最直接的方法：用戶面談 (interviewing) ? ―看起來很美”，但“做起來并不容易” ——需求分析者個(gè)人的偏見、事先的理解、以往的經(jīng)驗(yàn)積累是導(dǎo)致面談失敗的最重要原因 ——在面談時(shí)，忘掉一切以往所作的事情，通過問題啟發(fā)，傾聽對(duì)方的陳述 ——不要把自己放在“專家”的位置上 2023/1/30 69 如何提問？ ? “每個(gè)人都能提問題，但并不等于人人都會(huì)提問題 …‖ ? 封閉式問題： – 對(duì)錯(cuò)判斷或多項(xiàng)選擇題，回答只需要一兩個(gè)詞 ? 開放式問題： – 這種問題需要解釋和說明，同時(shí)向?qū)Ψ奖硎灸銓?duì)他們說的話很感興趣，還想了解更多的內(nèi)容。將答案記錄到紙面上，并指出和記錄下未回答條目和未解決問題； ? Step 4：面談之后，分析總結(jié)面談?dòng)涗洝? 2023/1/30 74 面談?dòng)涗浀氖纠?(1) ? 第一部分：建立客戶或用戶情況表 ? 第二部分：評(píng)估問題 – 詢問用戶對(duì)哪些類型的問題缺乏好的解決方案 – 它們是什么？ (不斷的問“還有嗎？” ) ? 第三部分：理解用戶環(huán)境 – 誰是用戶？他們的經(jīng)歷和經(jīng)驗(yàn)如何？用戶的預(yù)期如何？ ? 第四部分：扼要說明理解情況 – 你剛才告訴我： (用自己的話復(fù)述客戶描述的問題 ) – 這是否足以表達(dá)你現(xiàn)在的解決方案中存在的問題？ – 如果有，你還有什么問題？ 2023/1/30 75 面談?dòng)涗浀氖纠?(2) ? 第五部分：分析人員對(duì)客戶問題的輸入 – 對(duì)每個(gè)問題進(jìn)行以下提問： ? 這是一個(gè)實(shí)際的問題嗎？ ? 問題產(chǎn)生的原因是什么？ ? 現(xiàn)在如何解決的？ ? 希望如何解決？ ? 該問題的重要度如何？ ? 第六部分：評(píng)估自己的解決方案 – 總結(jié)自己建議的解決方案； – 對(duì)自己方案的優(yōu)先級(jí)排序； ? 第七部分：評(píng)估機(jī)會(huì) ? 第八部分：評(píng)估可靠性、性能及其他需要 2023/1/30 76 面談?dòng)涗浀氖纠?(3) ? 第九部分：其他需求 – 法律法規(guī)、環(huán)境、行業(yè)標(biāo)準(zhǔn)等； ? 第十部分：總結(jié)性提問 – 還有其他問題要問面談人嗎？ – 尚未解決的問題有哪些？ – 下次訪談的方式、地點(diǎn)、時(shí)間、參加人等； ? 第十一部分：分析人員的總結(jié) – 總結(jié)出客戶 /用戶確認(rèn)的三條優(yōu)先級(jí)最高的需求或問題。但它們對(duì)需求工程師來說卻不是顯而易見的。 ? 系統(tǒng)相關(guān)者在短暫而緊湊的時(shí)間段內(nèi)集中在一起，一般為1至 2天，與會(huì)者可以在應(yīng)用需求上達(dá)成共識(shí)、對(duì)操作過程盡快取得統(tǒng)一意見。 2023/1/30 81 需求研討會(huì) (Workshop) ? 專題討論會(huì)準(zhǔn)備 – 參加會(huì)議人員：主持人、用戶、技術(shù)人員、項(xiàng)目組人員 – 安排日程 – 通常在具有相應(yīng)支持設(shè)備的專用房間進(jìn)行 ? 舉行會(huì)議 – 可能出現(xiàn)人員之間的責(zé)備或沖突，主持人應(yīng)掌握討論氣氛并控制會(huì)場(chǎng) – 最重要的部分是自由討論階段，這種技術(shù)非常符合專題討論會(huì)的氣氛，并且營(yíng)造一種創(chuàng)造性的和積極的氛圍，同時(shí)可以獲得所有相關(guān)者的意見 – 分配會(huì)議時(shí)間，記錄所有言論 2023/1/30 82 現(xiàn)場(chǎng)觀察 ? 用戶可能無法有效全面的表達(dá)自己的需求，通過面談和會(huì)議也難以獲得完整信息； ? 在這種情況下，現(xiàn)場(chǎng)觀察用戶的工作流程有助于更深入全面了解需求。 2023/1/30 85 需求分析的任務(wù)與原則 2023/1/30 86 需求工程過程 需求工程過程分為需求開發(fā)和需求管理兩階段。 ? 具體地說，需求分析是提煉、分析和審查已收集到的需求信息，找出真正的和具體的需求，并確保所有相關(guān)人員都理解其含義。 2. 創(chuàng)建用戶接口原型 當(dāng)開發(fā)人員或用戶不能確定軟件需求時(shí)，開發(fā)一個(gè)用戶接口原型 (可能的局部實(shí)現(xiàn) )，這樣使得許多概念和可能發(fā)生的事更為直觀明了。 4. 確定需求的優(yōu)先級(jí) 應(yīng)用分析方法來確定使用實(shí)例、產(chǎn)品特性或單項(xiàng)需求實(shí)現(xiàn)的優(yōu)先級(jí)。 2023/1/30 90 需求分析的任務(wù)與原則 6. 創(chuàng)建數(shù)據(jù)字典 數(shù)據(jù)字典是對(duì)系統(tǒng)用到的所有數(shù)據(jù)項(xiàng)和結(jié)構(gòu)的定義，以確保開發(fā)人員使用統(tǒng)一的數(shù)據(jù)定義。該技術(shù)提供了一種分析方法以明確那些是客戶最為關(guān)注的特性。 就是將一種形式的數(shù)據(jù)轉(zhuǎn)換成另一種形式的數(shù)據(jù) 。 ? 在需求分析階段 ， 軟件的功能域和信息域都能做進(jìn)一步的分解 。 2023/1/30 93 需求分析的任務(wù)與原則 需求分析的原則 ? 這對(duì)系統(tǒng)滿足處理需求所提出的邏輯限制條件和系統(tǒng)中其他成分提出的物理限制條件是必不可少的 。 ? 軟件需求的物理視圖給出處理功能和數(shù)據(jù)結(jié)構(gòu)的實(shí)際表示形式 。 ? 基本思想是按照由抽象到具體 、 逐層分解的方法 ， 確定軟件系統(tǒng)內(nèi)部的數(shù)據(jù)流 、 變換關(guān)系 ， 并用數(shù)據(jù)流圖表示 。 – 收集、排序、選擇、聚集、分析等 – 加工要有名字，通常是動(dòng)詞短語，簡(jiǎn)明地描述完成什么事情 – 在分層的數(shù)據(jù)流圖中，加工還應(yīng)編號(hào) – 三種類型：計(jì)算機(jī)自動(dòng)加工、手工加工、人機(jī)協(xié)作的加工 1 錄入訂單 2 審核訂單 2023/1/30 100 DFD的主要元素 (2)：數(shù)據(jù)存儲(chǔ) ? 數(shù)據(jù)存儲(chǔ) (data storage，也稱文件 )：需要在外存儲(chǔ)器上保存的數(shù)據(jù)，它可以是數(shù)據(jù)庫(kù)文件或任何形式的數(shù)據(jù)組織。 – 由于數(shù)據(jù)流是流動(dòng)中的數(shù)據(jù)，所以必須有流向 – 應(yīng)用名詞或名詞短語命名 – 可能是紙張上的數(shù)據(jù)、電子數(shù)據(jù)、通過網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)等 – 可能存在于： ? 外部實(shí)體與加工之間； ? 加工與加工之間； ? 加工與數(shù)據(jù)存儲(chǔ)之間 2023/1/30 103 DFD的簡(jiǎn)單練習(xí) 文件1 加法 (+ )2 乘法 (*)3 加法 (+ )顧客abadc4 乘法 (*)a + ba*dc + a *d( a + b ) * ( c + a *d )? 背景：用戶輸入 a、 b、 c、 d四個(gè)值，系統(tǒng)計(jì)算(a+b)*(c+a*d)，并將結(jié)果輸出到一個(gè)文件中存儲(chǔ)。 ? 最底層 DFD中的加工稱為 “基本加工” 。 外部實(shí)體 1數(shù)據(jù)流外部實(shí)體 2數(shù)據(jù)流數(shù)據(jù)存儲(chǔ) 10 系統(tǒng)2023/1/30 115 父圖與子圖的平衡 ? 下層 DFD中的輸入輸出數(shù)據(jù)流同上層 DFD中相應(yīng)加工的輸入輸出數(shù)據(jù)流必須一致，此即父圖與子圖的平衡。 – 根據(jù)缺貨記錄進(jìn)行缺貨統(tǒng)計(jì)，將缺貨通知單發(fā)給采購(gòu)部門，以便采購(gòu)。 – 根據(jù)留底的訂單進(jìn)行銷售統(tǒng)計(jì)，打印統(tǒng)計(jì)表給經(jīng)理。 2．?dāng)?shù)據(jù)流圖的特性 （ 1）抽象性 （ 2）概括性（ 3）層次性 3. 數(shù)據(jù)流圖基本符號(hào) （ 1）源點(diǎn)（ 2）加工（ 3）數(shù)據(jù)流 （ 4）數(shù)據(jù)存儲(chǔ)文件 4．?dāng)?shù)據(jù)流圖的用途 作為交流信息的工具。 (2) 可以反映出數(shù)據(jù)的流向和處理過程。 (4) 容易與計(jì)算機(jī)處理相對(duì)照。 2023/1/30 126 數(shù)據(jù)流圖 6． 數(shù)據(jù)流圖的畫法 (1) 畫數(shù)據(jù)流圖的一般原則 畫數(shù)據(jù)流圖的基本步驟概括地說，就是自外向內(nèi)，自頂向下，逐層細(xì)化，完善求精。 2．?dāng)?shù)據(jù)字典的內(nèi)容 （ l）數(shù)據(jù)流 （ 2）數(shù)據(jù)項(xiàng) （ 3）數(shù)據(jù)結(jié)構(gòu) （ 4）數(shù)據(jù)存儲(chǔ) （ 5）處理邏輯 （ 6）外部實(shí)體 3．定義數(shù)據(jù)的方法 對(duì)數(shù)據(jù)自頂向下的分解 2023/1/30 130 數(shù)據(jù)字典 4．?dāng)?shù)據(jù)字典的用途 數(shù)據(jù)字典最重要的用途是作為分析階段的工具。 2023/1/30 131 數(shù)據(jù)字典 (DD) ? DFD只是繪制了系統(tǒng)各功能之間的數(shù)據(jù)流動(dòng)和處理關(guān)系，還需進(jìn)一步考慮各數(shù)據(jù)的具體內(nèi)容。 – DD所有的定義應(yīng)是嚴(yán)密的、精確的，不可有半點(diǎn)含混，不可有二義性。 – 分機(jī)號(hào)從 8201至 8299。 – 長(zhǎng)途電話號(hào)碼由區(qū)號(hào)和市話號(hào)碼組成，其中區(qū)號(hào)可以為 0021~02 0300~0999中的任意一個(gè)數(shù)字串。 2023/1/30 139 示例：數(shù)據(jù)字典 (1) ? “電話號(hào)碼”的數(shù)據(jù)字典： – 電話號(hào)碼 =[分機(jī)號(hào) |外線號(hào)碼 ] – 分機(jī)號(hào) =8201..8299 – 外線號(hào)碼 =0+[市話號(hào)碼 |長(zhǎng)途電話號(hào)碼 ] – 市話號(hào)碼 ={數(shù)字 } – 長(zhǎng)途電話號(hào)碼 =區(qū)號(hào) +市話號(hào)碼 – 區(qū)號(hào) =[010|021..029|0300..0999] 2023/1/30 140 示例：數(shù)據(jù)字典 (2) 名字： 零件編號(hào) 別名： 編碼 描述： 唯一的標(biāo)識(shí)庫(kù)存清單中一個(gè)特定零件 定義： 零件編號(hào) ={字符 }8 位置： 庫(kù)存清單 采購(gòu)訂單 訂貨報(bào)表 名字： 采購(gòu)訂單 別名： 采購(gòu)單 描述： 由各部門采購(gòu)人員定期向供應(yīng)商發(fā)出的單據(jù) 定義： 采購(gòu)訂單 =供應(yīng)商 ID+供應(yīng)商名稱 +采購(gòu)日期 +總金額 + {零件編號(hào) +零件名稱 +數(shù)量 +價(jià)格 } 位置： 訂貨報(bào)表 2023/1/30 141 層次方框圖 Warnier圖 IPO圖 2023/1/30 142 層次方框圖 ? 層次方框圖用樹形結(jié)構(gòu)的一系列多層次的矩形框描述數(shù)據(jù)的層次結(jié)構(gòu) 。 ? 系統(tǒng)分析員從對(duì)頂層信息的分類開始 ， 沿圖中每條路徑反復(fù)細(xì)化 ， 直到確定了數(shù)據(jù)結(jié)構(gòu)的全部細(xì)節(jié)為止 。 2023/1/30 144 IPO圖 ? IPO圖是輸入 /處理 /輸出圖的簡(jiǎn)稱 ,它是美國(guó)IBM公司提出的一種圖形工具 ,能夠方便地描繪輸入數(shù)據(jù) 、 處理數(shù)據(jù)和輸出數(shù)據(jù)的關(guān)系 。 2023/1/30 145 2023/1/30 146 需求驗(yàn)證的目的是確保需求規(guī)格說明具有良好（ 例如完整性和正確性 ） 。 2023/1/30 147 需求分析評(píng)審的主要內(nèi)容 : :所有需求必須是一致的，任何一條需求不能和其他需求互相矛盾。 :指定的需求應(yīng)該是用現(xiàn)有的硬件技術(shù)和軟件技術(shù)基本上可以實(shí)現(xiàn)的。 2023/1/30 148 需求驗(yàn)證的方法 : 1. 驗(yàn)證需求的一致性 自然語言書寫靠人工技術(shù)審查驗(yàn)證軟件系統(tǒng)規(guī)格說明書的正確性 當(dāng)軟件需求規(guī)格說明書是用形式化的需求陳述語言書寫的時(shí)候，可以用軟件工具驗(yàn)證需求的一致性。 3. 驗(yàn)證需求的完整性和有效性 快速原型法 原型系統(tǒng)所顯示的是系統(tǒng)的主要功能而不是性能，因此可以適當(dāng)降低對(duì)接口、可靠性等的要求，還可以節(jié)省文檔等方面的工作，從而可大大降低原型系統(tǒng)的開發(fā)成本 2023/1/30 150 需求評(píng)審 需求評(píng)審就是技術(shù)評(píng)審，是由非軟件開發(fā)人員對(duì)軟件系統(tǒng)進(jìn)行檢查，進(jìn)而發(fā)現(xiàn)系統(tǒng)存在的問題。 ? 需求管理的目標(biāo)如下： 1. 控制軟件需求，并建立軟件工程和管理使用的需求基線； 2. 使軟件計(jì)劃、產(chǎn)品和活動(dòng)與軟件需求保持一致。 2023/1/30 155 需求開發(fā)的管理 (1)需求來源 (2)需求形式化 (3)需求跟蹤矩陣 (1)編寫測(cè)試計(jì)劃與測(cè)試用例； (2)編寫系統(tǒng)驗(yàn)收標(biāo)準(zhǔn)； (3)通過需求評(píng)審； (4)需求評(píng)審的誤區(qū)。 正向跟蹤與逆向跟蹤 建立需求狀態(tài)是為了表示需求的各種不同情況 。 ? 只有通過軟件需求分析 ， 才能把軟件功能和性能的總體概念描述為具體的軟件需求規(guī)格說明 ， 進(jìn)而建立軟件開發(fā)的基礎(chǔ) 。 演講完畢，謝謝觀看！