Forums for the Business Analyst

  Modern Analyst Forums  Business and Sy...  Requirements  Requirements for multiple releases
Previous Previous
Next Next
New Post 8/3/2014 1:26 AM
User is offline Shiro
5 posts
10th Level Poster

Requirements for multiple releases 

Hi there,

When documenting requirements in a project with multiple releases (e.g. rel 1.0, 1.1, 1.2 etc), would it be acceptable to make a reference in the requirement documents of later releases to the requirements document of the previous releases or should you keep combining the requirement documents so there is only 1 document for all releases?

Your help is much appreciated.



New Post 8/5/2014 12:08 AM
Accepted Answer 
User is offline Adrian M.
762 posts
3rd Level Poster

Re: Requirements for multiple releases 

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 Marchis
Business Analyst Community Blog - Post your thoughts!
New Post 8/8/2014 6:03 PM
User is offline Shiro
5 posts
10th Level Poster

Re: Requirements for multiple releases 

Many Thanks Adrian.

Your help is much appreciated. I understand what you say.




New Post 9/8/2014 12:30 PM
User is offline Irene
31 posts
9th Level Poster

Re: Requirements for multiple releases 

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.

Previous Previous
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Requirements for multiple releases

Community Blog - Latest Posts

Context:  Intro Change Request Definition Reasons for CRs Adaptive, predictive and mixed projects Flow of processing change requests Change Management Workflow Tools and Techniques 1. Intro  The World will never stop changing, as well as human needs and desires. The business environment evolves continually. An or...
For many people, a career in business systems analysis can be an ideal opportunity to use their skills in technology and business. Business systems analysts bring together the best of both worlds – technical know-how and business acumen – to help organizations become more efficient and effective. Here are some of the key benefits of pur...
There is no doubt in my mind that curiosity nurtures the mind when it comes to T shaped skills.  T shaped professional are specialist in something(the vertical line) and also have a wide range of skills and knowledge in a broad range of subjects(the horizontal line) and are are highly sought after in the workplace.  I’ve recently...



Copyright 2006-2023 by Modern Analyst Media LLC