3 December 2007

Requirements Engineer ≠ Business Analysts

For a while I have been reading the Requirements Engineering Yahoo group, and from time to time I scan the RE Journal. When I do I always put down my reading with a hunch that Requirements Engineers and Business Analysts are not the same people.

A quick example to illustrate my point; when RE’s talk about quality the phrase “complete and accurate” comes up very quickly. In BA discussions the emphasis is on “understanding and effective communication.”

Both groups are talking to the same point, but one is focusing on the artefacts while the other is focusing on the people. The ‘quality artefact’ approach will be more important in highly formal and contractual environments, while the people (outcomes) based approach will be more effective when the team is working in a more informal or united way (e.g. less likely to be a cross-functional or client-vendor team.)

Another point to note is that the business analyst is not just a requirements manager. Requirements management is a critically important job and a key part of the business analyst’s role, but the BA looks beyond the requirements to a wider range of issues that orbit the business problem the project is there to address.

Business analysts are looking deeply at the business problem, and the requirements are just part of the solution. In particular there is the constraints of the environment, the change management-effort required and benefits realisation, not to mention things like enterprise analysis, developing project business cases, project portfolio management, stakeholder management and the many other things BAs do in the course of delivering the project.

The IIBA’s BABOK spends much of its content going through the requirements management process and rightly so because requirements management is a large part of a project BA’s life, but just like the contents of the BABOK it’s not the exclusive content.

The bottom line of all this is that Requirements engineering is just one of the many things a business analyst gets involved in. Requirements management is a key part of a business analyst’s role, but not all BAs are managing requirements and not all requirements managers are BAs.


  1. You have summarized very well that Requirements is not all what a BA does.

    As we gain more experience as BAs, the share of our daily time that requirements gets goes down as well. It's partly due to the fact that we get good at it and also largely because we realize precisely what you said - we are here to solve business problems, streamline processes, provide guidelines, identify opportunities for improvement both in technology and skills, share our learnings from the outside world, etc.

    One of my struggles in the past have been in defining the role of a BA. For a person who is just starting on this path, it is very easy to be told what a BA is, but as the same person progresses, the boundaries between BA and PM and Process Consultant, typically, become very blurred.

  2. Thanks Raj

    I totally agree with your views on this.

  3. Anonymous10:28 am

    You are absolutely right and have descirbed it well. BA is much more then just RE. RE is indeed an integral part of a BA's role and responsibility but not the absolute truth.

    Ths enigma is what actually are the KPA's for a BA. There is no standard approach taken when it comes to BA. I have worked in different organisations and each had their own definition of what a BA should be doing.
    Role of a BA in a software development house would be purely focused around SDLC on the other hand in a service industry it would depend on the organisation structure and where the job sits.
    In mu current role ownership of the Business case, Benefits realization lies with the Business and my role is to make sure we achive objectives defined in BC and Project charter.

    There are times where i have to wear two hats i.e. BA and PM depending on the size, funding and resource avaliability. and thats where the test begins.

    I believe role of a BA has been undermined in the present world and at times taken for granted. A BA is visualized as a person who could be manipluated to play varied roles(BA/PM/Tester/QA) as the situation calls and my argument has always been that PM/Testing/QA are dedicated streams and they warrant specific knowledge/experince. One cannot expect a BA to perform such specialized roles with an expectation of profeciencey

    Benefit realization responsibility should be held with the business owner/sponsor and cannot be left for a IT BA to manage.