1. 需求發展
   1. 需求彙整最困難的部分，在於如何將user想要的系統，轉成user需要的系統
   2. 需求彙整與規格化的動作，是不斷重複的，直到對user需求達到一個清晰穩定的瞭解
2. User
   1. Not only people
   2. 會影響或被影響的人事物，皆為User
3. 彙整與管理使用者需求
   1. 將需求訪談轉成結構化應用面需求
   2. 需求條列、分類
      1. 功能性
      2. 非功能性
      3. 介面requirement
      4. 效能需求
         1. rule
         2. 例外情形
   3. 對每一項需求編號
      1. 方便溝通
      2. 方便追蹤
   4. 文件產出(基本上以CMMI為主)
      1. 會議記錄
      2. 客戶提供資料記錄表
      3. 現行作業流程圖
      4. 需求彙整清單與glossary
      5. 系統軟體、硬體與網路架構
      6. 資料量分析表
         1. 若不需要PM可裁適
      7. 需求追溯表(RTM)
      8. 系統需求規格書
4. 需求確認
   1. 取得專案成員認同(內部成員，如SA、PM)
   2. 取得user認同
      1. 彙整報告會議
      2. 審查會議
   3. 交付需求分析文件
      1. 文件審查
      2. User簽名
5. Models
   1. 三個面向
      1. Level
         1. Scope level
            1. Scope
         2. High level
            1. Conceptual(brief description)
         3. Low level
            1. Detail description
      2. Focus
         1. who
            1. 影響與被影響的actor
         2. what
            1. 流程、規範等
         3. when
            1. 何時使用、使用的頻率與時間分佈
         4. where
            1. 網路與實體機器位置等
         5. why
            1. 為何需要，有什麼樣的問題需要被解決
         6. how
            1. 如何滿足需求
      3. View
         1. Behavior
            1. Use Case Diagram
            2. Flow chart
         2. Struture
            1. Data model
            2. Class Diagram
         3. Dynamic
            1. Statechart Diagram
            2. Event table
         4. Control
            1. 作業規範
            2. business policy
   2. 常用的model與適用時機
      1. What do we means
         1. Glossary
      2. Who's affected by the project?Who affects it
         1. Stakeholder Classes
            1. 關鍵人員
            2. 外部界接系統也可能是關鍵人員之一
      3. Who does it
         1. Actor table
         2. Actor map
      4. What must be true?What policies do we have?
         1. Business Policies
         2. Business Rule
         3. Decision Table
         4. Decision Tree
      5. When will it happen?What will result?
         1. Event table
            1. What does need to do?
            2. Event-driven system
      6. Who or what parts of organization are involved?
         1. Relationship Map
      7. What data is needed?
         1. Domain Model
            1. High level
            2. 將現實世界問題，使用圖解方式表達Conceptual class or object
            3. What information action need?
      8. When will the data change?
         1. Statechart Diagram
            1. 例如Insert、Edit狀態改變
      9. What processes will go on?In what sequence will things done?
         1. Process Map
            1. Flow chart
         2. Use cases
            1. 描述Actor與系統內功能的關聯
            2. 定時或批次處理的驅動actor
            3. timer
         3. Use Case Map (Activity diagram)
      10. What are dependencies among use cases?
          1. Use Case Packages
      11. What are examples of what will happen?
          1. Scenarios
      12. What will the system look like?
          1. User Interface Navigation Diagram
             1. 類似以UI為eneity的flow chart
          2. Prototype
6. SA的責任
   1. 引導(Elicitation)
      1. 可透過一連串的問答來引導user，找到user真的想要與需要的系統
   2. Analysis
      1. 找到消失的需求(missing requirement)
         1. 例如透過CRUDL matrix找出消失的操作
            1. 五種權限
            2. Create
            3. Read
            4. Update
            5. Delete
            6. List
            7. 二維matrix
            8. X: entity
            9. Y: use cases
   3. Specifation
      1. 將需求轉換成規格文件及model
   4. Validation
      1. 確認需求
7. You Should Know
   1. 需求發展程序
      1. 研讀專案計畫
         1. 瞭解專案目標
         2. Scope
         3. Key user參與計畫
            1. 關鍵人員參與溝通計畫
      2. 蒐集與瞭解使用者需求
         1. 蒐集的方法
         2. 可參考哪些data
         3. 如何瞭解user requirement
      3. 彙整跟管理使用者需求
      4. 需求與確認(V & V)
   2. 需求彙整與瞭解的方法
      1. 文獻調查
         1. RPP、proposal、工作說明書
         2. 專案計畫書，瞭解目標跟Scope
         3. 客戶組織有哪些user會使用此系統
         4. 客戶現行文件、報表
         5. domain knowledge
      2. 訪談會議
         1. PM擬定訪談計畫
         2. 瞭解現行作業流程與問題點
         3. 瞭解user requirement
         4. 對未來系統的需求與期望(共識)
         5. 未來系統的限制條件
      3. 導引
         1. 配合訪談會議
         2. 預先構思Scenario
         3. Prototype展示，啟發user requirement
            1. Axure
      4. 問卷調查
         1. 跨部門或跨組織可使用
      5. 實地調查
         1. 特定情境需實地訪查的系統
      6. 實習
         1. 先行瞭解作業(實際上比較少見)
   3. 需求發展應避免
      1. User涉入不足
      2. 四處蔓延的需求
      3. 語意不清的敘述
         1. 盡量
         2. 盡快
         3. 彈性
         4. 什麼什麼等....
      4. 鍍金
         1. 無謂的功能
         2. 花俏的UI
      5. Minimal specfication
         1. 應描述更詳盡，break down到更細的思考，才能避免遺漏需求或誤解需求
      6. 隨便給user承諾
      7. 忽略了User Class
   4. 為什麼需要Models
      1. 為了溝通
         1. 用簡單明瞭的方式，讓對方瞭解你要表達什麼
      2. 根據需要呈現不同的情況或要表達的重點，選擇適合的model來溝通
   5. 各種model適用時機與簡單描繪
      1. Process map diagram
      2. Statechart diagram
      3. Relationship map diagram