In between Business Engineers and IT Architects, how does a Business Analyst (BA) for requirements fit in? From industrial practice we know a BA definitely makes a lot of sense. So, now we try to conceptualise this extra benefit. As we’ll see, it’s mainly based on abstraction (and thus modeling).
Business and Technology perspectives
Say, your company performs the business tasks described in figure (BizTasks):
If you asked the CEO what her company is doing here, she would say sth like “We send greetings and invoices”, where ‘send’ means write and ship it, since a CEO doesn’t care if it is performed in 1, 2, or more steps, she solely has the business perspective.
If you asked the janitor, or whoever may be responsible for the tasks’ infrastructure, he would say sth like “We write ‘stuff’ and ship it”. The essential difference for him is, that he has to provide the writers with, say, a typewriter and a pen, and the mail office with, say, envelopes, stamps and a mail box nearby, in other words he has the technology perspective.
So, now that we have the biz and tech views, what is the requirements analyst’s view on this? And, moreover, is an analyst just a bit biz and a bit IT person, or does an analyst’s view makes sense on its own?
How Abstraction makes the Business Analyst
Although the janitor’s view is determined by technology, it doesn’t contain any technology itself, i.e. it consists of biz concepts (completely understandable to the CEO) only. Such a view is pretty exactly that of a BA in software requirements analysis: providing the implementors with relevant information about the business, in a technology free way.
Thus, does the BA have to be a technology specialist, in order to state relevant requirements?
Not if the BA can use an abstraction that hides the technology details. Notice, that abstraction is more than just reduction. It also has a ‘practical aspect’ (Stachowiak), in plain words, the abstraction has to make some ‘sense’ in it self. This is why a BA is not just a half-and-half biz and IT semi-specialist. The abstracting nature of the BA’s perspective makes software requirements analysis a self-contained discipline.
Information System as the Abstraction of Choice
As practice shows the concept of Information System (IS) is a ‘quite good’ abstraction for software requirements. For our purposes, by an IS we mean a system of information flows among participants. Moreover we assume an IS to be analytic, not designed, i.e. extracted from the world (by abstraction), not constructed into it. There are various definitions of IS* that are more or less all come down to data, functions, and interfaces.
In other words, analysis of software requirements means describing the world in terms of data, functions, and interfaces. No need of technology knowledge – in theory, of course. In practice some tech and biz knowledge is required as well, however the core competency – in which the BA differs – is the capability of abstracting (and thus modelling) the IS from the business. Also notice, that this is far more than just the ability to ‘think analytically’ often found in BA job ads.
So, remember: If you do not abstract, it is not analysis.
* textbook e.g.: Antoni Olive (2007) Conceptual Modeling of Information Systems.
For now, of course the open issue left, is a closer look on how an IS fits the above purpose.