Using Confluence I put together a series of PRDs for a future release. Each PRD describes a functional 'unit' of the application, such as 'editor', 'user management', 'customer management', etc. Using the built-in Product Requirements Document, I set the Target Release (e.g. "v1") for each PRD. Following the MoSCoW method I then set the Importance for each Requirement. All of this follows pretty closely the very helpful guide provided by Confluence Support.
The problem then becomes, how does one set a list of requirements for the next release (e.g. "v2")?
If the PRD descibes a functional unit, it will invariably contain requirements for different releases (it won't be 'done' when that version ships), so it's odd that there's a Target Release for the entire PRD. It seems like it would make more sense to target versions for each requirement in the PRD, which the MoSCow method emulates in a way, but it's not the same thing.
One way to address this might be to have a different PRD for each funtional unit + version, such as 'editor v1' and 'editor v2'. The problem here is that there's likely duplication of requirements: something with is "could have" for v1 might be "should have" for v2 and "must have" for v3. This feels messy. Also, it seems to run counter to the notion of a Target Release for the PRD. The Confluence Support guide linked to above has a PRD called "Android App v1 Requirements" with a Target Release of... wait for it... "1.0". This seems at best redundant and at worst confusing.
Another way to address this might be to leave the PRDs the way they are, and when the version is released, update the Target Release and the Importance for each of the remaining Requirements for each PRD. So, once v1 is out the door, change the 'editor' Target Release to "v2", remove the requirements that shipped and bump up the Importance of the requirements that are still there. The problem here is that visibility is limited to the next release. Perhaps this is fine, but if you're doing any sort of Roadmap it might be nice to offer guidance around requirements for a number of different versions comming down the pipe.
Yet a third option might be to have separate documents for each version and list the requirements for each, perhaps even linking back to the PRDs. So there could be a "v1 requirements" page with a 'editor' section that lists all the "must haves" for this release, and then a "v2 requirements" page, etc. The problem here is that this seems like a lot of duplication which could potentially become messy. Not only do you have to keep track of each requirements on the PRD, but you have to have track them all on each version requirements page.
This seems like there should be a straight-forward way to do this, but I've looked off and on for weeks and can't seem to find anything that outlines a procedure for handling this sort of thing while using Confluence's Product Requirements Docs. I like my third option the best because it seems most consistent with the tools provided by Confluence, but I'd like to hear other opinions.