系統分析的相關手法及細節

需求分析:

指的是在建立一個新的或改變一個既有的系統、服務或產品時，為確定新系統的目的、範圍、功能及定義所需要做的所有工作。

分析過程中常見的挑戰:

• 無利害關係人參與
• 利害關係人未必知道自己需要捨麼->開出一長串清單、甚至相互矛盾
• 利害關係人未必可清晰表達出自己的需求
• 需求分析不明確->用到模稜量可陳述或過多形容詞
• 專案範圍蔓延
• 需求一改再改導致重工

分析步驟

採集需求->分析需求->確認需求->製作需求規格書->管理需求

需求涵蓋範圍分類

(1)業務面:

一般性需求(業務限制、政策、法規、文化、品牌、語言)

技術性需求(軟硬體、網路、infra)

(2)解決策略面:

功能性需求(數據輸入、編修維護、檢索)

非功能性需求(可用性、可維護性、存檔及保留、備份和還原、效能、容量、安全性)

採集跟分析需求常見手法(相互搭配使用)

(1)文件分析:公司內部文件、先前案例、相關系統說明及規格書、會議記錄

風險:可能過時、有可能在其他mail loop有微調

(2)訪談、觀察

(3)問卷調查->採匿名、量較大

(4)Wireframe線框設計->手繪草稿

(5)Prototype模型製作->更趨近真實

需求訪談重點

1.寄出會議邀請(人數6~8人)。

2.參與名單建議是可以做決策的人、是利害關係人、派各部門代表。

3.規模小的會議較好(1對1、1對2較願意將真實想法透露)

缺點就是更耗時，還是建議一次約齊所有關鍵人。

4.讓大家有機會發言，不要會後才來補充。

5.引導與紀錄交談步驟

訪談後再次確認

1.製作流程圖(draw.io , visio)。

2.寄給相關人確認無誤或有無要再更動。

3.再次根據反饋更新

需求管理方式

需求規格書(清單)/User Story Mapping

需求ID

需求種類

身份(角色)->可能是部門、不同職務、消費者端還是商家端

需求名

目的

驗收標準

優先順序

企業(業務)相關功能

負責人職稱

需求負責人姓名