需求工程第一章

軟體的模擬特性 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. 控制變更