Modelling the business problem: Business Context and the argument for free diagrams
Having recently undergone a peer review, just before Christmas - this topic is sitting right at the top of my mind at the moment.
I wrote a business requirements document ( although in this particular company it's called a Customer Requirements Specification - due to the fact that the system teams can service other system teams as well as business areas.) In my opinion , the name of the document is far less important that it's contents, and I see no conceptual conflicts with referring to your client area as 'the business'. In practise , and for all intents and purposes , even if you are not directly interacting with an Operations Business Area , you are servicing your business clients, be they another system area that requires a service from you , or a business ops area that requires new functionality or a new process.
One of the areas that I was questioned on was my choice of diagrams, and the contents thereof. I must be honest , I had an absolute ball researching the things I wasn't sure of , and making mental notes to update my definitions and internal frame of reference, but the one point I found myself sticking on was that fuzzy grey area around modelling the business context.
I ended up using "use case" notation - and I use quotation marks deliberatley as I am still not too happy with the end result which included about 3 comment boxes detailing the problems.
I found this method on another blog : The BA Times: The Business Context Model; As Good as it Gets.
It's a very useful way to describe the problem to the business , and to the architects, system team members, and while I have no real issues with the method - I am still very cautious about it's usefulness in a document where the business problem is already described in detail both in the introduction and in the tabulated list of stated needs.
In my experience, and strictly talking in terms of the business stakeholders and users that I have dealt with, they are far more comfortable with pictures that are not UML, and short bullet points to describe the needs they have.
To contrast the UML method with the diagrams that I prefer to produce for the business sign off - I have produced two diagrams , using generic terms like : The Business Problem , and Area of Interest.
This is the first one :

And this is how I would model the same problem:
My response is this - for the purposes of getting your head around what the business problem is , and the points along the way in the high level business process that are hot spots and points of contention, this diagram is far more useful than the first one .
Note - I am not saying that the first diagram is not useful, and I am not saying that mine is better . I am saying that given the environment that I have my experience in , and the users that I have dealt with thus far , the second diagram lends itself more to being presented to the type of business users that are not interested in learning what all the funny pictures mean in BPMN, or UML. You really do need to explain less about the second diagram, and it will prompt more questions than the first.
And questions are good. If they are asking questions , it means they are thinking about how you have described their problem , and deciding if you really understand it. A 45 minute meeting going over and over how you have described their issues is infinitely better that walking into a room , having the users take one look at your use case , tell you it's fine and walk out.
There are people ( and the author of the blog I have referenced appears to be one of them ) who will claim that Use Cases are simple and easy for users understand. And they are mostly right on that point. Use Case Diagrams are a very succinct way of placing a process , or set of "uses" from the business in context.
They also however - miss out critical details about what's wrong with the current process , and what the business's stated needs and problems are. Which is why I do not like them for anything except the finest grained of system and business process definitions in a functional requirements document.
I am a stickler for doing things the right way - but I am even more of a stickler for being efficient and getting people to understand. Understanding , agreement , consensus , and coming to the same mental picture of that damn swing that we all know so well are far far more important than producing pretty little standards-compliant diagrams that no-one but you and your fellow BA council members can understand.
IT BA and BA : what's the difference ?
OK Cherubs , here's a thought. Debate rages all around about BA's and what is a BA exactly . While we have been blessed with the thorough and extensive work in the Business Analysis Body of Knowledge® (BABOK ®), and the rising star of the International Institute of Business Analysis IIBA®and its various local chapters, there is still a lot of debate around whether a BA focussed on Business processes only – also sometimes called a Business BA ( don't you love the redundancy in that term ? A Business Business Analyst, what a mouthful!), and an IT BA need the same skills necessarily, and what those skills should be.
see also Requirements Analysis for some background and a more information
All of the above does not require the Solution to include any technological aspects.
o Elicit, identify, analyse and decompose Solution Requirements that consist of
- Functional Requirements
- Non-Functional Requirements
The IT BA therefore, it is presumed and assumed should have some background in technology. Many graduates with IT focussed degrees , become junior developers , moving through the systems analyst role, and eventually taking on the role of IT BA. This is not always the case however, IT BA's, and BA's come from many different backgrounds.
The roles and responsibilities stay the same , but the collaboration of the two uniquely positioned viewpoints means that the processes , the analysis , the outputs and the resulting requirements definitions are, within the constraints of the project , the best they can be.
This does not mean necessarily that there will be two people working on the project. In organisations with resource constraints, or where there is no distinction between BA's and IT BA's , there will often be only one BA assigned to a project.
It is these projects where the BA's ability to don different hats becomes critical. If this is you , you must be able to do the BA work as a BA, focus on the Business definitions , concepts , problems and terms. Talk about the solution in terms of what the business will want to achieve. You should then effortlessly be able to step out of that role , and converse technically with the relevant development team as an IT BA regarding the mapping of those business requirements into functional requirements and solution architecture, while maintaining in the back of your mind anything that might impinge on the business needs.
Globally the role of the BA is becoming more recognised as a profession in it's own merit , and as this thinking gains ground, it becomes ever more critical that BA's step up to the challenge of delivering on that expectation. This means we all need to be able to play different roles, BA, IT BA, technical advisor, systems process analyst, process designer. User Champion.
Yes - User Champion. If that role has not been represented correctly on your project ( a senior VP Exec is NOT a user champion. ) then you need to take on that responsibility , at least to the extent of owning the Functional Requirements and relating them back to an actual business need.
Don't know what a User Champion is ? Check out below for some interesting reading :
http://www.frontend.com/design/the-user-champion.html
http://tc.eserver.org/19312.html
A BA is not someone who takes notes and writes down what the users want. A BA questions , probes , elicits information , and gathers details. All of this for the purpose of creating a unified view of the problem , it's solution and the road map to get there. In order to accomplish this they will need to play various roles, produce several artefact's and acquire and hone many skills, all of which combine to produce a uniquely skilled individual. An individual who is capable of filling those messy inconvenient gaping holes between Project Managers , Users , Architects, Developers , Business Management, Development managers and Executive Stakeholders.
If you're up to the challenge , it can be one of the most stimulating environments to work in. Nothing can ever be the same , and therefore everything changes , all the time.
A last word of advice : If you don't like your cheese moved, don't become a BA.