需求工程期末知識點複習

需求工程第一章

軟件的模擬特性 P6

軟件的模擬特性來源於其知識載體的特性：軟件在運行中表現出來的特性、行爲應該和應用的現實情況保持一致，即軟件“模擬”了現實。
“模擬性”具體指：

1. 目的性
2. 正確性
3. 現實可理解性

需求工程基本活動 P12

需求工程包括需求開發和需求管理
需求開發包括需求獲取、需求分析需求規格說明和需求驗證
需求獲取：從項目的戰略規劃開始建立最初的原始需求
需求分析：保證需求的完整性和一致性
需求規格說明：將完整、一致的需求與能夠滿足需求的軟件行爲已文檔的方式明確的固定下來
需求驗證：保證需求及其文檔的正確性，通過檢查和修正，保證需求及其文檔的完整性和一致性
需求管理：對需求開發所建立的需求基線的管理

需求工程的複雜性 P16

1. 處理範圍廣泛：連接現實世界和計算機世界
2. 涉及諸多參與方：客戶、用戶、領域專家、需求工程師、軟件開發者和系統維護者
3. 處理內容多樣：用戶的功能需求和非功能需求，軟件所處的環境及其約束
4. 處理活動互相交織：需求開發的各項活動雖然在理論上具有順序處理的特性，但在實際執行過程中往往是迭代和互相交織的
5. 處理結果要求嚴苛：正確性、完整性和一致性

需求工程師需要具備的技能 P18

• 軟件技術
• 認識學和社會學等方面的知識
• 哲學知識
• 專業技能
• 分析技能

需求工程師需要重視的軟技能 P18

1. 交流技能：交談和提問的技巧，傾聽的技巧
2. 觀察技能觀察用戶的工作環境和工作過程，觀察得出用戶的真實的感受和情感反饋
3. 抽象分析與問題解決技能：抽象能力，整合全局的能力，系統化思想
4. 寫作技能：文檔組織能力，語言駕馭能力
5. 關係協調和團隊工作技能：促成相關方的有效協商，以最終達成一個合理的解決方案

需求工程第二章

模擬與共享現象 P26

軟件系統能夠與問題域進行交互和相互影響的原因在於，軟件系統中的某些部分對問題域中的某些部分具有模擬特性
共享現象就是解系統所模擬的問題域部分，該部分在兩個系統中同時存在

需求問題都有層次性 P28

1. 業務需求 戰略問題
2. 用戶需求 任務問題
3. 系統級需求 系統行爲問題
   業務需求具有明顯的目的性和較高的抽象性
   用戶需求經過明確和細化的處理，可以轉化爲系統及需求
   用戶可以直接將系統及需求映射爲系統行爲
   
   
   

優秀需求的特性 P44

1. 完備性：是否描述了開發人員設計和實現這項功能所需的所有信息
2. 正確性：真實反映用戶的意圖
3. 可行性：需求必須能夠在系統及其運行環境的已知條件和約束下實現
4. 必要性：滿足用戶的業務需求所必需的
5. 無歧義：每一項需求都應該有而且只能有一種解釋
6. 可驗證：通過分析、檢查、模糊或測試等方法能夠判斷需求是否被滿足

需求工程第三章

需求獲取的主要任務 P54

1. 收集背景資料：先收集系統的背景資料以形成一個基礎的知識框架，如需深入，就需要應用相關的需求分析方法（如領域分析等）對收集的資料進行整合與處理
2. 獲取問題與目標，定義項目前景與範圍：瞭解用戶的需要、期望和關注點，推定用戶在業務中所遇到的高層次問題，確定軟件產品未來的形式，定義項目的前景
3. 識別涉衆，選擇信息的來源：將用戶分成不同的類型，在理解每種類型用戶特徵的情況下爲其選擇合適的用戶代表
4. 選擇獲取方法，執行獲取，獲取功能與非功能需求：獲取用戶需求，瞭解用戶在完成任務時遇到的問題與期望
5. 記錄獲取結果：記錄業務需求、項目前景和範圍、用戶需求以及問題與特性

需求工程第四章

需求獲取中的常見困難 P75

• 用戶和開發人員的背景不同，立場不同

1. 知識理解的困難
2. 默認知識現象

• 普通用戶缺乏概括性、綜合性的表述能力
• 用戶存在認知困境
• 用戶越俎代庖

