Ten Best Practices in Requirements Analysis

In any event, I just gave a two day seminar on best practices in requirements analysis at a client down in Louisville, so I prepared this top ten list for them. I thought I'd share it here with you - please feel free to contact me if you think I'm missing any. Always happy to hear more tips!

10. Create Visual prototypes of interfaces in a storyboard fashion. Much of what we do as IT professionals is hard to understand by business stakeholders, who appreciate visual depictions of the systems and tools they will be using.

9. Meet with as many stakeholders as you can as many times as you need in order to gather your requirements.

8. The most vocal people don't always know the most. If you are only holding requirements workshops or brainstorming meetings, you may be missing out on great ideas from shy people. Consider the Nominal Group Technique, or perhaps even just one-on-one interviews.

7. A requirement must have only ONE requirement in it. If there is the word "and" in your requirement, it is not testable thus invalid.

6. Be specific about what you need – using flowery language in a requirement only creates ambiguity. For instance, who are you really helping if you write a requirement as "system must be user-friendly?" Sure, you could write it "system must be easy to use" but who are you fooling? It is untestable and not actionable, so invalid.

5. The nature of functional analysis requires 'progressive elaboration' -- You will have to go back to your stakeholders to VALIDATE their requirements, and that is perfectly normal. Tell them in advance that you have to do this so they don't think that you are an idiot for coming back for clarification

4. Continue to invest in your internal functional analysis capabilities through training, best-practice process documentation. With each step toward improving your methodology you will gain commensurate benefits in the speed and accuracy with which you implement IT solutions, both as an individual and together with your team.

3. Don’t forget to create use cases, or workflow diagrams - VERY important to understand how people must interact with a new system.

2. Start from a base template for your solution requirements document. A good place to start is the IEEE conOps, although it is NOT suitable for every project, certainly not smaller ones. You can create your own variant of it to suit your needs.

1. There will be conflicts among how people see a requirement. Make sure you help facilitate agreement, or that conflict will rear its ugly head after implementation, up to and including project failure. Be mindful of your emotions/adrenaline, since you naturally will have a vested interest in the project's success, which may affect your ability to be composed in the face of conflict. The analyst on duty is the one that needs to reconcile the conflicts in a project, for the good of the team and the project. Be Courageous!

-Written by Joe Bachana, CEO of DPCI, October 6, 2011

I have been going on this year about a eureka moment I had in the Fall of 2010 regarding what separated companies that seemed to hit all of their IT initiatives out of the ballpark from those companies that struggle nearly almost every time. Many of these peer organizations did quality work around project management and practiced some SDLC, be it Agile or Waterfall. However, the analytical portion of the business seems to really make it all click together. The sun rose that day when I realized that great-quality requirements analysis was what differentiated those high-achieving companies from the others.