UML Business Analyst Solutions

I still meet people, usually at industry conferences – who are ‘not into’ modelling. They think its some sort of high-powered, ivory tower exercise, involving creating lots of unnecessary diagrams which aren’t useful.

Sometimes I take the time to persuade these people, and this is the argument I use. It’s specific to Business Analysis, which is what I do, but the same argument can be modified for other roles which use modelling.

Start with – “what’s your job?“. If the answer is Business Analysts or even their new big brothers “Enterprise Architects” then ask “what’s the purpose or ‘added value’ of your job?“.

If the answer from the BA is ‘I write down all the requirements, then feed them back to stakeholders‘ then give up – this person isn’t a BA: they are a secretary, and may never get what you’re talking about. Replace them with a Dictaphone.

Of the rest – thankfully the majority – most will come up with some variation of:

“My job is to look for the gaps, overlaps and inconsistencies in what is being requested“. This is the best summary I know for what I do as a BA.

So how do we do this? If the problem is small then this might be done by just screwing up your face, reading everything about the problem, thinking hard, and writing down what’s missing, where the overlaps are, and what’s inconsistent.

Not many problems are this small. If they were, they probably wouldn’t need a BA. So we’re left with the awkward, bigger problems, and here’s where the good BA gets organised. I seem to follow 3 steps:

1. Categorize and sort it – take what you find out, and put into piles of similar knowledge. Requirements, assumptions, stakeholders, software systems. All of these get mentioned, I need to decide what a piece of knowledge is. Without this, I can’t do the next step.
2. Model it – this means taking the piles of similar-styled knowledge, and linking things to other things. So stakeholders get hooked-up to Requirements because they ‘own’ them. Use cases get put inside Software systems, because the one implements the other.
3. Think about it – which is where we really earn our money. So far, (1) and (2) have resulted in some nice diagrams, and lists of things. But no value-add.

Now I can start to look for gaps, overlaps and inconsistencies, and, if I’ve put all these things, relationships and diagrams into a model, I can get the model to do the work.