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
Resolved
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.

Cheers

Shiro

 
New Post 8/5/2014 12:08 AM
Accepted Answer 
User is offline Adrian M.
726 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


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.

 

Cheers

Shiro

 
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

Digvijaybook
Digvijaybook
Analytics is the future of the business industry. Businesses and organizations today run on data and its interpretation. Its correct evaluation is the fundamental key to success. And business analysts are the guides to it. It is a very prosperous industry and has a lot of potential for talented people. To even qualify, you require more than just...
2 Responses
Samuel02
Samuel02
With the advent of modern-day cloud infrastructure, many business-critical applications like databases, ERPs, Marketing applications have all moved to the cloud. With this, most of the business-critical data now reside in the cloud. Now that all the business data resides on the cloud, companies need a data warehouse that can seamlessly store the da...
0 Responses
BPM_online
BPM_online
Bpm'online, a global business software company leading in the space of low-code, process automation, and CRM, will be soon announcing their new company name. The new name will be launched in the sky via a breathtaking skydiving performance involving 160 bpm’online employees, including the CEO. The new name of bpm’online is to be fo...
0 Responses




Latest Articles

Copyright 2006-2019 by Modern Analyst Media LLC