1. 用戶提出的不是需求，而是解決方案
2. 用戶固執的堅持某些特徵和功能

• 缺乏用戶參與

1. 用戶數量太多，選擇困難
2. 用戶認識不足，不願參與
3. 用戶情緒抵制，消極參與
4. 沒有明確的用戶

需求獲取活動 P79

• 獲取活動主要步驟

1. 研究應用背景，建立初始的知識框架
2. 根據獲取的需要，採用必要的獲取方法和知識
3. 先行確定獲取的內容和主題，設定場景
4. 分析用戶的高（深）層目標，理解用戶的意圖
5. 進行涉衆分析，針對涉衆的特點開展工作

• 實質步驟

1. 確定待獲取信息的內容
2. 確定待獲取信息的來源
3. 確定採用的獲取方法
4. 執行獲取
5. 記錄成果

獲取信息的內容 P80

1. 需求：涉衆的問題、期望、觀點、看法和態度
2. 問題域描述：承載和解釋需求的問題域特性，主要是現實世界的業務運行狀況
3. 環境與約束：屬於一種特殊的問題域特性

獲取信息的來源 P81

1. 涉衆
2. 硬數據
3. 相關產品
4. 重要文檔
5. 相關技術標準和法規

獲取信息的方法 P81

1. 傳統方法：問卷調查、面談、文檔分析、文檔檢查、需求剝離
2. 集體獲取方法：頭腦風暴、專題討論會、JAD、JRP
3. 原型：在需求模糊和不確定性較大的情況下，原型方法尤其有效
4. 模型驅動方法：定義明確的模型，模型的定義方式確定了所要收集的信息類型，模型建立和完善的過程就是需求獲取的過程
5. 認知方法：已認知的方式獲取用戶無法表達的潛在知識，任務分析，協議分析
6. 基於上下文的方法：用戶在一定環境下表現出來的行爲，通過分析用戶的行爲得到信息

需求工程第五章

問題分析 P96

1. 獲取問題：收集背景資料或涉衆溝通
2. 明確問題：
   2.1對問題達成共識
   2.2收集背景資料，判斷問題的明確性
   2.3分析不明確問題，發現問題背後的問題
   
   
   
3. 發現業務需求：確定每一個問題對應目標的過程
4. 定義問題解決方案及系統特性：
   4.1建立問題解決方案
   4.2確定系統特性和解決方案的邊界
   4.3確定解決方案的約束
   
   
   

目標分析過程 P113

1. 高層目標的獲取：將識別出來的目標、系統特性等組織爲相互聯繫的目標模型
2. 目標精化：
   2.1獲取對高層目標的描述
   2.2從高層目標描述中發現AND精化關係
   2.3從高層目標描述中發現“候選方法”，發現OR精化關係
   2.4考慮阻礙目標實現的情況
   2.5發現目標衝突關係
   2.6對高層目標問“How”，對底層目標問“Why”，完善層次結構
   
   
   
   
   
   
3. 目標實現：將最底層的目標分配給主題，設計實現最底層目標的操作（任務）

需求工程第六章

信息系統

1. 小型系統：能夠支持組織的部分工作，但又不會影響整個組織基礎工作的信息系統
2. 組織級系統：其功能能夠影響整個組織基礎工作的系統，它的功能在質量上和小型系統有着明顯的差異
3. 戰略信息系統：作爲組織戰略決策而得以開發的系統
4. 組織間系統：通過系統自身的實施來建立或增強組織之間的合作關係

涉衆分析的過程 P147

1. 涉衆識別：尋找軟件系統的涉衆類別
2. 涉衆描述：
   2.1描述不同涉衆類別的簡單特徵，包括個人特徵和工作特徵
   2.2描述不同涉衆類別的複雜特徵，包括關注點和興趣取向、重要性和影響力，輸贏條件和受影響程度
   
   
3. 涉衆評估：
   3.1爲涉衆類別劃分優先級
   3.2評估不同涉衆類別的風險，化解風險
   3.3分析涉衆衝突，實現共贏
   
   
   
4. 涉衆代表選擇：從每種涉衆類別中選擇代表
5. 指定涉衆代表參與需求開發乃至軟件系統的參與策略

識別涉衆的方法P150

