October 06, 2011

Ten Best Practices in Requirements Analysis

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.

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 comment 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!


Posted at 01:55 am by Joseph Bachana

Having consulted with Joe, I must add that validating and verifying requirements are absolutely critical.  I find that we often accept inputs from certain Business Process Owners as valid, but we only look at the specific task state as opposed to viewing a complete workflow.  Assumptions are often made, which require re-mapping and solid referencing to ensure that the process is bought into.

http://www.databasepublish.com/comment/reply/1429

 

why do you arranged 10-1 instead of 1-10? do you arrange it by priority? if so, 10 or 1 is most priority?

 Database Publishing Consultants Inc. BBB Business Review

Case study

Drupal Consulting for the Daily Racing Form

DPCI provided Drupal consulting to help the Daily Racing Form to improve the online experience for both newcomers and veteran horse racing enthusiasts. > more

All case studies


Press Release

DPCI Celebrates its 15th anniversary on April 27th, 2014. "I attribute our success to a singular focus on content technologies and on constantly looking to optimize our operations,"; states Joe Bachana, President and founder of the company. more
Alltop, all the top stories