# 系統分析CH5

* 需求:使用***簡單的文字***來描述使用者需要的系統服務
* 描述系統應該做甚麼，而非系統如何做到這些功能

|需求|說明|
|:--:|:--:|
|使用者需求|使用者角度描述的需求(User case)|
|系統需求|詳細描述系統功能，系統開發者角度的需求|

**==RE(需求工程)==**
需求擷取-->需求規格-->需求驗證

* 需求擷取
> 從使用者、客戶或利益相關者取得系統需求
* 需求規格
> 描述為甚麼需要此系統，最後完成開發的系統樣貌
* 需求驗證
> 針對需求規格來確認文件內容的完整與正確性

==需求作業流程==
> 獲得:從專家或google等地方取得知識來獲得事實，以找出使用者的需求是甚麼
> 呈現:使用文字描述或圖形來呈現事實　
> 驗證:我們需要客戶或專家來驗證我們發現的事實是否正確

* **「利益相關者」:對系統有興趣的人，大部分是客戶，包含**
> 執行者(Executive):通常是公司，不會涉入軟體開發的技術層面，只會提供商業流程與規則方面的意見
> 終端使用者(End User):使用者
> 專家(Expert):公司顧問或其他支援like法律或會計人員
### 需求擷取活動
> 背景閱讀:先了解公司內部的情況與背景
> 訪談
> 問卷調查
> 觀察
> 腦力激盪
> 紀錄需求
> 定義需求:哪些需求是必須的，排列優先等級並整理需求
### 需求描述
> 將原始需求資料重新定義成我們需要解決的問題
> 使用簡單且標準的語法來描述需求(T or F之類的)
> ==功能性需求==: 描述系統應該做甚麼(What)「對一些特殊案例還要標示不能執行哪些功能」
>> 非功能性需求:「最低選課學分應該15、用甚麼方式Hashed之類的」
### 需求屬性
> 每個需求都需要一組屬性來記錄額外資訊

|優先等級|說明|
|:--:|:--:|
|==MoSCoW==||
|Must-haves|M|
|Should-haves|S|
|Could-haves|C|
|Want-haves|W|
|==Rational==||
|State狀態|建議、允許、拒絕、完成|
|Benefit效益|嚴重的:需求開發完成但客戶不認可、重要的、有用的|
|Effort成本|需求完成的時間資源|
|Risk風險|高中低|
|Stability穩定性|高中低|
|Target Release目標釋出版本|預計需求完成的產品釋出版本|

### 事件分割法
> 定義:與使用者互動的過程，每個使用者做的動作都是一個事件
> 基本語法:++主詞+動詞+受詞++
> |欄位|說明|
> |:--:|:--:|
> |事件|事件名稱|
> |觸發器|產生事件的原因|
> |來源|外部實體，通常是使用者或外部系統|
> |活動/使用案例|系統如何回應事件|
> |回應|系統產生的輸出|
> |目的地|誰會取得輸出結果|
>> 外部事件:系統外的事件，使用者透過介面執行
>> 時間點事件:特定時間點觸發，例如時間到要報稅等等
>> 狀態事件:內部狀態改變所觸發的事件，例如管理者關閉系統等
### 需求規格
> 說明為甚麼需要這套系統，和最後完成開發的系統樣貌
### 需求驗證
> 目的是確認需求規格的內容是正確的
>> 手工確認
>> 使用雛形:建立系統雛型來驗證功能性需求
>> Fagan檢驗:使用系統化和結構化方式找出文件錯誤，目標是找出錯誤，需要一個小組來執行
>>> 
###### tags: `系統分析`