馬達拉

REF:http://wzl.idv.tw/index.php?p=123&c=1&tb=1&pb=1

RA(Requirement Analyze)需求分析
>工作內容：
對使用者或 Key Man 進行訪談，以使用者角度了解並定義流程及需求，或針對現行作業中於資訊化過程中可能造成窒礙難行的方案進行流程轉化與修正。
>角色特質：
溝通引導強、思緒條理優、臉皮耐心夠。
>產出：
作業流程圖 DFD、系統功能表Function List、系統雛型Prototyping（使用者介面需求）、使用者需求文件 URS、需求追溯 RTM。

SA(System Analyze)系統分析
>工作內容：
依 RA 所產出URS 文件及RFP、會議紀錄等，轉化為系統程式面需求，此時需評估使用者需求轉化為系統後的可行性、合理性，若具有該專案或產業 Domain Know How 於系統需求面的描繪會更趨明確。
>角色特質：
溝通技巧棒、具技術 Sense、思緒邏輯強、撰文表達好。
>產出：
系統雛型Prototyping（整合客戶流程及介面需求）、軟體需求文件 SRS 、SIT 測試個案、需求追溯 RTM。
Use Case、Use Case Specification、Activity Diagram。

SD(System Design)系統設計
>工作內容：
由SA 產出之SRS及Prototyping 進行軟體細部設計，針對開發程式語言的特性進行軟體規格設計，除以完成系統功能為目的外，需考量系統的擴充彈性、可用性、可靠性、效能性、維護性等。
>角色特質：
技術能力強、組織能力好、工具應用佳。
>產出：
系統設計書SDD、Unit Test 測試個案、需求追溯 RTM。
Class Diagram、Sequence Diagram、Table Schema、ERD。

 

REF：http://www.kenming.idv.tw/el_sa_sd_c_es_e_se_ar_af

SA, 系統分析師(System Analyst)，是對設計中(Under Design)的系統來作分析，既然是分析，那麼，應該是需要 “剖開" 系統內容，來對其系統內部的結構組成元素，以分析其脈絡。所以我覺得系統分析師，也可以稱之為 “結構分析師(Structure Analyst)。

 

需求分析由 RA 負責；結構分析由 SA 負責

 

REF:http://dennis74728.pixnet.net/blog/post/13012312

[SE, 系統工程師]

就某種角度來看, SE對PM而言, 算是萬金油, 只要做IT專案, 那就一定用得上, 差別只是要選那一個專業的SE而已。系統建置安裝要SE, 使用者環境要SE, 甚至到硬體選擇及佈建, 都要用到SE, 有什麼IT專案跟這個沒有關係呢 ?

當然, 雖然SE是到處都吃得開, 但相對的也是專案裡面最沈默及少有聲音的一群。他們的工作基本上就是建構出一個可以執行系統的環境, 系統要如何展現, SE可以給SA和SD一些建議, 但建議時機通常都是在系統運行出了些非系統可以掌握的問題後。

系統工程師基本條件上, 和SD最為接近, 但有一點不同, 就是不需要有很好的軟體開發經驗, 也就是不太需要會寫程式。但要對作業系統, 服務器系統, 網路運用環境有相當程度的瞭解。

D的工作內容如下：

· 設計畫面元素規範
· 設計頁面結構及規則
· 設計系統操作畫面, 並編定欄位規範及防呆處理
· 設計權限管理與系統操作機制
· 撰寫使用手冊
· 調整DB之各項定義, 使其符合畫面欄位規範及操作搭配
· 配合SA撰寫系統開發文件, 供程式師CODING之用
· 撰寫UI(使用者介面)測試計劃書

 

很少有SA同時專精於數個領域的, 熟悉汽車業運作規範的SA, 在金融業的開發案裡, 就很難討好, 反之亦然。但SD沒有這種限制, 基本上SD可以和任何行業的專案開發團隊配合運作。

 

UR：http://sabreurqq.blogspot.tw/2009/06/rasasd.html

RA：對於系統的需求，用自然語言寫出來，後將名詞提出作為Role，而動詞提出作為UC。且對於需求描述，用Activity Diagram畫出該動作，這部份至少完成需求描述、Use Case Diagram、Activity Diagram。

SA：參考RA的Use Case Diagram 針對每個UC去撰寫詳細流程，並且定義Class，通常之前所提出來的名詞，即是一個Class。根據UC流程繪製Sequence Diagram。這部份至少完成 Class Diagram、Sequence Diagram。

SD：有了Class Diagram，可以去試著設計系統的物件，物件的分類有Boundary、Control、Entity，Boundary通常為使用者介面，Control通常是運算的物件，而Entity通常就是資料庫的資料表。設計出所有的Object後就可以繪製Collaboration Diagram，和Sequence Diagram類似，只是Collaboration Diagram可以更清楚的知道動作的流程以及系統的架構。