使用者需求分析

需求調查與可行性研究

定義需求與撰寫規格書

尋找利害關係人與目標

確認事件(處理什麼事情)與使用案例

需求調查/需求引導
require-ments elicitation

瞭解問題、實際狀況、評估可行性、寫出規格書

調查對象:利害關係人

直接或間接提出系統需求,甚至影響系統成功或失敗的人

內部的人:作業人員、經理、管理者、外部廠商

直接作業的人:作業人員

間接影響的人:總經理、廠商、顧客

需求調查方法

問卷

排版清晰明瞭、結構清楚

面談:找關鍵使用者來訪談(開放式問答)

缺:耗時

問卷:封閉式問卷(先設計好的)

優:有效地收集資料

應該與所要收集的資料有對應關係

內容表達簡潔清楚

問題安排有邏輯

說明函:目的、調查者的名稱與聯絡資訊、回覆截止時間、回覆的方式與地點

文件回顧:組織現有的程序與相關的報告文件必須要透過收集與檢視,以進一步瞭解現有系統的運作狀況

內部資料:標準作業規範、銷售報表、產品規格等

外部資料:總體經濟報告、產業現況與趨勢報告

觀察:與現場使用者建立關係

研究:建立能解決問題的作業方式

可行性研究

評估系統發展時可能為企業帶來的風險

組織的可行性

技術的可行性

慨念證明雛形proof-of-concept prototype:確保技術的可行,降低系統發展風險,將可能使用的技術或解決方案製作出雛型以證明技術或解決方案是可行的一種方法

資源的可行性

人力資源

經濟資源

進行成本效益分析(損益平衡)

專案發展之管理

技術人員

時程的可行性

定義需求

如何撰寫系統規格書

擬定可行方案和管理者確認:根據前面執行的結果提出各種可行方案及成本效益並向管理者進行簡報(包含:系統發展的範圍與優先次序、軟體發展的方式等)

發現需求:系統分析師進行需求調查的工作

需求紀錄與分類:將調查的文件資料加以記錄與分類,以整理出有結構的文件

排定需求優先次序

急迫性

重要性

使用者需求與規格書

功能需求Functional requirement:企業每天運作的流程,也就是系統所要完成的主要工作

非功能需求Nonfunctional requirement

可用性Usability :考量系統是否容易使用,規範介面使用方式

可靠性Reliability :考量系統是否可以持續運作,規範系統有效使用與修復時間

績效性Performance :考量系統運作效率,規範系統運作時間

其他+:設計上的限制(ex.記憶體)、實作(ex.語言、工具、發展程序)、介面(ex.與其他系統傳輸的資料格式)、實體的需求(ex.作業環境)與其他支援性需求

支援性Supportability:技術服務人員安裝、組態及監控電腦產品,提供硬體或軟體服務的能力

規格書的格式

簡介

背景說明

使用者需求

環境說明

系統架構

系統規格

詞彙說明

附錄

尋找利害關係人

確認利害關係人目標並建立目標表

利害關係人的類型與職稱

利害關係人

間接/直接類型

內部

外部

操作

管理

技術

逐項分析不同使用者的需求,紀錄、分類、整理,定義出厲害關西人之目標或利益,這個紀錄並整理出來的文件就稱為利害關係人目標表

事件:在特地時間或地點發生,可以描述且值得記住的事情

外部事件external event

暫時/內部事件temporal event:
在特定時間所發生的事

狀態事件state event

由外部參與者所發動,然後由系統處理
(由代理者(間接影響系統需求)或參與者(直接操作系統)所啟動的事)

在某一特定時間一到,系統就要處理的事件(根據時間自動啟動,不需外部參與者/人為操作)

系統內部引發系統必須處理的事,通常由外部事件所引發,但與時間無關,屬於系統內部自動執行的作業

事件尋找的方法

從事件的類型尋找

從利害關係人目標表中尋找

從所有參與者需要的服務過程中尋找事件

事件的分辨

發生的時間都是同一時間,這些連續動作其實可以看成單一事件
(雖然發生時間可以獨立開來,但因為性質相近,可以將這些事件合併)

事件描述與使用案例名稱描述

事件描述:參與者在某個時間或地點要處理某個單一事情,所以描述的方式是「某個時間觸發+事情處理」

使用案例名稱描述「事情(名詞)+處理方式(動詞)」

事件表:一個事件可以對應一個使用案例,也可以幾個事件對應到一個使用案例