How can I get our BAs to provide business requirements, and stop confusing them with implementation

Question

Our BAs (Business Analysts) have an annoying habit of providing us with system requirements, rather than business requirements. Often times, they don't even know what the business requirement is.

It infuriates me, because I see a list of requirements, and it will be tied to the way it should be implemented, rather than the problem that should be solved.

A very contrived example would be, "System should email customer an order confirmation." instead of "The customer needs to be informed that the order is confirmed."

Granted, in this case, it will likely be an email. However, there is a chance we make a business decision to be more personable and want to follow up orders with phone calls to verify they found everything they were looking for, etc...

Other examples are more insidious. I was working with something that handled reallocating distribution to different locations based on sales. The order is initially placed sending $X amount to store X, $Y amount to store Y, and $Z amount to store Z. However, 6 months had passed from the initial order, and we see that store Z is now outperforming store Y, who's sales have dropped. We want to swap the goods we are distribution between the stores. The business rules I were given were tied very closely to the implementation, and in many case, where X->Y, Y->Z and Z->X no swaps would occur, even though our eyes can see that we are literally just shuffling goods between stores.

So I suggested a new approach, queu up the orders we have, sort them, sort the stores based on sales, and then rematch the lists that way. Ensuring the best selling stores get the largest orders.

However, because I don't actually know the business rule, and just know the shuffling algorithm I was given, which seems incorrect, fixing it involves going back to the users, and getting the business rules...which should have been done in the first place.

What I'm asking is, is there a trick to gathering good requirements that are based upon business rules? How can I get the BAs to do this, when they aren't already. I'm having a hard time know explaining the difference between business and system rules...and they clearly aren't grasping it. How can I educate, and improve their abilities?

Answer 1

Change the format. Traditional functional requirements are pretty flawed and have decades of focusing on the "what" and not the "why" or the "who."

User Stories and User Persona based requirements focus on the "who" and the "why." While agile is the most obvious user of this today, it's not a new concept. I first learned about this concept through a product management methodology from the 1990's call "Building a Market Focused Organization."

Take US Banks in the 70's and 80's. In their efforts to become more competitive in post deregulation era they went out to their customers. They didn't start with what to do, they started with asking the customers questions. Then they looked at what the customers said "Longer hours, more tellers." and asked how they could solve this (without spending the $ on longer hours and more tellers). The outshoot was to leverage a technology that had been around since the mid-60's but had languished as a gadget without a true market. And so came to pass ATMs.

So use User Personas and User Stories. Mike Cohn has published two very good books on this topic that I highly recommend.

I recently did a two part blog on using agile practices at the product requirements level, to drive useable requirements. If you're interested in it, my blog is linked in my profile. Look for the "Garbage in, Gorilla out" and "How much is that gorilla in the window" blogs.

Answer 2

Not sure whether you would have the chance, time and resources to reject existing requirements and get them rewritten based on a more business usage perspective.

If you have the opportunity, try to work with the relevant manager and build together a Business Request / Change Request Form (depending on the type of action) Template for future demands. This template should incorporate all relevant information from the requester's name, dates, specifications required and end user expectations. You can add as many fields as you need to gather the information that is convenient for you.

Try to focus his attention on the "end usage" or "business expectation" sections where the analyst will have to describe concisely the expected output. Get this manager to agree the format with you (so in the future it will not consider a rejection as something personal) and provide examples of desired input in the template so they just have to overwrite it.

If they submit their requests via email attaching the form properly populated at least you'll get a robust mechanism that can enable you to rejected straight forward any request that does not meet the agreed criteria.

Just bear in mind that the improvement won't happen from one day to another and you need to work with them so they provide you with the right information, but providing to them a feasible solution will help to achieve what your goal.

I have found an article related to documenting business requirements that includes additional insights:

Documenting Business Requirements

Answer 3

There is no trick. Writing a requirement with the appropriate wording, at the right level of abstraction, without including the solution require a bit of skill, analysis, and thought. It is what the BA is supposed to do for you. Grasping the concept is simple, actualy writing it is a bit more difficult. If your employee in this role cannot even grasp the concept, then you have the wrong person or persons. Take a look at your knowledge/skill requirements you have for this role, rewrite them, then go find new talent. Looking for a "trick" is a non starter.

EDIT: I might be in favor of kicking back the work. In a process, the next step is triggered by the output of the previous step. The previous step has finish criteria that says the work here is finished. Similarly, the next step has entry criteria, against which the input from the previous step is tested to ensure fit for service. If it fails, it is rejected and the subsequent step does not start.

Kicking the BA's work back will likely cause a bit of a stir in your organizaiton, but it is a symptom of a problem in your process and might be the fastest way, albeit politically risky, to get it fixed for good, e.g., BA is replaced.

Answer 4

Lead by example. Either do a few good ones yourself to share, or hire a rock star. You also have to figure out why these folks are lacking. Many BAs do the job because they love the business they are in. Others do it because they aren't technical enough to program. The latter group focuses on how rather than what or why because they don't know better.