本文將會討論這三個職位在我們團隊中各扮演什麼樣的角色

SA-系統分析師(System Analyst)

跟客戶做需求訪談，利用詢問到的需求做產品的設計分析，由於做需求訪談的對象較多是直接操作系統的使用者，所以對於需求的產生是建立在功能使用情境及介面操作上，因為會需要跟專業領域的使用者訪談，也需要對產品的Domain Knowledge有一定程度的認識，所以SA就是將情境說明及介面的操作設計搭配系統的專業領域知識寫出SRS(Software requirements specification)，其中產出包括以下幾點：

業務流程圖：整個模組的流程圖
基本資料：功能代號、名稱、概述、需要編號、使用單位、角色
前置作業：使用此功能前須要做的事情，像是要建的資料、要在哪個狀態才可以使用此功能
使用案例說明：情境描述、操作行為、注意事項、功能間的交互關係
使用案例畫面：介面的呈現與設計
欄位定義：介面上每個欄位的名稱、種類(下拉選單、文字、日期…)、資料來源(系統代碼…)、是否必填

SRS為需求導向，做的是軟體的分析，比較著重在邏輯跟順序的設計，也因為SRS跟特定的程式語言其實沒有很大的關係，所以SRS可以用不同的程式語言所實作

SD-系統設計師(System Designer)

SD會依照SA撰寫的SRS去做更細部的規格設計，也就是技術規格，SD通常會是有系統開發經驗的人擔任，必須要了解系統的運作方式及程式語言，把由SRS上得到的使用情境及介面操作寫成程式的實作方式、設計資料的存放方式及測試案例的設計，SD會寫出SDD(Software Design Description)，會產出以下幾點：

欄位定義：詳細的欄位定義，像是由那張資料表取得、取得的方式、條件(Join、Exists)，要實做的控制項(Drop Down List、Date Picker、Text Box)
細部說明：實作方式，特殊需求
參考檔案：與此功能相似做法的參考，取得資料要使用的UDF、SP
Service Method：Service設計，傳入的參數、命名
單元測試注意事項：單元測試需要注意的地方，測試資料設計，畫面測試情境設計
Table Schema設計：DB資料表設計(參數名、型態、預設)