Pardon my cynicism and with apologies to the RESG group whose name includes RE, but I’d suggest these differences mainly reflect title inflation aimed at enhancing the role’s perceived prestige. ‘Engineer’ generally sounds better, and perhaps can be argued convincingly should command higher pay, than ‘analyst.’ All the rest of the supposed distinctions that have been raised seem like not-very-meaningful-in-the-(pardon-the-expression)-real-world-overly-anlayzed rationalizations.

 

I agree the dictionary defines analyst and engineer differently. However, so far as I can tell, dictionary differences are irrelevant in this instance; and as a practical matter, what business analysts and requirements engineers do is essentially interchangeable. No doubt there are variations among individuals with these titles, but I doubt seriously that there are any consistently meaningful characterizations attributable to the one title versus the other. Your post here certainly has not revealed any widely shared consistent distinctions.

 

Again with apologies to RESG, I believe a far bigger issue is that the term ‘requirements engineering’ is inappropriate—from two standpoints. First, in many political jurisdictions, such as the 50 states of the United States, ‘engineer’ is actually defined by law. It is my understanding, for instance, that at least two states in the USA prohibit the term ‘software engineer’ because said title fails to satisfy those states’ legal requirements for being called an ‘engineer.’ Surely the far less widely used ‘requirements engineer’ also would fail to pass legal muster.

 

Second, one does not engineer REAL business requirements—business deliverable _whats_ that provide value when delivered, satisfied, or met. REAL business requirements are conceptual, exist within the business environment, and therefore must be discovered. 

 

There usually are many possible ways to satisfy REAL business requirements. Engineers are not discoverers but rather specify the requirements of a human-defined product, system, or software _how_ which is presumably one of those possible ways to satisfy the REAL business requirements _whats_. As such, the proposed product/system/software is a high-level design and provides value if and only if it in fact satisfies the REAL business requirements. ‘Engineer’ and ‘specify’ are synonyms for ‘design.’ REAL business requirements must be discovered--not designed, specified, or engineered. 

 

See my book, Discovering REAL Business Requirements for Software Project Success, for further elaboration of these critical differences.