How to convince your BA to drop out of the Tony Montana School of Business Analysis

BAs and cocaine…they go together (from what I’ve seen from most requirements documents) like developers and coffee, and sales executives and three-hundred-dollar lunches. Unfortunately just because your BA does a bad job it doesn’t magically remove the need for analysis to happen, somebody’s got to pick up the slack. If you’re a developer then that somebody is probably you, and to be honest you’ve got enough on your plate already, haven’t you. The best outcome for everyone would be if the BAs cleaned up their act and actually did their job. These are some suggestions for how to get your BAs to drop out of the Tony Montana finishing school for BAs, stop smoking crack and start creating clear, unambiguous and actionable requirements. If this doesn’t work try an intervention or rehab.

Side node: Although Tony Montana was a vicious psychopath without any specific technical skills he wasn’t actually a business analyst, per se.

Pay attention to terminology

Ideally all requirements should be written in a language structured around the domain model and used by all team members to connect all the activities of the team with the software. If your BA uses widget and sprocket interchangeably find out if the two have a different meaning or are synonymous. If your BA uses the two interchangeably but your business reps eyes glow with white-hot rage when you confuse the two chances are your BA doesn’t understand the problem domain properly.

Watch out for stuff that’s ‘pretty complicated’

Some problem domains are legitimately complicated. Sometimes people use ‘pretty complicated’ as a synonym for ‘stuff I don’t understand very well’. Knowledge is power, and I’ve seen BAs hold ‘pretty complex’ over the development team as some kind of Ace up their sleeve.

‘The foobaz report is pretty complex, but in practice all you have to do is multiply this value by 10%’.

There are plenty of aspects of software systems that live outside of code, like processes and procedures, policies, human workflow and the stuff that happens in the heads of the people using the system. As a developer you’re on the line to deliver the CODE part of the system, and the business rules and logic you have to encode in the foobaz report are either complex or they aren’t. If you code it up to multiply all the values by 10% it’s not suddenly going to start to show complex emergent behaviour once it gets deployed to production. Drill down into the complexity that needs to be, or can be implemented, and tell them to STFU about the stuff that isn’t/doesn’t/can’t if they keep banging on about it.

Push back on subjective adverbs and adjectives

For example: ‘all pages on the site will load quickly’ is meaningless. Quickly relative to what? Get your BA to re-write this to provide something quantifiable, or get them to remove it.

Push back on motherhood statements

For example: ‘The system will be easy to use’ is ambiguous, and can’t be verified. It adds no value. Best get your BA to remove statements like this altogether.

Get them to think about the negative cases

I’ve read plenty of requirements with little snippets like:

‘if the user has the foobar role and the order has more than one line item they can click on button A to finalize the order’.

This describes the ‘happy path’ well enough, but what about all the un-happy paths? If they don’t have the foobar role what should the button do? Should the user even see it, or should it be disabled? What if the order has no line items? What about zero-dollar line items? What about future-dated orders? Try and train your BA to enumerate the negative cases along with the positive ones, because you’re going to have to build both.

Join forces with the developer’s arch-enemy, the tester!

Testers hate the ambiguous crap that most BAs spew out more than developers, because the personality traits that go towards making them a good tester also make them obsessive-compulsive, detail-oriented, and inclined to be none-to-impressed by prosaic and insubstantial requirements. Wishy-washy requirements are like kryptonite to testers because requirements that can’t be verified can’t be used to raise bugs. Detailed negative cases (the kind I noted above) in the requirements are the bedrock that negative test-cases are built on. Negative test-cases often make up the majority of (sometimes as much as 80%) of the volume of test cases, so without these negative cases testers are not going to feel like they’re giving the system the necessary coverage.

Get them to focus on the What and Why, and stay clear of the How – requirements shouldn’t dictate the implementation

Sometimes if the BA is a former developer, or when an existing system is being replaced BAs will devolve into specifying requirements in prescriptive technical detail. For example:

‘Every night at 12:00 the system will generate a tab delimited file containing the orders from that day that will be FTPd to’

