Posted by tac_admin, July 22, 2012

Success and Failures in Business Analysis Requirements

There was a discussion in the IIBA group on LinkedIn titled “What is your #1 tip for requirements success in business analysis” and I wanted to expand on that topic and also look at requirements failures.

In my response on LinkedIn I said that I felt the most important factor in requirements success comes in the requirements elicitation area. Specifically that we need the ability to analyze the requirements quickly and know when to dig deeper. As BAs we need to analyze the requirements while they are being given to us so that we follow-up on the spot with questions that dig deeper when needed to get to the root or “real” requirement.

I really wanted to have two tips in the number one spot; the other would be to have a deep and clear understanding of the business area and what pain points they have today.

This of course also got me thinking about requirements failures. So many times we’re rolling along through the project, life is good, were on time, on budget, and everyone is happy. Then we get to testing and the business starts using the application and all of the sudden they are saying the application doesn’t function the way they expected, there’s too many bugs, things are missing, etc.

The BA is shocked at this point and walking around saying “I don’t get it. They said my business requirements document was great. Everyone signed off on it, how can they come back now and say we missed functionality and things aren’t working the way they expected?”

What would be the number one cause of requirements failure?

The easiest answer would be the opposite of the number one success – not analyzing and getting to the root business requirements.

However, when I gave this more thought, I think we could have a different number one for failure: Not ensuring the business team truly understood what would be built for them based on the requirements.

How do we get the business to truly understand what they’ll be getting? Provide future business process flows (pictures), provide screen mock-ups (pictures), provide UI designs (pictures). Requirements in text format definitely have their place and there is no doubt we need them documented in this fashion and the business does need to review and approve them, but I think the various ways of documenting them in a picture format are also critical to giving the business a visual representation of what they can expect and this will oftentimes bring out missed requirements earlier in the process and will also help the business to have a true understanding of what they are getting.

I welcome your comments and perspective on this subject. Please feel free to post your thoughts!



Leave a Reply

Your email address will not be published. Required fields are marked *

Get in touch today

Speak directly with The Analyst Coach
and get pointed in the right direction.

Preferred Contact EmailPhone

Subscribe to receive our free white paper on how weak requirements effect strong companies


Sign up to get your FREE Business Analyst Survival Guide

Don't worry, we hate spam too. We will never share your information to third parties.