When discussing software requirements documentation, a very common question asked is "When is a software specification complete?" This is a very subjective question, and answers are often as far apart as discussions comparing waterfall to agile software development methodologies. I like to break the discussion into two parts.
- When is requirements elicitation complete?
- When is requirements elaboration complete?
If you split the question and look at the issue in this way, you can at least get to a non-subjective half answer. I know... what a terrible result. But the truth is sometimes like that. The answer to question 1 is still subjective, but at least we have succeeded in identifying a more specific point to discuss. The answer to question 2 is far less subjective. In fact, removing arguments based on the quality of the elaboration work product, one could argue that answering question 2 is absolutely non-subjective. Requirements elaboration completeness is identified when all elicited requirements are described sufficiently to transfer understanding of the requirement to the software documentation reader. In other words, when each requirement is checked as complete by the software documentation author, and agreed as complete by stakeholder reviewers.
The Requirements Elicitation Completeness Conundrum
Question 1 is much harder to identify. The inability to identify the answer to this question, and the frustrations of teams that have tried, is a huge contributor to the industry-wide recognition of agile methodologies as a potential better way to work software projects. Any attempt at identifying completeness can only take into account known issues. You simply don't know what you haven't yet discovered, and the best advice in assessing requirements completeness is to acknowledge this simple truth. Don't get hung up on it. Diligently attempt to elicit the known requirements, and plan to iterate early and often in order to catch the unknown requirements.
It can become very costly when we try to completely identify all requirements of a software project up front. This cost is not just in the analysis time we spend chasing perfection, but also in all the requirements that are identified in our quest, but are not really requirements. These requirements turn into software features that are developed, but never used.
Software teams should expend reasonable resources in identifying known requirements up front, elaborate those requirements to completeness, then recognize and embrace requirements change that comes from iterative understanding of the problem domain and iteratively incorporate changes as the unknowns become known. This is scope creep, but it is not bad, and should be planned for. Your team will fair far better technically and financially when necessary scope creep is expected, planned for, and then analyzed and documented as part of your iterative development process.