Really? At 12:00, always and forever? Perhaps this other system we need to integrate with has a web-service we can call to keep the two in synch real-time? And what if tony leaves? Best to specify WHAT needs to be achieved form a business perspective (and possibly WHY to give the developers some context when making trade-offs) but steer clear of the HOW.

Sometimes there are real non-functional requirements that effectively dictate the implementation – if your BA is adamant that something needs to be done using a certain technology then perhaps (in a moment of clarity) they’ve done this analysis. Drill down to find out WHY they, on the face of it, seem to be suggesting the most brain-dead technical solution that has ever crawled out of the UML swamp. Even a stopped watch is right twice a day, and one with a substance abuse problem may be right slightly more often. Drill down into the details.

A similar (but worse) variation of over-specifying the implementation based on an existing system is the ‘nobody knows why it does this, but that is what the existing system does so that’s what we’re going to do’ syndrome, also known as ‘cargo cult business analysis’. Here’s a clue – discovering the answer to these questions is what the ‘analysis’ part of business analysis entails. Don’t accept ‘that is what the existing system does’ as a rationale for something.

Document significant decisions & changes

You approach Anthony the BA after a discussion with the business reps. He seems in his usual hyper-alert state, and he has that usual focused, manic stare. It’s 6 weeks out from ‘go-live’ and you have some specific questions about the security model. You feel that some of the requirements are unclear and can be interpreted in two contradictory ways. He rattles off some answers to your questions even though you’re not sure he’s thought through the implications. You try to draw him into a longer conversation about this but he says he’s in a rush, and to just make it happen. What do you do? You go back to your desk and write an email like this:

Subject: Clarification of <Feature name>
Hi Tony, Just confirming the conversation we had re: <Feature name>, in particular <elaboration of your problem/question>. You said <what Tony said goes here>. I’m a little worried that <your concerns/impact of bad decision goes here>. I’m going to proceed on the basis that what you’ve said is correct, but can you verify this ASAP and get back to me either way?
<your name>

Call me an ass-covering whatever, but I’ve been burned by this often enough that it’s almost a reflex now. What if your documentation ‘ownership’ process allows you to update the requirements directly? Why not just run with whatever Anthony said and run with that? Doing it this way if your fears are well-founded someone else might join the dots and realize what you’re on about. If not then you’re giving them visibility of the process. Plus letting Tony or another BA make the updates to the requirements shows that you’re not just making stuff up and then implementing it.

Don’t be fobbed off

Remember that time you stayed up ‘til 3AM in the morning with reflector figuring out how the data contract serializer worked, or debugging that memory leak using WinDBG? Good BAs should be like that but with business processes. Don’t be fobbed off with ‘well, I suppose I could ask the business’.

Further Reading

Writing quality requirements

Role of the Analyst in Agile Projects

Agile Requirements Modelling

Say hello to my little friend

Pingback from

Twitter Trackbacks for

    How to convince your BA to drop out of the Tony Montana School of Business Analysis 
7/07/2010 6:08:37 AM
Great reading JoCo. You hit on quite a few issues that bite any dev who is working in enterprise and LoB apps. But what do you do if you don't have a BA? What is the requirents are unknown? What if you are living in a world if scope-on-a-rope? What can we do to not only cover our asses but actually deliver something meaningful to the clients? I guess what I'm alluding to is that in a lot of cases, a BA is on the wish list, and instead it's the client who is spewing ad-hoc requirements at you as they walk past you in the hall. In essense, they are the BA and should be treated as such when it comes to getting things locked down. Sometimes you have to take a different approach with clarifcation, not only to make sure it happens but to avoid pissing people off in the process. Right now, I'd give my left nut for a full-time BA :) I enjoyed the post mate. Nice work. OJ
7/07/2010 2:18:31 PM
Patrick Klug
Great article Joseph!
8/07/2010 1:32:04 AM
May Levy
How is it going, you really saved me a boat load of time with all the information you have on this website. I found just what that I was searching for I definitely appreciate it
9/07/2010 6:09:50 PM
Pingback from How to convince your BA to drop out of the Tony Montana School of Business Analysis – Domain Talk
19/07/2010 5:55:10 AM
Pingback from Tony Montana | Trends Pics
16/07/2011 6:00:43 AM