Skip Navigation LinksForums > SpiraTeam Forums > SpiraTeam Best Practices > Deprecating old requireme...

Deprecating old requirements RSS Feed

Tuesday, January 24, 2012
If RQ123, implemented as part of Release 1.0, is being removed as part of Release 2.0, what is the preferred way of handling this in SpiraTeam? I see that requirements can be marked "Obsolete". But how do you track that the requirement removal work is being performed as a requirement for Release 2.0? Is it best to create a separate requirement for this new work? Something rubs me the wrong way about having a requirement that specifies that some bit of functionality should be removed from the system.
2 Replies
Adam SAdam S
re: Greg Ferreri on Tuesday, January 24, 2012
Friday, January 27, 2012
That's probably the best way to do it for now. We're considering adding a "removed in release" field to requirements to better capture this.
Andy SmithAndy Smith
re: Adam S on Friday, January 27, 2012
Monday, October 1, 2012
Hi Adam

I agree with Greg that creating an RQ that simply relates to the removal of another RQ is a bit strange.

Adding a "removed in release" field to requirements would be great.

Have you considered this any further in your roadmapping?

  • Started: 1/24/2012
  • Last Reply: 10/1/2012
  • Replies: 2
  • Views: 3331
Powered by KronoDesk v1.1.0.15 | © Copyright Inflectra Corporation 2011-2017 | Licensed to Inflectra Corporation.