There is another good reason for not labeling things as “non-requirements” in a requirements document–it can become a maintenance nightmare. If you are constantly returning to the requirements document after every release to determine which requirements are in scope or out-of-scope, changing the status of a requirement to a “non-requirement” and back again, this is not only a lot of work, but confusing. Furthermore, it makes it difficult to generate a report which indicates which features were implemented in which release (unless this is also explicitly indicated in the requirements document, which is even more work).
So, the original problem is still unsolved–it’s the end of the release and you need to know the difference between the requirements document and the implemented system. The requirements document cannot provide you with this information. What to do? The solution requires some upfront planning at the beginning of the release, but can be more valuable in the long run:
- As soon as the user approves the requirements document, leave the functional requirements document alone. The requirements document should be a list of statements which the customer agrees is true. Don’t label things as non-requirements. A better solution would be to continue to describe the statement as a “requirement”, but ascribe a property to the requirement which indicates its scope (see below).
- Manage all of the functional requirements in a tool. After performing your post-release gap analysis, identify the requirements which fell out of scope for the release, and label them appropriately (in-scope for release 1.x or out-of-scope for release 1.x, etc.). This maintains the statement’s “requirement-ness”, but adds a new attribute to the requirement. This provides you with much more information than calling out a statement as a “non-requirement”, and is much easier to manage in the long run.
- Periodically, review the requirements which have been out of scope and review them against the currently implemented system to determine whether they still make sense, and whether the user would still agree that they are requirements.