I was recently teaching a new BA, helping her to analyse an existing system, prior to it being upgraded.

I taught her how to write use cases and create a domain model.  A good starter-set of BA tools for a newbie.

Later in the week, she came to me having struggled for several hours to write a use case for a tricky bit of the user experience. It was a highly modal bit of UI, with the behavior being different for each of several types of user, and also changed based on the state of the users account. She’d done a few use cases, but they all had lots of if/then/else ideas in them, and none gave a good picture of what was required. And neither of us could figure out if we’d missed anything, and that’s a BIG problem.

  • After all, the ‘Analysis’ part of the BA job title makes us look for ‘gaps, overlaps and inconsistencies‘, and we couldn’t be sure of seeing any at all.

I decided to create a state model for the user and their account. Sure enough, ten minutes thinking about the account states, and how they linked together, had us spotting the error – a missing Use Case, and another variable in the account domain class.

But I was surprised by he next question: how did you know to stop writing use cases and draw a state diagram?

[thinks]

Because I’ve been doing this for 15 years, and I know that if I’m going round in circles with one technique, and not learning anything, then it probably means I’m using the wrong technique.

So I stop. Look at the problem, and think which technique to use next. And with experience, I probably get it right second time. Or third maybe. Either way, change of technique nearly always delivers new insights.

All of which made me think about how I would differentiate between an OK BA and a good one.

  • An OK one would continue doing use cases, because they have been taught to write use cases, and told to write use cases by someone higher up.
  • A good one would spot they weren’t making progress, and switch.
  • A great BA would get it right first time, and save lots of effort.

The good news is that this can be taught – you don’t need 15 years experience to get good. When you find yourself at a standstill,

  • consciously step back and examine your set of BA techniques,
  • think about why the current one isn’t working, and which other might work better.
  • make a note somewhere of the characteristics which lead to your decision. With time, you’ll improve.

But the most important thing is to continuously add to your set of techniques. At first your list will grow quickly, but its never complete: there are always more to learn.

And as you learn new ones, try to also learn when it’s time to give up.

 

About the Author Ian Mitchell

Ian Mitchell is a business analyst and software developer. He's been using UML since before it was UML, and has managed teams of BAs all over the place. He also teaches UML and BPMN, and writes the eaDocX document generator for the Sparx EA tool.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s