<rss version="2.0" xmlns:a10="http://www.w3.org/2005/Atom"><channel><title>Inflectra Customer Forums: Deprecating old requirements (Thread)</title><description>  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.    </description><language>en-US</language><copyright>(C) Copyright 2006-2026 Inflectra Corporation.</copyright><managingEditor>support@inflectra.com</managingEditor><category domain="http://www.dmoz.org">/Computers/Software/Project_Management/</category><category domain="http://www.dmoz.org">/Computers/Software/Quality_Assurance/</category><generator>KronoDesk</generator><a10:contributor><a10:email>support@inflectra.com</a10:email></a10:contributor><a10:id>http://www.inflectra.com/kronodesk/forums/threads</a10:id><ttl>120</ttl><link>/Support/Forum/spirateam/best-practices/234.aspx</link><item><guid isPermaLink="false">threadId=234</guid><author>Greg Ferreri (gferreri@glneurotech.com)</author><title>Deprecating old requirements</title><description>  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.    </description><pubDate>Tue, 24 Jan 2012 15:27:20 -0500</pubDate><a10:updated>2012-10-01T11:33:30-04:00</a10:updated><link>/Support/Forum/spirateam/best-practices/234.aspx</link></item><item><guid isPermaLink="false">messageId=463</guid><author>David J (adam.sandman+support@inflectra.com)</author><title>That's probably the best way to do it for now. We're considering adding a "removed in release" field</title><description>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.</description><pubDate>Fri, 27 Jan 2012 21:39:55 -0500</pubDate><a10:updated>2012-01-27T21:39:55-05:00</a10:updated><link>/Support/Forum/spirateam/best-practices/234.aspx#reply463</link></item><item><guid isPermaLink="false">messageId=724</guid><author>Andy Smith (andy.smith@infoterra-global.com)</author><title>Hi Adam  I agree with Greg that creating an RQ that simply relates to the removal of another RQ is a</title><description>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  &#xD;
&#xD;
</description><pubDate>Mon, 01 Oct 2012 11:33:30 -0400</pubDate><a10:updated>2012-10-01T11:33:30-04:00</a10:updated><link>/Support/Forum/spirateam/best-practices/234.aspx#reply724</link></item></channel></rss>