ANSWER

Analysis Paralysis is the dreaded black hole of projects. So, how do you recognize that you might be in Analysis Paralysis.  Here are a few symptoms that might clue you in.

• Requirements development seems to carry on forever
• New versions of the system requirements document are continually getting released with a feeling of churn on the same requirements 
• Substantial requirement changes are getting introduced into the business requirements document long after they were thought to be baselined
• All requirements have been documented in multiple ways using a lot of different models just for the sake of "completeness" but without added any real additional clarity
• The team has been instructed that no coding can start until the requirements are "done"

If you notice you are in analysis paralysis, or better yet in order to avoid it from the start, here are some things you can do:

• Remember that your end product isn't a requirements document, it's software.
• Choose an appropriate SDLC based on your project, timeline, team culture, etc.  Some projects work fine with a traditional waterfall approach, while others do not. 
• Your requirements are never going to be perfect. Strive for "good enough" while ensuring you have avoided major gaps in requirements.  Decide upfront as a team when requirements are considered "good enough" and how you will define "good enough".  Ask things like, what is an acceptable amount of risk before determining to proceed with development? Determine who will review the requirements and be part of the decision making process that they are "good enough".  This may include the business analysts, customers, internal stakeholders, developers, and testers.
• Don't model everything "just because".  Model things that are complex, where written language falls short.
• Don't include UI designs early on in the requirements spec. Wait until you are closer to the end and in the "design" portion of your SDLC.

These are a few things that can really help avoid Analysis Paralysis, but it's hardly an all inclusive list. 

[This answer was derived from a talk given by Karl Weigers on Software Requirement Pitfalls.]

--
Chris Adams
LinkedIn Profile