Software Engineer vs Systems Analyst

A Systems Analyst is concerned with requirements specification. The term is pretty much obsolete today because it was coined back in the days of Structured Development. SD was very much focused on the hardware computational models. The problem was that customer domains generally are not as rigorously defined as the computing space so requirements tended to get garbled by the time they were implemented by the developers.

So the position of Systems Analyst was developed to essentially convert the customer’s natural language specification into a complete, precise, and unambiguous requirements specification. The developers would then presumably have no difficulty converting that specification to correct software. Thus the Systems Analyst was supposed to be a domain expert who also understood some rigorous notation for specifying the requirements.

Alas, in practice that was a problem because the only notations around that were sufficiently rigorous and were readily mappable to the computing space were those already used by the software designers. As a result the Systems Analyst typically overspecified the requirements by also defining the software design. Since knowledge of the computing space was a very secondary requirement for the Systems Analyst, this often led to big problems.

Unfortunately Software Engineer has been so broadly used that it has become synonymous with “software developer”. Historically, though, the term referred to someone who was concerned with the process of
developing software rather than the software itself. IOW, the people who design and understand how to apply processes and process frameworks like RUP, CMM, and XP are software engineers.