1. 先膨脹後收縮的方法
   1.1 膨脹：收集到背景資料後，憑藉自己的經驗，儘可能多的列出涉衆類別
   1.2 收縮：判斷是否有兩類或多類涉衆的立場是一樣的，將一樣的多個類別進行合併
   
   
2. 檢查列表方法：
   常見的涉衆類別：
   2.1 用戶：最終使用和操作產品的人
   2.2 客戶：爲軟件系統開發付費的人
   2.3 開發者：負責實現軟件系統的人
   2.4 管理者：參與軟件系統開發事務管理的人
   2.5 領域專家：在問題域中具有豐富知識的專家
   2.6 政府力量
   2.7 市場力量：組織中的市場部門人員
   2.8 維護人員：系統管理員
   
   
   
   
   
   
   
   
   
3. 涉衆網絡方法：
   3.1 尋找最容易識別的初始涉衆
   3.2 將初始涉衆集中起來，進行一次頭腦風暴，儘可能列出一個涉衆類別列表
   3.3 對涉衆類別列表進行分析，判斷他們和軟件系統的相關性，找出其中的關鍵涉衆類別
   3.4 爲各個涉衆類別選擇代表，集中起來進行進一步的頭腦風暴，列出新的涉衆類別列表
   
   
   
   

涉衆評估 P156

1. 優先級評估：要優先考慮涉衆的基本特徵，尤其是任務特徵
2. 風險評估：分析涉衆的態度，涉衆的關注點和興趣取向。化解風險：提高環境設定者對系統的關注，將他們轉變爲參與者；消除強反對者的反對原因，將他們變爲強支持者；給予被影響者一些充分發表和實現自身意見的權力，化解弱反對者的憂患
3. 共贏分析：爲了保證軟件系統的最終成功，應該儘可能地解決這些衝突，而且最好是在衝突發生之前能夠消除

涉衆代表採樣 P160

1. 涉衆採樣：
   1.1完整採樣
   1.2態度積極
   1.3數量適中
   1.4比例恰當
   
   
   
   
2. 用戶替代源：
   2.1擁有類似系統經驗的系統分析人員
   2.2與用戶直接聯繫的技術支持人員
   2.3服務諮詢人員
   2.4內部或者外部的顧問，通常是指領域專家
   2.5用戶方的管理者
   2.6市場人員
   2.7擁有相關知識的開發人員
   如果能找到真正的涉衆代表，就不要使用替代源，因爲替代源的效果比真實涉衆代表要差得多
   
   
   
   
   
   
   
   

硬數據 P166

1. 定量硬數據：經過仔細設計、具有嚴格貴伐要求的格式化文檔
   1.1數據收集表格
   1.2統計報表
   
   
2. 定性硬數據：使用自然語言進行的文本描述
   2.1整個組織的描述文檔
   2.2業務指導文檔
   2.3業務備忘
   
   
   

需求工程第八章

準備面談 P198

準備工作

1. 閱讀背景資料
2. 確定面談主題和目標
3. 選擇被會見者
4. 通知被會見者做準備
5. 確定問題和類型

問題類型

1. 兩種基本問題類型
   1.1 開放式問題：被會見者對答覆的選擇可以是開放的和不受限制的
   優點：感到自在；可以收集被會見者的詞彙，這反映他的教育、價值標準、態度和信念；提供豐富細節
   缺點：產生很多不相干的細節，面談可能失控；花費大量時間獲得有用的信息
   1.2 封閉式問題：對答案有基本的形式，被會見者的回答是受到限制的
   優點：節省時間；切中要點；保持控制；快速討論大範圍問題；得到貼切的數據
   缺點：使被會見者厭煩；得不到豐富細節；失去主要思想；不能建立友好關係
   
   
   
   
   
   
2. 程序性提示：避免面談過程中的一些認知問題
   1.1 總結與反饋
   1.2 重複和改述
   1.3 建立場景和細節
   1.4 抗辯
   
   
   
   
3. 其他重要的問題類型
   3.1 探究式問題
   3.2 誘導性問題
   3.3 雙筒問題
   3.4 元問題
   
   
   
   

問題準備

1. 保證面談能達成目標，就應該有所準備
2. 高效利用時間，麪攤前就要花費更多的時間進行準備
3. 事先準備好面談的主題與線索
4. 讓會見者更好集中精力主導面談過程

主持面談 P204

