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.