我常在许多软体公司与砖案经理们讨论软体人员的职掌时，发现到，耶？ 怎么我所认知的 SA/SD 与他们实际的工作内容大大不同。嗯，所以我想就针对 SA/SD 来给个正名与定位吧。

SA, 系统分析师(System Analyst)，是对设计中(Under Design)的系统来作分析，既然是分析，那么，应该是需要 “剖开" 系统内容，来对其系统内部的结构组成元素，以分析其脉络。所以我觉得系统分析师，也可以称之为 “结构分析师(Structure Analyst)。

系统分析师的工作，是着重在系统的内部，应该是要能找出与描述系统组成结构的静态(Static)元素，并利用元素，动态组合以满足系统外部的功能需求。也就是说，静态面的结构元素，与功能面的行为(Behavior)描述，均是属于系统分析师的範畴。几个主要的产出，包括类别(Class)图、循序(Sequence)图、资料库的 E-R(Entity-Relationship)图，是 SA 所该负责的，而且，上述的产出是偏向于建立领域概念的模型(Domain Conceptual Model)，并非为与平台相依的软体规格模型(Softuozhanare Specification Model)，与平台相依的软体模型，是属于 SD(System Designer) 的範畴。

而一般软体公司对 SA 的定位，是在于对客户端操作者(Operator)与领域砖家(Domain Expert)的需求访谈。但是，需求面是属于系统外部的功能面观点，我一直不认为这是属于 SA 的工作，正确地来说，这应该是 “需求分析师(RA, Requirement Analyst)" 的範畴。

有趣的是，我发现到，一般对 SA 的要求，还需要包括对使用者介面(User Interface)的设计，为何会需要 UI 的设计？ 我想应该是与 SA 访谈的对象，都比较偏于层级比较低的终端操作者，而这些操作者，会很重视 UI 的操作，却很少能正确地说明系统真正要的功能，往往都是以局部操作者的角度来看待系统。

我发现到，一般软体公司对 SA 的角色定位太过模糊，以致于 SA 根本就搞不清楚他们要做的是到底是属于系统外面的工作，还是属于系统内部的工作。如果能正确地将系统外部的需求分析与系统内部的结构分析作区分，需求分析由 RA 负责；结构分析由 SA 负责。如此，才能界定与釐清系统内与外的工作。

至于 SD，系统设计师(System Designer)，焦点仍就于系统内部的结构，与 SA 所不同的是，SA 所建构的是属于偏向于领域的概念模型；而 SD 则是根据领域模型，再配合实体的平台，如 .NET or J2EE的框架(Framework)，考量其效能、稳定、分散与安全性等，所建构而得的软体规格模型。SD 的主要产出，仍包括了类别图、循序图以及 Database Schema，而这些产出，都会与实体的平台相依。例如，具化的软体模型是以 J2EE 来实做，而就永续层(Persistent Layer)设计考量，SD 是以 Hibernate Framework 来实做，以桥接领域物件与资料库的永续储存。

不过，软体公司对 SD 的定位，反而仅在于对资料库 Schema 的设计。其实呢，对于 E-R 与 DB Schema，也并没有相对切分逻辑(Logical)与实体(Physical)的层次(Layer)。逻辑与实体之分，简单的说，实体的 DB Schema 会考量到与现实所使用的资料库系统的特性相关，诸如栏位资料型别的定义、Index and Constraint 的设计等…。

一个基本的结论，系统外部的功能性需求分析，係由 RA 所负责。而系统内部的分析与设计，是交由 SA 与 SD 来负责的，而 SA 与 SD 的界限，可以以是否有与实体的平台相依来界定。我们也可以以两句话来说明分析与设计的关係：

“Do the right thing (分析)”and “Do the thing right (设计)”。



转载自：网页

相关甘苦谈连结：

漫谈系统分析师的工作技能2 研发替代役考古题-网路上评价不一，还应该去面试吗？ 内湖晨星科技研替面试的内容?经验?感想? ABC细微的关键点