面談開始階段

1. 握手
2. 概要說明會談的原因
3. 準備好筆記本、錄音機或其他記錄設備
4. 開始時採用一些非常一般的、輕鬆的、開放式的問題

面談主體階段

1. 保持有禮貌的傾聽
2. 控制面談過程
3. 保持面談主題
4. 使用探究式問題
5. 觀察被會見者
6. 使用道具支持

面談結束階段

1. 45~60分鐘結束
2. 總結面談的要點
3. 感謝被會見者，並且給他們時間讓他們詢問自己關心的問題
4. 握手告別

記錄面談

1. 記錄的內容
   1.1 事實和問題
   1.2 被會見者的觀點
   1.3 被會見者的感受
   1.4 組織和個人的目標
   
   
   
   
2. 記錄的方式
   2.1 筆錄：
   優點：使會見者專心和集中精力；幫助回憶重要的問題；表現會見者對面談的興趣；表明會見者是有準備的
   缺點：丟失語調、停頓等語音信息；做筆記時，會讓會見者說話猶豫；對事實注意過多，對感覺及觀點注意過少
   2.2 錄音和攝像
   優點：記錄了更多信息；會見者能輕鬆傾聽並快速響應；完整重現面試過程
   缺點：被會見者可能緊張；數據採集代價極高；信息尋找難以定位
   
   
   
   
   
   

整理面談報告 P207

1. 複查面談報告
2. 總結面談信息：評估面談中所得到的信息
3. 完成面談報告：
   3.1 參與者、時間和地點
   3.2 會見者對被會見者的印象
   3.3 面談中發現的觀點和要點
   3.4 會見者對面談的基本評價
   
   
   
   

面談的類別 P208

1. 結構化面談：會見者會完全按照事先的問題和結構來控制面談
2. 半結構化面談：實現需要根據面談內容準備面談的問題和麪談結構，但在面談過程中會見者可以根據實際情況採取一些靈活的策略
3. 非結構化面談：沒有事先預定的議程安排

面談的優點和侷限性 P209

優點：

1. 條件簡單，經濟成本低
2. 能獲得包括事實、問題、被會見者觀點和被會見者信仰等各種信息類型在內的廣泛內容
3. 可以和涉衆建立友好關係
4. 被會見者會產生一種主動爲項目做出貢獻的感覺，提高涉衆的項目參與熱情

缺點：

1. 耗時，時間成本高
2. 在被會見者地理分散的情況下難以實現
3. 面談參與者的記憶和交流能力對結果影響較大，面談的成功很大程度上依賴於需求工程師的人際交流能力
4. 交談過程中的各種問題容易導致錯誤數據
5. 在會見者不瞭解被會見者的認知結構的情況下，面談不會令人滿意

羣體面談 P210

概述

羣體面談的方法就是將所有的涉衆代表集中起來，選擇一個合適的地點，集中一段時間，召開一個多方共同參與的會議，一起進行需求的討論、分析和獲取
優點：

1. 節約時間，時間成本低
2. 在一個集中連續的時間內完成，能夠加速項目的開發進度
3. 涉衆之間可以直接交流，提高了衝突的處理能力和處理效率
4. 提高涉衆的項目參與度
5. 常常會有創造性的信息內容出現

缺點：

1. 要求所有參與方都要在一個集中的時間內抽出大量的時間和精力，難以實現
2. 羣體面談獲得的信息難以分析
3. 主持羣體面談更加複雜

計劃面談

• 確定參與人員：

1. 涉衆
2. 主持人
3. 負責人
4. 分析人員
5. 記錄人員
6. 觀察員

• 安排面談時間

1. 2~4天全職參與面談
2. 擬定一份議程

• 選擇面談地點

1. 充足的空間
2. 道具支持
3. 良好的餐飲服務

• 準備面談內容：

1. 確定面談的主題和範圍
2. 確定面談的議程
3. 建立需求的預期和麪談的目標
4. 提前準備各種材料

主持面談

1. 建立基本規則
   1.1 按時開始和結束
   1.2 中途休息後儘快進入狀態
   1.3 一次只討論一個主題
   1.4 期望每個人都做出貢獻
   1.5 關注問題，不人身攻擊
   1.6 限制發言時間
   
   
   
   
   
   
