„In which part of the organization should a business analyst or requirements engineer be located?“ is actually an age-old question. It always comes along with other questions like the „what is the difference between a business analyst and a requirements engineer?“, as well as the WHAT and HOW. These questions have a symbiotic relationship.

If an organization has business analysts as well as requirements engineers working in a Taylorized step-by-step Waterfall environment, then the business analyst will be located in business while the requirements engineer will most likely be placed in IT.

This setting will create friction at some point in time. It is not the WHAT and HOW that separates the business analyst from the requirements engineer. The issue, of course, is that there are different levels of the WHAT and HOW: In a Taylorized setting with business architects, business process engineers, business analysts, requirements engineers, application architects, application designers, and application developers each of these roles have their own HOW and will not be amused if another role describe that. Each of these HOWs is the reason for their job and existence in the organization.

In a modern setting, the requirements engineer uses user-centered design to identify what the user wants, identify what the user needs and describe what the application shall do in order to fulfill a user’s needs. In order to describe the WHAT, we need a little bit of HOW, too.

BA: „That is my job as well!“
RE: „But, if that is your job then what is mine?“
BA: „I don’t know what your job is. I’m in business and I identify our needs and what I expect from the application.“
RE: „And what about the flow of activities within the application? May I do that?“
BA: „Of course not. The flow of activities is part of the business process and I also describe that within the use cases.“
RE: „Not the alternate flows as well?“
BA: „The alternate flows are linked to our business rules. Of course, that is my job.“
RE: „But the object model! I can do the object model!?“
BA: „That is business knowledge.“
RE: „But then, what else is left for me to do?“
BA: „You could describe the inner workings of the application.“
RE: „Alright then. To prove the need for my existence, I’ll do that.“
Application Designer and Application Developers in unison: „No chance, that is the system design! You are not going to describe my HOW!“

In a different setting in which there is only one role combining the business analyst and the requirements engineer, the BA/RE could be located on both sides of the fence, some may argue. If business knowledge is implemented into an application and a BA/RE in IT documents that business knowledge to be implemented into the application, then that business knowledge about the application will be in IT. The business will loose their business knowledge.

There is one distinction that we have not touched: The WHY. We always talk about the WHAT and HOW while the WHY is the most important question a business analyst should be allowed to ask. If the BA/RE would be located in IT then it would be more difficult to ask that question.

BA/RE: „Why do you believe you need this feature?“
Business User: „That’s none of your concern. The decision has already been taken by me, the business, and the order is out to the IT department.“

But, what is „the business“? What about the other users of the organization that are not „the business“? Don’t users in the IT department also have „wants“ and „needs“ that an application should fulfill?

The real issue are the orders to IT and the „I’m the business and take the decision. You are IT and are supposed to deliver!“. In a collaborating environment it doesn’t really matter where a BA/RE is located, as long as you may ask „WHAT do you want?“, „WHY do you need it?“, and may define your HOW. Most of the time, that will be in business.