背景
客戶想要幹什麼的時候! 有時候，也有可能是，老闆想要幹什麼的時候! 最常發生的時機，大概都會是在年度快結束，準備要談下年度的工作的時候。
需求內容
也就是客戶說他想要幹什麼的內容，通常會包含有三種資訊：
1.故事：誰想做什麼?
過去怎麼做的；現在我們想要改成什麼樣子，或是增加什麼功能；未來最好可以保留什麼彈性，以方便增加什麼東西。
2.限制：誰? 什麼時候? 在哪裏? 跟什麼搭配?
預報員於預報作業時間，在預報中心的主機，讀取GFE的資料，編輯產品後，送給機務課負責傳送…
3.相關配合工作：
請你們幫忙Survey什麼技術，幫我們的人做教育訓練，還要有一些文件可以給我們…
運作執行
好了，我們接到客戶提出來的需求了，接下來呢…
1.先開一個會，擬定策略
(1).先討論這件事的程度，意思是說，也許根本可以不理他…
(2).確立權責與關鍵人員：這項工作的對象包括我方與對方；誰是這項任務的負責人與關鍵人員，這很重要!!
(3).建立溝通管道：對於這樣子的負責人與關鍵人員，應該有什麼樣的管道；是要集合所有關鍵人員一起開會，還是各個擊破，還是對單一窗口就好?
(4).訂立時程規劃：以上確定後，就可以來訂定時程，時程的規劃，主要會包含[步驟2.]，而且可能會重覆3~4次；時程人力的預估，應該會依需求內容之不同而有不同。不過，我們現在還沒有足夠的統計資訊，所以可以先憑經驗，大家有共識即可。
2.開始認真工作 (這個步驟可能會重覆3~4次)
(1).系統需求分析 (這個步驟可能也會重覆好幾次)
將客戶提出的故事、限制等等東東，分解成為四種圖，可以看一下本文件後面 [參考事項-需求分析] 一節。
A.對四個面向分別討論已知及未知項目
B.連結各面向關係，檢視彼此衝突
C.重覆A、B動作，直到沒有疑慮
D.討論相關配合工作：這個項目的討論，跟上面的系統開發，好像比較沒有什麼關係，似乎只要能釐清就好…
E.整理記錄，安排下一階段工作，可能的工作像是：找哪一個客戶確認什麼事情；了解一下什麼技術…
(2).人力預估：對上面討論的結果，主要是已知的部份，包括模組與元件的開發以及配合的工作項目，估計人力成本。因為，在與客戶反覆討論與確認的過程中，人力資訊可能會是客戶做決定的一個參考指標。
(3).與客戶討論與確認：最好都能留下會議記錄。
3.撰寫規格書&建議書：到了這個階段，寫這些東西應該就不是什麼難事了…
參考事項－需求分析
需求分析的工作，應該會要有下面的四種圖，而這四種圖之間會有連結與衝突之關係，實際的需求分析工作，其實就在於了解之間的關連並解決彼此的衝突。每一個圖都應該會有已知的部份以及未知的部分，所以實際畫圖時，可能會畫出不只一張圖；例如，對於未知的使用者操作流程，我們可能就可以先行假設2~3種不同的建議。
1.使用案例圖：即是UML裏的UseCase，一個系統可能會有好幾個不同的UseCase，每一個UseCase應該會是一個獨立的作業流程。以QPF為例：[預報編輯]與[預報校驗]會是兩個不同的UseCase。當然，系統夠大才會需要UseCase；像TED系統，預報員的作業是一次從頭做到尾(選擇條件、編輯、傳送)，其實就只有一個UseCase，所以也就不需要案例圖了。
2.作業流程圖：這是從使用者角度觀看的操作流程，只要把使用者會知道、會看到的部份寫上去就行了。建議可以是UML的Activity Diagram。
3.資料流程圖：以氣象局為例，客戶很重視資料(包含產品)如何流動；所以，必需將資料流程清楚表現。建議可以用DFD，但是，最好是與 [作業流程圖] 搭配，不要把圖畫的太複雜。
4.模組元件圖：這個會是以系統開發人員的角度來畫的圖，也是以後系統開發設計時，主要的參考資料。所以，必須十分注意，模組與元件的完整性，以及介面的相關性。因為，這些資訊會變成一個系統的架構，也就是說，以後如果有新的需求是要變更這個架構，會累死人的…
客戶想要幹什麼的時候! 有時候，也有可能是，老闆想要幹什麼的時候! 最常發生的時機，大概都會是在年度快結束，準備要談下年度的工作的時候。
需求內容
也就是客戶說他想要幹什麼的內容，通常會包含有三種資訊：
1.故事：誰想做什麼?
過去怎麼做的；現在我們想要改成什麼樣子，或是增加什麼功能；未來最好可以保留什麼彈性，以方便增加什麼東西。
2.限制：誰? 什麼時候? 在哪裏? 跟什麼搭配?
預報員於預報作業時間，在預報中心的主機，讀取GFE的資料，編輯產品後，送給機務課負責傳送…
3.相關配合工作：
請你們幫忙Survey什麼技術，幫我們的人做教育訓練，還要有一些文件可以給我們…
運作執行
好了，我們接到客戶提出來的需求了，接下來呢…
1.先開一個會，擬定策略
(1).先討論這件事的程度，意思是說，也許根本可以不理他…
(2).確立權責與關鍵人員：這項工作的對象包括我方與對方；誰是這項任務的負責人與關鍵人員，這很重要!!
(3).建立溝通管道：對於這樣子的負責人與關鍵人員，應該有什麼樣的管道；是要集合所有關鍵人員一起開會，還是各個擊破，還是對單一窗口就好?
(4).訂立時程規劃：以上確定後，就可以來訂定時程，時程的規劃，主要會包含[步驟2.]，而且可能會重覆3~4次；時程人力的預估，應該會依需求內容之不同而有不同。不過，我們現在還沒有足夠的統計資訊，所以可以先憑經驗，大家有共識即可。
2.開始認真工作 (這個步驟可能會重覆3~4次)
(1).系統需求分析 (這個步驟可能也會重覆好幾次)
將客戶提出的故事、限制等等東東，分解成為四種圖，可以看一下本文件後面 [參考事項-需求分析] 一節。
A.對四個面向分別討論已知及未知項目
B.連結各面向關係，檢視彼此衝突
C.重覆A、B動作，直到沒有疑慮
D.討論相關配合工作：這個項目的討論，跟上面的系統開發，好像比較沒有什麼關係，似乎只要能釐清就好…
E.整理記錄，安排下一階段工作，可能的工作像是：找哪一個客戶確認什麼事情；了解一下什麼技術…
(2).人力預估：對上面討論的結果，主要是已知的部份，包括模組與元件的開發以及配合的工作項目，估計人力成本。因為，在與客戶反覆討論與確認的過程中，人力資訊可能會是客戶做決定的一個參考指標。
(3).與客戶討論與確認：最好都能留下會議記錄。
3.撰寫規格書&建議書：到了這個階段，寫這些東西應該就不是什麼難事了…
參考事項－需求分析
需求分析的工作，應該會要有下面的四種圖，而這四種圖之間會有連結與衝突之關係，實際的需求分析工作，其實就在於了解之間的關連並解決彼此的衝突。每一個圖都應該會有已知的部份以及未知的部分，所以實際畫圖時，可能會畫出不只一張圖；例如，對於未知的使用者操作流程，我們可能就可以先行假設2~3種不同的建議。
1.使用案例圖：即是UML裏的UseCase，一個系統可能會有好幾個不同的UseCase，每一個UseCase應該會是一個獨立的作業流程。以QPF為例：[預報編輯]與[預報校驗]會是兩個不同的UseCase。當然，系統夠大才會需要UseCase；像TED系統，預報員的作業是一次從頭做到尾(選擇條件、編輯、傳送)，其實就只有一個UseCase，所以也就不需要案例圖了。
2.作業流程圖：這是從使用者角度觀看的操作流程，只要把使用者會知道、會看到的部份寫上去就行了。建議可以是UML的Activity Diagram。
3.資料流程圖：以氣象局為例，客戶很重視資料(包含產品)如何流動；所以，必需將資料流程清楚表現。建議可以用DFD，但是，最好是與 [作業流程圖] 搭配，不要把圖畫的太複雜。
4.模組元件圖：這個會是以系統開發人員的角度來畫的圖，也是以後系統開發設計時，主要的參考資料。所以，必須十分注意，模組與元件的完整性，以及介面的相關性。因為，這些資訊會變成一個系統的架構，也就是說，以後如果有新的需求是要變更這個架構，會累死人的…
沒有留言:
張貼留言