2. 保持面談氣氛
3. 確保每個人都積極地參與討論
4. 控制面談的主題

分析結果

記錄員要完整記錄下會談的內容
記錄員需要和參與的技術人員一起對記錄內容進行整理
整理的工作：

1. 按照主題組織參與者的討論
2. 建立粗略的模型，分析每個主題已經獲得信息內容
3. 指明下一步的努力方向

和麪談相關的其他需求獲取方法 P213

調查問卷

格式設計：

1. 提供足夠的空白空間
2. 提供足夠的答覆空間
3. 要求回答者清楚地標出他們的答覆
4. 使用目標幫助確定格式
5. 保持風格一致

頭腦風暴

鼓勵參與者在無約束的環境下進行某些問題的自由思考和自由討論，以產生新的想法

• 需要採用的典型情況

1. 發明並描述以前不存在的全新的業務功能
2. 明確模糊的業務
3. 在信息不充分的情況下做出決策

• 頭腦風暴的兩個決策

1. 想法產生階段：產生出儘可能多的新想法
   頭腦風暴的基本規則：
   1.1 充分發揮想象力，不要有羈絆
   1.2 產生儘可能多的想法，想法重在數量不是質量，不要顧及想法是否荒誕
   1.3 自由討論，目的是產生新的想法，不要爭吵和批評
   1.4 在自由討論中，可以轉換和組合所有已提出的想法，以產生新的想法
   
   
   
   
   
2. 想法精簡階段：
   2.1 去除那些不值得進一步討論的想法
   2.2 把類似意見歸類
   2.3 主持人遍歷每一個未被刪除的想法，確保所有參與者都對其有共同的理解，利用投票或類似方法，評估先有想法的優先級
   2.4 根據評估的數據，從中篩選符合一定標準的想法作爲頭腦風暴方法的成功
   
   
   
   

需求工程第九章

原型及原型法

• 如果在最終的製品產生之前，一箇中間製品被用來在一定廣度和深度範圍內表現這個最終制品，那麼這個中間製品就被認爲是最終制品在該廣度和深度上的原型
• 原型通常僅僅是真實系統的一個部分或一個模型，重要的不在於使用什麼材料和工具來創建他們，而是人們怎麼利用他們來探索和論證未來物件的某個方面
• 原型系統通常被構造爲不完整的系統，以在將來進行改進、補充或者替代
• 包括書面描繪、場景敘述、故事板、幻燈演示、動畫模擬、屏幕快照和程序代碼等在內的各種被用來探索和論證軟件系統功能的物件都是軟件的原型
• 在系統開發中利用這些原型的行爲都屬於原型法

使用原型法進行需求獲取

基本過程

1. 確定原型需求
2. 原型開發
3. 原型評估
4. 原型修正

確定原型需求

如果發現產品的需求存在不確定性，就可以考慮使用原型法

1. 可能發生的需求變更
2. 存在衝突的地方
3. 信息不充分：
   3.1 產品的部分需求從前從未存在過，而且難以可視化
   3.2 產品的涉衆對相關的產品功能沒有經驗，而且對將要採用的技術也沒有經驗
   3.3 涉衆進行自己的工作已經有一段時間了，但在完成工作的方式上仍然存在障礙
   3.4 涉衆在清晰說明某些需求方面存在困難，如默認需求或者潛在需求
   3.5 需求工程師在理解涉衆的部分需求上存在困難
   3.6 部分需求的可行性值得懷疑，即具體需求的可滿足性存在着不確定性
   
   
   
   
   
   

原型開發

注意事項：

1. 將探索不確定功能需求的原型構建得易於修改
2. 讓探索可行性的原型收集充分的數據
3. 控制開發成本

原型評估

1. 使用腳本指導評估過程
2. 創造無偏見的評估環境
3. 引導評估者從恰當的角度進行評價
4. 觀察評估者的行爲
5. 手機評估者的反饋

原型修正

1. 讓用戶能夠較早感受到系統功能並及時提出反饋
2. 根據評估者的反饋迅速調整錯誤的或不完善的想法，並在連續的反饋和調整之中逐步接近正確的和完善的需求

需求工程第十章

觀察 P234

概述

常見的觀察方法：

1. 採樣觀察
2. 民族誌
3. 話語分析
4. 協議分析
5. 任務分析

情境性的重要性質

