Do non-requirements exist? If so, where do they belong?

Every release cycle, after dev scopes the functional requirements against the release schedule, certain requirements fall out of scope for the release. These requirements are postponed until a future release, or potentially indefinitely. Part of the job of the product manager is to track what is implemented in a given release against what was originally specified by the user. But do statements about scope–including which requirements were implemented in the current release–belong in a requirements document?

Out-of-scope requirements are sometimes referred to as "non-requirements" or "future requirements", and some methodologies propose calling out these "non-requirements" in the functional requirements document. I have two issues with this practice. The first issue is semantic. The second is methodological. Both issues are very closely related, but I'll deal with the semantic issue first: I'm not entirely comfortable with the moniker "non-requirement". At worst, it sounds suspiciously like a term with no referent. At best, it sounds like something that doesn't belong in a requirements document. A requirements document is like a mini-universe. It is inhabited by requirements statements. Requirements are the things that make up the requirements document–much like the physical universe is comprised of physical things. So, I can't make sense of what a "non-requirement" in a requirements document would be anymore than I could make sense of a "non-thing" in the physical world. In short, it gives me existential angst thinking about what a "non-requirement" is (or is not)! Maybe if there were such things as "non-requirements" documents, then "non-requirements" would probably belong in them.

Secondly, the methodological point: A statement’s requirement-ness is binary: a statement is either a requirement or it is not. More specifically, a statement is a requirement if and only if the customer believes that the "System shall..." statement which describes the requirement is true or should be true. A requirements document is prescriptive–it describes what the system should do, not what the system can do in the current or upcoming release. Because of this, the requirements document should be more or less static after the user approves the document. Whether a statement is a requirement is not dependent on whether the requirement is implemented. Granted, there might be other factors which affect a statement's requirement-ness (such as another feature being implemented which makes the older requirement obsolete or nonsensical, or the user changes her mind), but not scope decisions. After all, the customer still likely believes that the "System shall..." statement is true or at least ought to be true–even if it will not be implemented in the next release (or any release at all, for that matter). So calling out out-of-scope requirements as "non-requirements" in a requirements document is not only disparaging to the customer, it is blatantly contradictory.

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:

1. 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).


2. 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.


3. 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.