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 12: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/4/2014 11:08 PM
Accepted Answer 
User is offline Adrian M.
764 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 5: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 11:30 AM
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

In today's dynamic business environment, mastering effective business analysis techniques is crucial for organizations aiming to achieve sustainable growth and competitive advantage. Business analysis involves the systematic evaluation of business processes, requirements, and strategies to uncover insights that drive informed decision-making. T...
For many years now, a lot of people have found it difficult to identify the difference between Sankey diagrams and parallel sets. The two have made headlines, given that most people find it challenging to note what makes them different from each other. What remains to be undeniable is the fact that the Sankey diagram is among the top data visualiza...
Hosted by Deirdre Caren on Agora Insight's Blueprints for Success - Business Architecture and AI In our recent conversation with Joseph Edward, we explored the transformative power of business architecture (BA) and technology as tools for uplifting communities. Joseph, with his rich background spanning from education to IT leadership, shared...



Copyright 2006-2024 by Modern Analyst Media LLC