Hi Shiro,

Here's a method that I used and which worked very well (assuming you don't have a requirements management tool):

• Create your functional requirements document for release 1.0 (or any other analysis artifact for that release).

• Give the document a name which clearly identifies it as documenting a given release:
  • It could be numbering based such as: ACME System - Functional Requirements R1.0
  • It could be using the date of the release such as: ACME System - Functional Requirements 2014-08 (I prefer this one myself since it tells everybody how old/new the release is/was).

• When you are ready to create your requirements for release 2 you make a copy of the R1.0 version can call it 2.0
  • If using a standard word processor such as MS Word you can use the "Track Changes" feature to clearly show the differences from the previous release
  • I also like to maintain an internal revision history table to track intermediate versions for a given release

• After 3 releases would have three documents, something like this (assuming monthly releases):
  • ACME System - Functional Requirements 2014-08 (This could the version for the code in Production)
  • ACME System - Functional Requirements 2014-09 (This could be the version for the code in QA)
  • ACME System - Functional Requirements 2014-10 (This could be the version the analyst is still working on for the future release)

This process can work regardless of how often your organization releases code to production or how many changes you need to make for a given release.

Now you have a good baseline for future changes. Consider these scenarios:

• You need to make a document changes due to a defect which needs to be fixed in the Production environment:
  • Make changes to the "... 2014-08" version and give it to the development team (this represents the change to production).
  • Apply the same change to the "... 2014-09" and to the "... 2014-10" versions.  This is because if the defect is in the production code, it's most likely in the other code pipelines.  You don't want to fix a defect in production and then have it re-appear when the next release is deployed, do you?

• If you are adding a last minute feature to the code in QA:
  
  • Make changes to the "... 2014-09" and to the "... 2014-10" versions.
  • Again, the changes to the "... 2014-10" version is to ensure the feature is there in the future release.  The development team, following good coding practices, will merge the change to 2014-09 change into the 2014-10 code base.

I hope you get the picture.

A couple more points:​

• Using a version control system for your documents allows you to track multiple versions of the same document even for the same release.  Ideally, you should be able to use the same version control software that your dev team uses (ex: Team Foundation Server).
• It is very helpful to also use an Application Lifecycle Management (ALM) tool which you can use to submit and track work orders from SA, to Dev, to QA, to Production.  When you're ready to deliver a given version of the artifact to dev/qa, you enter the ALM tracking ID in your revision history of the document.
• If you use a "track changes" type feature in your word processor then don't forget to "accept/clear" tracking before you begin tracking again for the next request to be submitted to the development team.

Hope this makes sense!

Adrian

Great suggestion, Adrian!

Another way to consider is to depend on whether the release differences from last release is big or small: some might just have small upgrades based on previous release; some might have totally new modules or too many new functionalities from previous one. If it is the second situation, creating another document and referencing back to previous doc when necessary might be easier to maintain.

If it is one document, it might help to add a column indicating the release this requirement is hope for, ex. Nice-to-have/R1, Must-have/R2; So that even in later release versions, you have an idea in which release the requirement is first delivered.