If ever I think I know everything I spend a little time talking to my eight year old daughter. She's very good at asking questions I can't answer, or at least have to think hard about. The thinking hard bit is important because she cuts through bullshit quickly. When she was five and her mother had been sending her to Sunday School, out of the blue one day she asked me:

"If God made us, and God loves us, why would God let us get sick?"

What would you have said? I squeaked by this one but "ask your mother" has limited effectiveness. When she asks me about my work I have to give her real answers and frame them in a way that makes sense to her. Recently she wanted to know if everyone who worked with computers was a programmer.

"No," I responded. "I'm not, I'm a Business Analyst."

"Do you know how to program computers?"

"Not really, no."

"And it's the programmers who make the computer work?"

"Basically, yes."

"So why do programmers need you?"

"That's what they keep saying to me."

"I'm serious Daddy, what do you do?"

"I write the business requirements. I work with the programmers to make sure the computer ends up doing the right thing."

"Does that mean you're in charge?"

"I wish. First, I talk to the people in charge about what they want. I work out what their requirements are, that's why we call it business requirements."

"Don't they know what they want?"

"Not always."

"That's silly, everyone knows what they want."

"Not always. And people aren't always good at explaining to someone else what they want. How about if I told you I wanted you to buy me a car, what car would you get me?"

"Ummm, a Smart car, they're cute."

"That's too small for me."

"Then I'll get you a 4WD."

That's too big and slow. I want something faster."

"I'll get you a Porsche."

"I don't have enough money for that."

"Well, what sort of car will I get you?"

"See, now you're asking me about my requirements. I want a Volkswagen Passat."

"OK, I'll get you that."

"What colour did you get me?"

"Red."

"I don't want red, I want black."

"Why didn't you say so?"

"You didn't ask."

"Is this what you have to do all day?"

"Pretty much, yeah."

"No wonder you're angry all the time."

"I AM NOT ANGRY ALL THE TIME! See, this is what I have to do – ask the right questions. The programmer is like the car dealer, they can get you whatever car you want. All you have to do is be clear about what car you want. It's like in Shrek, when Shrek said ogres are like onions because they have layers. Requirements have layers and I have to pull them off one layer at a time to get to the middle. Then I know what to tell the programmers."

"So the people you work with are like onions?"

"I guess."

"Do they stink?" Gotta love 8 year old humour.

"That's a bit harsh."

"Do they make you cry?"

"Sometimes I come close. Usually they make me want to scream."

"So they really are like an ogre? They're scary!"

Sometimes they are very scary. And I know I don't want to find one of them under my bed.

I love this explanation and I fully intend to steal it when my daughter decides that she cares what I do all day (she’s only three at the moment). The one thing you missed though is the other side, not just asking the questions, but making sure that the programmers don’t go out and make a Hummer while you’re still getting the answers.
Most of the programmers that I have to deal with have already decided how they’re going to build the relational database before we’ve even told them what the project’s called.

You write: “Unless you’re from a very big consultancy…” You then go onto describe what most Big-5 consultancies actually do, by my estimation. Actually what they do is more like deliver a skateboard and charge for an aircraft carrier. And then it’s a skateboard that the customer could have gotten from their own storage closet.

In my experience, customers don’t know what they want until they see something. So it’s important to show them something quickly, forcing you to build fully functioning but incomplete systems. Preferably daily. So they can twist the knobs and change their minds, keeping in mind that cost of change isn’t free. In other words, deliver features as high risk / low criticality elements to your system as often as possible. Then the business analyst can actually do their jobs, which is to measure the efficacy of the system instead of playing something like the children’s game of “telephone” which is what I see most of them doing. And from the sound of it, this is essentially what you end up doing, too.

Requirements aren’t about how computers work or how programming works. It about the results users need to get from a system. Programmers are far more often than not the WORST people for defining user requirements.