需求調查
需求指引
工作：
- 瞭解問題
- 實際狀況調查
- 評估可行性
- 系統規格書
3W1H
面談
問卷
結構：
- 說明函
- 問卷內容
- 填寫人基本資料
文件回顧
收集現有資料，寫一個對照表，我們系統能做什麼來改善現狀？
觀察 假如訂便當系統，要觀察現場的狀況，檢查標準作業程序和現場作業的每一步驟是否相符
研究
- 大型企業經由專家和顧問建立作業方式
- 小型企業必須聘請外部專家協助
技術可行性
- 新技術不夠成熟，無法解決企業問題
- 缺乏新技術的人才與能力，外面也不容易取得
- 新舊技術引發系統不相容
- 技術、價格與未來擴展性所引發的問題
- 技術預算不夠的問題
可行性研究
- 組織的可行性
- 技術的可行性
- 資源的可行性
- 時程的可行性
時程研究
影響時程的因素（人力、資金、技術⋯⋯ ）
- 加速發展會降低品質與提高成本與風險
- 延緩上線牽涉效益問題
- 考量規劃其他時程之方式
定義需求與撰寫規格書
工作步驟
- 發現需求
- 需求紀錄與分類
- 排定需求優先次序
系統規格書
使用者需求分為功能需求與非功能需求 稱為FURPS+
功能需求： 企業每天運作的流程，亦即系統所要完成的主要工作
非功能需求
- 可用性
- 可靠性
- 績效性
- 安全性
規格書須包含功能規格以及非功能規格
功能規格包含： 增刪改查等等等的
非功能規格包含： 資安等等等…
規格書格式
- 簡介：描述需解決問題、可能達成的企業目標
- 背景說明：說明企業原有問題
- 使用者需求：定義不同使用者的不同需求
- 環境說明：新系統所要面對的環境
- 系統架構：描述系統與子系統之架構、系統與硬體結合的關係
- 系統規格：功能規格與非功能規格
- 詞彙說明：專有名詞說明
- 附錄：收集的相關資料
之後要根據執行的結果，提出可行方案，與管理者確認、簡報。
系統分析活動與物件導向分析程序之關係
確認利害關係人
難處：系統發展初期，使用者通常是提出需求的部門主管，不會明確告知誰是這個系統的利害關係人
利害關係人目標表
把需求寫成目標
事件
在特定時間或地點發生，可以描述且值得記住的事情
- 外部事件：在系統外部發生的事
- 暫時事件：又稱內部事件，在指定時間發生的事
- 狀態事件：發生在系統內部引發系統必須處理的事
事件表中的使用案例
小考題目
今有某警政機關欲於某地區道路設立區間測速系統，以偵測行經道路 A點至B點之問的車輛。此系統將透過車牌辨識功能擷取車輛的車牌號碼（於A點及B點擷取行經車輛的車牌號碼），在確認車牌號碼的有效性之後（如失竊車輛、道路救險、消防救護等車輛，為特殊性質車輛，經過警政人員確認後，得不受區問限速之規定，因此車牌號碼將視為無效），可依據其A點至B點的道路距離以及行車時間，計算此車輛是否有發生超速之情形；而若有發生超速之情形，則可依據監理機關所頒佈之區間限速規定，給予一定金額之超速罰款（可依據超速情形調整罰款金額，超速愈多金額愈高）。此罰款將透過開立罰單並以郵寄方式通知車輛車主，以達到醫示作用，而警政人員以及車主亦可透過系統查詢罰單相關資訊。
- 利害關係人、目標
假設訪談了利害關係人，他的目標？
課程範例
事件：以系統的角度來思考
| 利害關係人 | 目標 | 事件 |
|---|---|---|
| 監理機關 | 知道他的法規、查車牌 | 提供超速規定（外部事件）、提供車籍資料（外部事件） |
| 警政人員 | 受惠於這套系統 | |
| 當地居民 | 受惠於這套系統 |
實作
| 利害關係人 | 目標 | 事件 |
|---|---|---|
| 監理機關 | 知道速限規定、查詢車牌、查找救護、警察、道路救援車牌號碼資訊 | 提供速限規定（外部事件）、查詢車牌（外部事件） |
| 警政人員 | 可減少人力成本；負責系統誤判人工處理；負責特殊性質車輛確認；提供通緝、失竊車輛車牌資訊 | 查詢通緝、失竊車牌資訊（外部事件） |
| 地方政府交通局 | 獲取當地道路長度 | 輸入當地道路長度（外部事件） |
| 當地居民 | 減少出門發生意外事故機率 | 計算事故率（狀態事件）查詢事故率（外部事件） |
| 郵政機構 | 協助警政機關寄送違規單 | 查詢罰單地址（外部事件） |
| 監視器廠商 | 協助製作高解析度影像系統供系統辨識 | 匯入高解析度影像（外部事件） |
| 車主 | 能更安全地於此處駕駛，避免與超速車輛相撞、查詢罰單 | 查詢罰單（外部事件） |
| 地方政府 | 罰金收入增加 | 查詢罰金收入（外部事件）、計算罰金數量（狀態事件） |
期中
FURPS是啥