由 Jeff 看世界

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。

V&V 是 Validation and Verification

Validation, however, is a more general process. You Should ensure that the software meets the expectations of the customer.

Verification involoves checking that the software conforms to its specification.

Validation: Are we building the right product?
Verification: Are we building the product right?

Validation(驗證)：使用者，符合使用者需求(DO THE RIGHT THING)
Verification(證明)：開發者，符合系統功能規格(DO THE THING RIGHT)

UR(user requirement)：
針對Use Case 及 Use Case Description (但僅針對需求的描述及說明輸入輸出 及重要的stakeholder關係說明 限制條列等)
以 User goal Level 產出 SRS

SA(system analysis)：
針對UR 的 UC 及 UCD 進一步的延伸　包括流程的定義　例外的流程 　及相關TEST PLAN 限制說明等
就我認為SA 應該補捉的是Dynamic 分析也就是行為面(behavioral)
透過 UC 及UCD 的修正、Sequence D、Activity D、StateChart D、Collabation D 當然是視需要來挑選Diagram 最好加入System Prototyping (UI、Flow等)
SA 要執行的層面是 What is ? 比UR 更深入的來看系統

SD(system design)：
以SA 產出的上述之Diagram 來進行 Static 分析也就是結構面（Structural）
利用 Class D、Object D、Component D、Deployment D 來Model 出物件關係及物件屬性及方法等(當然是視需要來挑選Diagram )含DB Design
SD 要執行的層面是How to? 依SA 的需求來架構系統

註:
我個人一直覺得 DB Schema 的結構性分析或定義　
往往都被提到該由SA 或SD 甚至是 SA 規劃大致規格 SD 細部調整
但我後來讀了許多文章與書後發現在UML Model 下 DB 的Design 根本不該出現
因為若是以DB Design 的角度來看系統設計　思維已被綁死在DB 的限制之上
而非跳脫到物件導向層次　但是當然最終還是會回歸到DB (或 Storage)
只是是否如 UML 其它前輩先進所說
「當Static Model 被設計出來　你的DB Schema 也就設計出來了 系統也可以實作了？？」
我不否認我感到質疑　無論是方法結果或是Performance 等來說
我相信都很難被實現在現行的專案環境中
不過我自己認為最好的方法還是要有DB 的Design：
「SD Model Schema、Architect Review、DBA tuning Performance」
當然現實環境專案大小會影響到人員的配置與成本
應該可以做調整與fix