Deprecating old requirements

Tuesday, January 24, 2012
Avatar
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
Friday, January 27, 2012
Avatar
re: gferreri Tuesday, January 24, 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.
Monday, October 1, 2012
Avatar
re: inflectra.david Friday, January 27, 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?

Cheers
Andy
Statistics
  • Started: Tuesday, January 24, 2012
  • Last Reply: Monday, October 1, 2012
  • Replies: 2
  • Views: 4562