【正文】 形式規(guī)約，形式建模 ? 就問題性質達成共識 驗證 , 沖突及矛盾消解 , 磋商 需求管理 – 維護雙方的共識 軟件工程 43 43 需求：關于為什么？做什么？ 不包括怎么做？ （ why, what, how） ? … 需求描述必須給出 為什么 需要這樣一個系統(tǒng)。但是，二者不太容易區(qū)分，上一個抽象層次的“怎么做”經常在下一個抽象層次上轉化為“做什么”。 ? “怎么做”是指系統(tǒng)的內部結構和行為。 ? 用戶需求 (user requirement) 描述了用戶使用產品必須要完成的任務，這在使用實例（ use case）文檔或方案腳本（ scenario）說明中予以說明。 軟件工程 48 Environment 客戶 由客戶的Goal 找出 流程 出口 押匯 轉賬 (Domain) 世 華銀行 外 匯業(yè)務 出口 托收 軟件工程 49 看 單人員 結賬人員 柜臺人員 收件 審單 解款 出口 托收作業(yè) : 呈 報 審單 解款 收件 呈 報 IS 使用UML 表示之 軟件工程 50 50 軟件需求各組成部分之間的關系 管理人員或市場分析人員確定軟件的 業(yè)務需求 ，使公司運作更加高效（對信息系統(tǒng)而言）或具有很強的市場競爭力（對商業(yè)軟件產品而言）。用戶需求使需求分析者能從中總結出 功能需求 以滿足用戶對產品的要求從而完成其任務，而開發(fā)人員則根據功能需求 來設計軟件以實現必須的功能。功能需求可以在多種不同的抽象層次上來表達，這使得導出需求過程比較復雜和困難： a) Physical behavior b) Inputoutput relationship c) Observable states d) User interface 軟件工程 52 4. 軟件需求的分類 ④ 非功能需求 非功能需求是功能需求的補充，它描述了系統(tǒng)完成功能實現的補充和約束條件。 在具體操作時，關于可靠性和可用性的規(guī)范最為困難，但又是客戶最為關心的 軟件工程 53 4. 軟件需求的分類 ④ 非功能需求 a) Response b) Accuracy c) Frequency d) Capacity e) Throughput f) Defect rates g) Modifiability h) Supportability 軟件工程 54 4. 軟件需求的分類 ⑤ 設計約束 設計約束是真正意義上的非功能約束，它們約束系統(tǒng)怎樣被構建而不是系統(tǒng)做什么。 Karakostas, 1995） 軟件工程 59 59 原型法 （ Prototype） ? 適用范圍： ? 用于獲取關于系統(tǒng)用戶界面的需求 ? 用于檢驗設計方案的可行性，或探討系統(tǒng)性能問題 ? 存在的問題： ? 用戶將原型誤認為最終系統(tǒng) ? 原型所反映的系統(tǒng)是不全面的 （ Loucopoulos amp。 Dorfman, 1997, p10) 軟件工程 61 61 螺旋模型 (Spiral Model) ? 螺旋模型主要用于風險分析 ? 每一輪開發(fā)活動具體包括 : ? 制定下一輪計劃 ? 決定設計目標和限制條件 ? 評估候選方案 , 風險降解 ? 產品開發(fā) ? 需求工程有關步驟為： ? 需求風險分析 ? 規(guī)劃設計 ? 可以減少 需求變更 所帶來的風險 ? 存在的問題： ? 無法應付 不可預見的需求變化 軟件工程 62 62 關于敏捷模型 （ Agile Models） 基本原則： ? 減少溝通障礙 ? 程序員與客戶直接交流 ? 減低繁重的文檔負擔 ? 文檔代價昂貴但用途有限 ? 對開發(fā)人員給予充分信任 ? 無需運用花樣翻新的過程模型給與提示 ? 響應客戶要求 ? 而非嚴格遵循合同條文 缺點： 依賴程序員的記憶力 源代碼是難于維護的 依賴口頭交流 易發(fā)生誤解 假定只有唯一的客戶代表 不可能反映多視角 制作短期計劃 無長期及前瞻性規(guī)劃 軟件工程 63 1. 需求獲?。ǐ@取哪些內容？） 1) 定義需求開發(fā)過程 2) 定義項目愿景和范圍 3) 確定用戶群 4) 選擇用戶代理人 5) 確定用例 6) 確定系統(tǒng)事件和響應 7) 描述軟件的 功能 和 性能 8) 指明軟件與其他系統(tǒng)元素的 接口 9) 建立軟件必須滿足的 約束 軟件工程 64 需求獲取的主要步驟 1. 開發(fā)高層的業(yè)務模型 ? 理解應用領域 ，即目標軟件的應用環(huán)境。 ? 一旦系統(tǒng)分析人員對該領域有了充分了解，就可以 建立一個業(yè)務模型 ，描述用戶的業(yè)務過程，確定用戶的初始需求。 軟件工程 65 Environment 客戶 由客戶的Goal 找出 流程 出口 押匯 轉賬 (Domain) 世 華銀行 外 匯業(yè)務 出口 托收 軟件工程 66 Scenario 敘述 客戶 世 華總管理處 焦點 : 世 華 內部 國外銀行 中央 銀行 看 單 人員 結賬人員 柜臺人員 出口 托 收 軟件工程 67 67 Viewpoints 關于需求的基本觀點 軟件工程 68 68 關于需求的基本觀點 ? 需求工程活動不總是順序進行 ? 問題描述不總是先于解決方案描述 ? 在系統(tǒng)開發(fā)的任何階段描述問題均是有益的 ? 需求工程是在各開發(fā)階段持續(xù)進行的一系列活動 ? 問題陳述無法追求完美 ? 需求模型是對世界的近似表示 ? 將包括不精確和不一致性 ? 會省略某些信息 ? 細致的分析將降低導致嚴重問題的風險 ? … 但風險永不可能降解為零 軟件工程 69 69 關于需求的基本觀點 ? 追求規(guī)約的描述會降低性價比 ? 需求分析是有開銷的 ? 不同的項目，性價比的平衡點是不同的 ? 問題描述永不可能是固定的 ? 變化是無法避免的，因此應納入計劃之中 ? 對變化的處理應定期進行 軟件工程 70 不適當的需求引起的一些風險 1. 無足夠用戶參與 – 用戶參與不多會導致產品無法被接受 2. 用戶需求的不斷增加 – 用戶需求的增加帶來過度的耗費和產品質量的降低 3. 模棱兩可的需求說明 – 將導致時間的浪費和返工 4. 不必要的特性 – 用戶增加一些不必要的特性和開發(fā)人員畫蛇添足 5. 過分精簡的規(guī)格說明 – 過分簡略的需求說明以致遺漏某些關鍵需求 6. 忽略用戶分類 – 忽略某類用戶的需求將導致眾多客戶的不滿 7. 不準確的計劃 – 不完善的需求說明使得項目計劃和跟蹤無法準確進行 軟件工程 71 不適當的需求引起的一些風險 1. 無足夠用戶參與 客戶經常不明白為什么收集需求和確保需求質量需花費那么多工夫，開發(fā)人員可能也不重視用戶的參與。盡管原因是多方面的，盡早讓具有代表性的用戶參與是可以避免一定的風險的 軟件工程 72 不適當的需求引起的一些風險 2. 用戶需求的不斷增加 在開發(fā)過程中，若不斷地補充需求，項目就會越來越大直到超出計劃和預算范圍。 如果變更發(fā)生在設計編碼以后，這樣的變更會使軟件結構日漸紊亂，補丁代碼使模塊違背強內聚、低耦合的設計原則，使程序越來越難以理解和維護。 軟件工程 73 不適當的需求引起的一些風險 3. 模棱兩可的需求說明 模棱兩可，也就是需求的 “ 二義性 ” ，是需求說明中最可怕的問題。 模棱兩可的需求直接的后果就是返工。 認真、高質量的需求評審可以消除大部分的模棱兩可型的錯誤。相反的情況也存在，即客戶會提出這些花哨的但缺乏實用價值的需求，需求分析人員應做的是去說服客戶避免將資源浪費在這些無關緊要的功能上。 軟件工程 75 不適當的需求引起的一些風險 5. 過分精簡的規(guī)格說明 有時客戶并不明白需求分析如此重要，于是只作一份簡略之至的規(guī)格說明。大多數情況下，這會增加開發(fā)過程的迂回、返工。如果產品功能設計不能滿足某些關鍵用戶需求，會大大影響產品的用戶接受度。 軟件工程 78 ? 軟件需求工程 需要執(zhí)行的活動 包括： 1) 確定目標系統(tǒng)將要面對的 各類用戶 ； 2) 從各類用戶的代表那里 收集需求 ； 3) 將頂層的 需求分配 到軟件系統(tǒng)構架內定義好的軟件成分中； 4) 協商需求的實現 優(yōu)先級 ； 5) 書面化 ； 6) 審閱 需求文檔，以確保在認識上與用戶需求相一致。 軟件工程 79 3. 可能的需求的來源 ? 軟件需求的來源取決于目標系統(tǒng)的性質和開發(fā)環(huán)境。 Steve Easterbrook, 2022) ? 如何 獲取 需求信息？ ?核心技術： ? 座談，問卷，代表會議 ? 采用人種學（ Ethnographic）方法（社交嵌入系統(tǒng)） ? 采用原型法，或參與設計法（缺乏了解的系統(tǒng)） 軟件工程 81 ? 根據所受限制不同，不同類型的應用系統(tǒng)能夠從用戶那里獲取需求的比例也不同。 相對低的 相對高的 從人群獲取需求的大概百分比 應用的類型 高度受限的 不受限制的 導彈制導系統(tǒng) 航班控制系統(tǒng) 公司財務系統(tǒng)增強版 制造控制系統(tǒng) 公司財務系統(tǒng) 視頻游戲 軍事戰(zhàn)略決策支持系統(tǒng) 軟件工程 82 ? 如導彈制導系統(tǒng)更多地受物理運動定律的限制，而非人的決策。 ? 應用受到的限制越少，能從人們那里獲得的需求比例越大。 ? 商定誰是項目需求的 決策者 。 ? 不同用戶類的需求甚至可能發(fā)生 沖突 ，導致需求不一致。 ? 分析員 必須 在項目初期便確定產品有哪些不同的用戶類，并描述它們的特點，這樣就能從每個重要用戶類的代表那里獲取用戶需求。 軟件工程 84 描述用戶需求 ? 需求可以看成是應用與外部用戶之間的交互。 ? 描述客戶需求的過程如下： 1) 標識參與者 標識目標系統(tǒng)將支持的不同類型的用戶，可以是人、事件或其他系統(tǒng)。 軟件工程 85 3) 標識用例 當雙方確定了一組場景后，開發(fā)人員從該場景抽象出一組用例，描述所有可能的情況。 4) 求精用例 細化每一個用例。 5) 標識用例之間的關系 描述用例之間的依賴關系，提取相同功能，建立用例模型。 軟件工程 86 出口 托收導出 的 系 統(tǒng) 流程 看單人員 國外銀行 收件 審單 解款 呈 報 結賬人員 柜臺 人 員 世華總管理處 UML 的 Use Case 圖 軟件工程 87 草擬用戶界面和其他接口 ? 建立初始用戶界面，是原型方法的一種，目的是快速與客戶溝通。 軟件工程 88 軟件工程 89 分析建模 ? 常用的分析方法 ? 面向數據流的結構化分析方法 (SA) ? 面向數據結構的 Jackson方法 (JSD) ? 面向數據結構的結構化數據系統(tǒng)開發(fā)方法 (DSSD) ? 面向對象的分析方法 (OOA) 等 軟件工程 90 ? 結構化分析方法最初只是著眼于數據流。 結構化分析方法 軟件工程 91 結構化分析的分析模型 實體 — 關系圖 狀態(tài) —遷移圖 數據流圖 數據對象描述 加工規(guī)格說明 數據 字典 控制規(guī)格說明 軟件工程 92 數據建模 ? 數據模型包括三種互相關聯的信息：數據對象，描述對象的屬性，描述對象間相互連接的關系。 ? 例如，在教學管理中，一個教師可以教授零門、一門或多門課程，每位學生也需要學習幾門課程。 軟件工程 93 教學數據模型 學號 姓名 專業(yè) 性別 …… 學生 職工號 姓名 專業(yè) 職稱 年齡 教師 課程號 課程名 學分 學時 …… 課程 學號 課程號 成績 選課 軟件工程 94 X Y 一個 X與一個 Y相關聯 一個 X與一個或多個 Y相關聯 X Y 一個 X與零個或一個 Y相關聯 X Y 一個 X與零個 , 一個或多個 Y相關聯 X Y 一個 X與一個 Y或 Z相關聯 X Y Z 一個 X與一個 Y與 Z相關聯 X Y Z 軟件工程 95 功能建模和數據流 ? 最初 ,結構化分