Head First OOAD Ch2 tips

Gathering the Requirements.

Main objectives:

# Gather the requirements for the object.

# Figure out what the object should really do.

# Get any additional infos we need from users.

# Build the object right.

有一小段字講到很關鍵,在做系統需求訪談時, 關鍵就是讓你客戶盡量講,然後你只需要專心聽@@"

Oh my god ..要是每個都跟小李一樣...那我就升天了= =

在本章當中,以遙控器作為一個delegation的概念來開狗門,算是有跟第一章呼應到..

在需求談完之後,其實應該產出一份需求列表,而非是像那鬼屋特有的會議記錄格式-.-

不過,有時候只傾聽使用者的想法確實是不夠的,應該一下其他部份是使用者沒想到的,甚至是缺點,但這當然已經是另外一回事了,是否要真的跟客戶反應倒是見仁見智了!!

把客戶需求項目逐步寫下的列表,並考量各種流程與事件,其實就是在撰寫一份use case !!!!

而一份Use case具備了三件事

1. Clear Value , 清楚的描述到底要作什麼

2. Start and Stop ,程序到底是如何的開始與結束

3. External Initiator , 有無外部的參與者( or 引發者)

完成use case撰寫時,必須再次與需求列表對照確認功能是否都滿足

測試..一般狀況我們都會去測正常的case,但這是不夠的,因為正常狀況很容易測試,而錯誤的部份則是需要更該被關注的,也許可以要求同仁來作assertion,在單元測試中進行

總結:

# External Initiator -->

外部的引發者或參預者,在系統規劃時應併同考量此可能性,並知道其帶來的 影響

# UseCase -->

常見的老台詞了,主要還是用於收集需求並描述系統功能運作

# Start Condition -->

在use case中 所有功能的起始

# Requirement -->

老梗...描述系統功能要作到哪些事情

# Clear Value -->

最正確的去描述出UseCase到底要作到哪些正確的事情,才能符合客戶需要的

# Stop Condition -->

在use case中 功能的結束

# Main Path -->

在系統功能中預期正常的運作過程與結果,但很顯然的必須規劃或預測其他有可能的不同過程

在撰寫一份use case時, 應至少包含以下幾點項目

# 功能名稱

# Primary Actor

# Secondary Actor

# Preconditions

# Goal

# Main Path

# Extensions (在main path之外的部份)