The short answer is that a software requirements spec is done when you can convince the stakeholders to sign on the dotted line. The long answer is that a requirements specification is truly never done. It should be a living document that is updated throughout the project. As decisions are made or requirements clarified, the Product Manager needs to own managing the changes and keeping the document as complete as possible.
The question of “doneness” often arises when a project is using a traditional waterfall model because everyone wants to know how to determine when the software requirements are complete enough that the project can move on to the next stage. On a recent project, our team members worked with a development team that would not let us move from the requirements stage into design until every last outstanding question was answered because their performance reviews were tied to their ability to hit the schedule that came out of the planning phase. As a result, by the time the requirements were officially complete, the development team was probably over 50% done with their development. Even then, they still refused to sign off on the requirements document and continued to block the project’s formal exit from the requirements phase. We finally got signoff when there were literally zero identified requirements issues (I have never seen this before).
We prefer a model that lets the phases of the development cycle overlap such that it effectively becomes an iterative model. Once a critical mass of requirements are complete enough that the technical team can begin making design decisions (typically 20-30% of the way into the overall requirements effort) the design phase begins. Our experience shows that there will always be some design issues that impact the requirements so it is better to work them out simultaneously rather than trying to perfect the requirements document in advance. However, by the time development starts, the requirements specification should be complete enough for signoff. There will almost always still be outstanding issues, but none of them should be big enough to prevent a formal signoff.
The exceptional issues that are big enough to block signoff are typically ones that have far reaching impact across the application. Examples might be a security system that modifies permissions across the application or a shopping cart that is passed from a catalog module, to a checkout module, to an order status module. In both of these examples it would be important to understand exactly how those pieces should work to ensure that the system doesn’t have to be completely redesigned due to a fundamental change.
Asking whether the requirements are done is actually focusing on the wrong question. The right question to pose is whether the requirements are done enough – do you have enough information to begin the next stage and enough of an understanding of the outstanding issues that still need to be addressed.
