At the Requirements Engineering conference in Sydney I've just come from a discussion about whether there is a need to create a 'requirements engineering body of knowledge' - yes, REBOK.

Unfortunately I missed the first part of the discussion and am mystified as to the difference between RE and BA. The faciliator mentioned the BABOK, but implied a gap between it and RE.

I want to understand what this gap consists of - if in fact it exists. As one participant pointed out, virtually no one has the job title of 'Requirements Engineer'. I would have thought that the vast majority of RE practitioners were called business analysts, some systems analysts or architects - ie, no substantial difference in the actual day-to-day practice, just different labeling.

Is this just a turf thing, where rather than lobby to expand or extend the BABOK the RE crowd (which seems to be more academic than your typical IIBA member) wants its own BOK? That doesn't strike me as particularly efficient, or even helpful - to those who do business analysis/requirements engineering for a living.

I notice that I could choose 'BA - Requirements Engineer' as my job title in my profile for this site, so apparently someone sees a distinction.

Thoughts?

Bruce:

You stated: "Is this just a turf thing, where rather than lobby to expand or extend the BABOK the RE crowd (which seems to be more academic than your typical IIBA member) wants its own BOK?"

Congratulations!!! You are going to go very far in Business Analysis  - or your body will be found floating face down in a swamp :-)

Let's expand this discussion:  Is there really any difference between the essentials of Requirements Engineering, Requirements Analysis, Business Analysis, Business Systems Analysis, Business Process Analysis, Functional Analysis, Systems Analysis, Systems Engineering, Business Architecting, etc., etc.?

NOPE.   The main thing that needs to be done is the same: Come up with a comprehensive, integrated understanding of the essential tasks/processes that need to be performed and - especially - how they all interrelate.  After one does that, whether he/she then tweaks it to be an As-Is model, a Requirements Specification, a Business Requirements Spec, a Systems Specification or whatever is relatively minor.

Yes it is all about turf.  The key question is:  Why is everyone so compelled to defend a turf? 

Tony

Thanks Tony. I posted the same question the IIBA forum and got an interesting response:

http://community.theiiba.org/vb/showthread.php?p=474#post474

- which makes a good case that, regardless of labeling, this is not necessarily just a turf thing. While their processes (eg elicitation, documentation etc), methods (eg workshops), and artefacts (requirements documentation, models, etc) may be more or less identical, BAs and requirements engineers/analysts etc are often not working on the same kinds of projects. While both often work on software systems, requirements engineering typically deals with large complex systems in which software is only a component, eg airplanes, naval vessels, automobiles, hydroelectric plants, etc.

This suggests that the difference in scale might involve a qualitative difference in approach and output, and Berenbach et al make the point that processes that work for a small number of requirements will not scale to, say, tens of thousands of requirements or more. (Barenbach spoke at the conference and made the further point that no one in industry or academia has successfully implemented a process yet that does work well with very large numbers of requirements.)

That said, the different labels are a very poor (and very confusing) way of distinguising between the two practices. Standard definitions of RE are not much help:

Requirements engineering is the branch of software engineering concerned with the realworld goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behavior, and to their evolution over time and across software families. (Zave)

And if I substitute the phrase 'business analysis' for 'requirements engineering' in 99% of the literature I've seen so far, it wouldn't make a substantive difference. Still, it's valuable to appreciate how projects of vastly different scale - including numbers of requirements, and numbers and variety of components (including hardware, software, social, etc) - call for different approaches to requirements elicitation, documentation, and management. Whether a REBOK (and I have a feeling there will be one eventually) will help illuminate those differences remains to be seen.

Bruce