Edited by Sebastian Tyrrell, Wednesday, 9 Feb 2011, 12:34
I was thinking a little bit about the relationship between business analysis and requirements’ engineering, particularly when it comes to job specifications. If an agency or an employer are asking for a business analyst, to what extent does your experience as a requirements’ engineer help? And vice-versa of course.
If I am asked for a quick definition, I will usually say that the business analyst is concerned more with the organisation and the way that works in general, whereas requirements’ engineering looks at products (or processes) to be developed to improve the way an organisation works. This is true as far as it goes, but is not particularly satisfactory and leaves many questions hanging.
For a start the requirements’ engineer must understand the context in which a new product or process will work, and to do this must understand the business and how it functions. We must identify the stakeholders, their roles, and the other systems with which a proposed product must interact. We must analyse how it works now in order to propose a better way of working in the future, and crucially we must be able to tell our customer whether the proposed new product or process will indeed be an improvement. In doing this we will use tools such as stakeholder analysis, business events, business use cases and business process modelling. In other words, we will be performing a business analysis It may be only a part of the business that we are analysing, but then how many business analysis tasks are specified as “analyse Microsoft”?
So the two disciplines – if indeed they really are two disciplines – are clearly intricately related. Can we get any more specific? Are there any clearly defined points of difference?
Business analysis is the discipline of identifying business needs and determining solutions to business problems. Solutions often include a systems development component, but may also consist of process improvement or organizational change or strategic planning and policy development.
It seems to me that this would be a pretty good definition of requirements’ engineering as well: though some might quibble with the idea that requirements engineering would encompass the possibility of process improvement, organisational change or strategic planning. Yet it only takes a moment’s thought to realise that it must, indeed, do so – are we really going to tell our customer that they should go ahead and develop a heavyweight system at great expense to support an unwieldy process when we know that they could get more benefit from simplifying the process?
Maybe don’t answer that too quickly, because unfortunately the answer is all too often “yes”: but commitment bias and the role of the requirements engineer (or business analyst) in avoiding it by concentrating on solving the problem rather than implementing a pre-conceived solution are a subject for a whole other post.
Wikipedia, again, identifies six “sub-disciplines” of business analysis. Of these five – requirements planning and management, elicitation, analysis and communication and solution assessment and validation – are unequivocally also sub-disciplines of requirements engineering while the other – enterprise or company analysis – includes many elements common to requirements engineering such as establishing the context within the wider socio-technical environment: stakeholder analysis, goal analysis and so on. Arguably the closer the requirements’ engineer can come to a full business analysis, the better the job s/he is likely to do because s/he can focus on the wider goals and not just someone’s proposed solution.
There is, possibly, the nub. A task that is advertised as “requirements’ engineering” might generally assumes that there is a systems development component as part of the solution, while one that is described as “business analysis” makes no such assumption. That analysis though depends on the author of the task description having thought carefully about what to call the task, rather than using the standard term previously used by their organisation.
In summary, business analysis and requirements engineering are closely entwined but with some subtle differences in perspective. Job descriptions are unlikely to be completely clear merely from the job title: it is important to look at the details of the task to see where it is really focused.
Note: I’ve used Wikipedia here not because I regard its definitions as definitive, but because I found them useful and descriptive. There are other definitions of business analysis on the web, such as this from BusinessDictionary.com
that I felt were either woolly or (as in this case) so general that I would have in effect needed to rewrite the Wikipedia article just to explain them. If anyone has a different view on the nature of business analysis and its relationship to requirements engineering then please do contact me, or leave a comment, and we can start a discussion.
The business of requirements.
I was thinking a little bit about the relationship between business analysis and requirements’ engineering, particularly when it comes to job specifications. If an agency or an employer are asking for a business analyst, to what extent does your experience as a requirements’ engineer help? And vice-versa of course.
If I am asked for a quick definition, I will usually say that the business analyst is concerned more with the organisation and the way that works in general, whereas requirements’ engineering looks at products (or processes) to be developed to improve the way an organisation works. This is true as far as it goes, but is not particularly satisfactory and leaves many questions hanging.
For a start the requirements’ engineer must understand the context in which a new product or process will work, and to do this must understand the business and how it functions. We must identify the stakeholders, their roles, and the other systems with which a proposed product must interact. We must analyse how it works now in order to propose a better way of working in the future, and crucially we must be able to tell our customer whether the proposed new product or process will indeed be an improvement. In doing this we will use tools such as stakeholder analysis, business events, business use cases and business process modelling. In other words, we will be performing a business analysis It may be only a part of the business that we are analysing, but then how many business analysis tasks are specified as “analyse Microsoft”?
So the two disciplines – if indeed they really are two disciplines – are clearly intricately related. Can we get any more specific? Are there any clearly defined points of difference?
Let’s start with some definitions:
Wikipedia defines business analysis as:
Business analysis is the discipline of identifying business needs and determining solutions to business problems. Solutions often include a systems development component, but may also consist of process improvement or organizational change or strategic planning and policy development.
It seems to me that this would be a pretty good definition of requirements’ engineering as well: though some might quibble with the idea that requirements engineering would encompass the possibility of process improvement, organisational change or strategic planning. Yet it only takes a moment’s thought to realise that it must, indeed, do so – are we really going to tell our customer that they should go ahead and develop a heavyweight system at great expense to support an unwieldy process when we know that they could get more benefit from simplifying the process?
Maybe don’t answer that too quickly, because unfortunately the answer is all too often “yes”: but commitment bias and the role of the requirements engineer (or business analyst) in avoiding it by concentrating on solving the problem rather than implementing a pre-conceived solution are a subject for a whole other post.
Wikipedia, again, identifies six “sub-disciplines” of business analysis. Of these five – requirements planning and management, elicitation, analysis and communication and solution assessment and validation – are unequivocally also sub-disciplines of requirements engineering while the other – enterprise or company analysis – includes many elements common to requirements engineering such as establishing the context within the wider socio-technical environment: stakeholder analysis, goal analysis and so on. Arguably the closer the requirements’ engineer can come to a full business analysis, the better the job s/he is likely to do because s/he can focus on the wider goals and not just someone’s proposed solution.
There is, possibly, the nub. A task that is advertised as “requirements’ engineering” might generally assumes that there is a systems development component as part of the solution, while one that is described as “business analysis” makes no such assumption. That analysis though depends on the author of the task description having thought carefully about what to call the task, rather than using the standard term previously used by their organisation.
In summary, business analysis and requirements engineering are closely entwined but with some subtle differences in perspective. Job descriptions are unlikely to be completely clear merely from the job title: it is important to look at the details of the task to see where it is really focused.
Note: I’ve used Wikipedia here not because I regard its definitions as definitive, but because I found them useful and descriptive. There are other definitions of business analysis on the web, such as this from BusinessDictionary.com
Investigation into the operations of a business to expose the causes behind the results achieved, and the effects of those results on the business.
that I felt were either woolly or (as in this case) so general that I would have in effect needed to rewrite the Wikipedia article just to explain them. If anyone has a different view on the nature of business analysis and its relationship to requirements engineering then please do contact me, or leave a comment, and we can start a discussion.