1. 突現：集體促成，互動的基礎上突顯的
2. 局部：特定的上下文環境
3. 暫時：依賴於當時的情況
4. 涉身：參與者具有一定的認知和能力
5. 開放：對事件的解釋必須保持開放，以在得到進一步的分析之後可以進行進一步完善
6. 模糊：基於一些當然的潛在知識

需要應用觀察方法解決的問題

1. 理解複雜的協同事件：突顯 民族誌
2. 獲取工作中的異常處理：局部 採樣，民族誌
3. 獲取與用戶認知不一致的實際知識：暫時 採樣，民族誌
4. 瞭解用戶的認知：涉身 民族誌，話語分析法
5. 獲取默認知識：模糊 採樣觀察，協議分析，民族誌

採樣觀察

1. 時間採樣：允許需求工程師建立指定的時間間隔來觀察用戶的活動情況
2. 事件採樣：通過有目的的選取整個時間進行觀察，而不是隨機採樣時間段

民族誌

• 優點：

1. 深度理解信息
2. 能夠讓真實世界的社會因素可見化
3. 打破人們已有的一些錯誤假設觀念

• 缺點：

1. 耗費很長時間
2. 調研結果很難傳遞到開發過程

• 針對複雜協同問題的民族誌

1. 分佈式協同：注意那些利用物件實現的協同和創建這些物件的文書工作
2. 計劃和程序：關注他們在組織活動中的應用方式，發現實際工作和文檔化程序之間存在的偏離
3. 工作的意識：活動可以對協同中的其他人可見或可理解

• 使用普通民族誌的規則

1. 定期記錄他們的發現
2. 儘快記錄可能會在觀察工作中發生的面談
3. 定期複查和更新自己的想法
4. 確定該問題的應對策略

文檔審查 P242

1. 需求方法：相關產品的需求規格說明
2. 文檔分析：硬數據
3. 需求剝離：客戶的需求文檔

需求工程第十六章

需求驗證的方法 P418

需求評審

由作者之外的其他人來檢查產品問題，主要的靜態分析手段，每一條需求都應該進行評審

• 參與評審的人員

1. 組織者
2. 仲裁者
3. 作者
4. 閱讀人員
5. 記錄人員
6. 收集人員
7. 評審人員（領域專家+用戶代表）
8. 技術人員
9. 觀察員

• 評審過程

1. 規劃
2. 總體部署
3. 準備
4. 評審會議
5. 返工
6. 跟蹤

• 評審的檢查方法

1. 自由方法
2. 檢查清單
3. 缺陷
4. 功能點
5. 視角
6. 場景
7. 逐步提升

• 評審的類型

1. 審查
2. 小組評審
3. 走查
4. 輪查
5. 臨時評審

原型與模擬

需求涉及複雜的動態行爲時
成本較高

開發測試用例

如果無法爲某條需求定義完備的測試用例，那麼它可能就存在着模糊、信息遺漏、不正確等缺陷

用戶手冊

1. 對軟件系統功能和實現的描述：幫助進行功能需求的驗證
2. 系統沒有實現的功能部分：幫助進行項目範圍的驗證
3. 問題和故障的解決：幫助進行異常流程需求的驗證
4. 系統的安裝和啓動：幫助進行環境與約束需求的驗證

利用跟蹤關係

1. 業務需求（系統特性）
2. 用戶需求（業務、任務）
3. 系統級需求（分析模型）

問題的修正 P425

1. 需求澄清：
   1.1 已經獲得需求信息，理解當中出現偏差：需求工程師重新進行分析工作
   1.2 已經獲得需求信息，沒有被納入需求分析或者文檔化工作：重新分析和文檔化這部分信息
   1.3 使用了不恰當的表達方式：重新以合適的方式修改對需求的表達
   
   
   
2. 發現需求缺失：
3. 解決需求衝突
4. 修正不切實際的期望

需求工程第十七章

需求管理的作用 P431

1. 增強了項目涉衆對複雜產品特徵在細節和相互依賴關係的理解
2. 增進了項目涉衆之間的交流
3. 減少了工作量的浪費，提高了生產力
4. 準確反映項目的狀態，幫助進行更好的項目決策
5. 改變項目文化，是需求的作用得到重視和有效發揮

需求管理的活動 P432

1. 維護需求基線
2. 實現需求跟蹤
3. 控制變更