How do I know when my requirements spec is done?
That’s the million dollar question formost beginning and many intermediate-level business analysts.
You’ve poured your heart and soul into drafting the perfect requirements specification. You’ve checked, doubled checked, and triple checked every syllable of the document for clarity, spelling, testability. You have full traceability to every business requirement. You’ve been extra, extra careful not to tread in the domain of design. Your spec is rock solid.
So, why, after 5 review sessions with project stakeholders and document consumers, are you still making edits?
Why does it seem like at this rate it’ll probably take another 5 before you even dare think to ask for sign-off?
The answer is simple. Your project is stuck in Analysis Paralysis.
Per Answers.com, [a]nalysis paralysis is an informal phrase applied to when the opportunity cost of decision analysis exceeds the benefits.
Karl Wiegers defines the dreaded ailment in these terms:
If requirements development seems to go on forever, you might be a victim of analysis paralysis. Though less common than skimping on the requirements process, analysis paralysis results when the viewpoint prevails that construction cannot begin until the [requirements specification] is complete and perfect. New versions of the SRS are released so frequently that version numbers resemble IP addresses, and a requirements baseline is never established. All requirements are modeled six ways from Sunday, the entire system is prototyped, and development is held up until all requirement changes cease.
The solution? You simply need to concede (and then convince your product team) that baselining a perfect , polished, and 100% complete spec during the analysis phase is likely not a realistic target. In fact, I’d argue that unless the project is very, very simple, there will always be edits and clarifications to make to requirements throughout the project as new information is gathered. Per Wiegers, perfection in analysis isn’t the goal:
Your goal is not to create a perfect [requirements specification], but to develop a set of clearly expressed requirements that permit development to proceed at acceptable risk. If some requirements are uncertain, select an appropriate development lifecycle that will let you implement portions of the requirements as they become well understood.
This is where, as the requirements analyst, it becomes important to have at least these 2 key things working for you; 1] a solid, trust based relationship with your business stakeholders and the consumers of your document and 2] an agile software engineering methodology that includes a functional and reliable change control process.
You need the trust of your business owner and downstream teams so they’ll rely on you to work dilligently with them to close remaining functional gaps as quickly as possible so the project can proceed with a manageable level of risk. I’ve seen instances where customers and/or development teams force a project into paralysis for fear that if they sign-off on a less-than-perfect document, the customer will end up with an incomplete or inferior product, or that the development team will get hammered for not delivering an acceptable product because the analyst would “disengage” once he/she got a signed spec, and would not help fill in the remaining “TBD”‘s.
You need an flexible methodology that supports occasional edits for clarification throughout the SDLC to ensure that filling in a few, necessary gaps for TBD’s won’t throw the project into a tailspin. Even if you have the trust of the customer and downstream delivery teams, you need a change management process that facilitates communication of changes to requirements across all impacted teams. and that ensures that all requirement changes outside of the analysis phase are evaluated for necessity and costs in terms of time and money to ward off scope creep.
All this is not to say that it isn’t a good thing to work for perfection from the first draft. Just as the analyst deserves a measure of grace for not having a “perfect” spec at the end of analysis, the developers and business stakeholders deserve the courtesy of receiving a well-conceived, concise document with only those mutually agreed upon items that remain to be completed.
So, now that you know the symptoms and the cure of analysis paralysis, it’s time to put them to good use.
I’ll be glad to hear any thoughts or commentary from readers on your own dealings with analysis paralysis.
Have you considered xP for such kind of projects?
No, I’m not sure I know what that is.. Is it a project management suite? XPlanner or XP-Project or something?
Honestly, I’d like to get to know more about some of the available tools for lifecycle management..
Hey J!
Oh how many times i have been in this situation! However, there are ways of getting out of it, forget the waterfall model, requirements up front etc. I usually do a couple of requirements sessions with clients, this inculdes rich pictures, use case models, DFD’s, even SWOT and PEST sometimes dependign on the project, activity diagrams etc. Having done that i write my users stories WITH the client we prioritise them and start development and deliver a the project in chunks (iterations) every 2 weeks (ususally). This way i dont really worry too much if i got the requirements 100% correct, since updating and adding to the user sotires/cases is ongoing and parallel to the development. You can say that i use a mixture of methods XP/RAD/RUP/EVO etc.