Documenting things a solution won't do is similar to documenting items that are specifically out of scope for a project - you do it to remove ambiguity and reduce the possibility of scope creep if certain features have already been assessed and a decision has been made on whether they are in or out.
It is better to state requirements in the positive. For instance:
This is what most people mean when they say to document what the system does instead of what it doesn't do.
What you are describing is not the same thing. You need a feature list that states which features are offered in each version of the application.
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: