Deprecating old requirements

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 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 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?

Cheers
Andy

Statistics

Started: 1/24/2012
Last Reply: 10/1/2012
Replies: 2
Views: 3284

Tel: 1-866-572-5878 | Help Desk | Legal Notices | Privacy Policy

Name:
Body:
Tags:

Name:
Body: