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

What are you doing to make sure you get the requirements that you want?

I practiced as a BA for several years at a large company. I will tell you that this is not an uncommon problem that you are having. I can also tell you that the only way It gets fixed is when you and the BA get on the same page.

Yes, the BA is supposed to document the requirements in a manner that is easily consumed by the dev team. The dev team is supposed to produce code that works and doesn't drive support calls (that you do not have to take) also.

Either way, getting requirements to you is only one part of a BA's job. The other part is to get the NON technical senior leaders that hold the checkbook which pays both of you to give requirements that make sense and don't change every week. I can promise you that they do not get your problem at all.

If you start looking for work where the BA is going to be a rockstar you are going to be looking for a lot of work in your career.

Why not get with the BA on the side. After work, for coffee or whatever and help them understand what your needs are. Train them to ask the questions so that they are gathering the requirements in a way that you can consume efficiently. It's a win win for both of you.

Oh, and I coded before I became a BA and still do today so I know why your requirements need to be clean.

Answer 3

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 4

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 5

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.

Answer 6

Focusing on being as impartial as possible, I offer two point of views:

• From the Business Analyst perspective: As already mentioned, he needs to focus on the WHAT. If he's telling HOW, the requirement is not optimal (from a business perspective). There's the definition of optimal requirements (from BABoK): They are expected to be cohesive, complete, consistent, correct, feasible, modifiable, unambiguous and testable. You can use it to find gaps on the requirements.

• From the IT department perspective: The quintessential task of IT is to build according to the requirements. If the BA confirmed with business that what they need is that the "System should email customer an order confirmation" and it's agreed between parts, there's nothing else IT can (nor need!) to do. Business accepted the mail solution.

Now, about the communication flow: If the BA is the channel between IT and business, then:

• The business needs must be transparent to IT or
• IT has some level of access / understanding of business needs

If the former, I strongly believe this question wasn't being raised. So, taking the latter for granted, we have roles intertwined: BA trying to do the work of the Functional Analyst and also the other way round. Who knows... maybe your BA raised a similar question on a BA forum (my IT lead doesn't stop trying to offer different views for the problems I detected).

Success!

Answer 7

What I'm asking is, is there a trick to gathering good requirements that are based upon business rules?

If there is a single trick, it is to ensure you first have a sufficient understanding of who the project is intended to help. Who (or indeed what) benefits from a successful outcome of your project? This is sometimes known as stakeholder analysis or stakeholder mapping. In my experience, a typical IT project has between 20 to 40 stakeholders, all of whom have some kind of interest, direct or indirect, in the project. But of course some are more important than others to the project to keep happy! Hint: direct "users" of the software are but one of these, and almost certainly not the most important (e.g. their bosses?).

Once you have built up a model of the stakeholders, you can start to focus on each in turn and ask: "What is it they do?" and, crucially "What is it about what they do that they need made better?". Document "how they do what they do now" for background information, and definitely capture any ideas they may have on how to improve things. BUT keep these separate and segregated in your specifications.

How can I get the BAs to do this, when they aren't already.

A proven technique to ensure sufficient quality in project artifacts in non-software engineering disciplines is to use inspection techniques coupled with entry / exit criteria. You cannot give an airplane wing technical drawing to the fabrication unit unless you know it has a sufficient level of objective "correctness" (e.g. less than one potential major defect per drawing page).

Some practitioners applied these techniques to software from the 1960's onward (for example, see this book for a collection of previous work). I recommend Gilb's "Agile SQC" sampling - based measurement technique. It will tell you, cheaply and objectively, how many "major defects" (aka "potential bugs") there might be per specification page produced by your BAs. You can then agree as an organisation that it is economically unacceptable to pass requirements specifications to a development team that exceed a given level of defects (e.g. say "10 per page of 300 words"). It really can help to take egos and emotions out of the process.

How can I educate, and improve their abilities?

A wonderful side-effect of using Agile SQC over time, if done correctly, is that it becomes self-improving.

From the Gilb Agile SQC paper:

"Long term, the most effective practical solution is to adopt Agile SQC as part of the corporate process, and most importantly, make sure each individual specification writer takes the defect density criteria (and its 'no exit' consequence) seriously. They will then learn to follow the rules; and as a result will reduce their personal defect injection rate. On average, a personal defect injection rate should fall by about 50% after each experience of using the (Agile) SQC process."