Inflectra Customer Forums: Multiple Projects Vs. Single Project for Related Systems (Thread) We have an array of related products that share many of the same requirements and test cases. Since SpiraTest treats projects as independent entities, we cannot easily share requirements and test cases between them. Should we consider using a single project? en-US(C) Copyright 2006-2024 Inflectra Corporation.support@inflectra.com/Computers/Software/Project_Management//Computers/Software/Quality_Assurance/KronoDesksupport@inflectra.comhttp://www.inflectra.com/kronodesk/forums/threads120/Support/Forum/spiratest/best-practices/13.aspxthreadId=13David J (support1@inflectra.com)Multiple Projects Vs. Single Project for Related Systems We have an array of related products that share many of the same requirements and test cases. Since SpiraTest treats projects as independent entities, we cannot easily share requirements and test cases between them. Should we consider using a single project? Tue, 08 Feb 2011 19:54:53 -05002011-03-09T15:07:45-05:00/Support/Forum/spiratest/best-practices/13.aspxmessageId=13David J (support1@inflectra.com) Generally we recommend using a single large project if the various products are highly related and Generally we recommend using a single large project if the various products are highly related and share the same requirements and test cases. This can be done by simply making each project it's own separate Release Tree. So in the Release Hierarchy you'd have: Product 1 Release 1 Iteration 1 Iteration 2 Release 2 Iteration 1 Iteration 2 Product 2 Release 1 Iteration 1 Iteration 2 Release 2 Iteration 1 Iteration 2 Product 3 Release 1 Iteration 1 Iteration 2 Release 2 Iteration 1 Iteration 2 On the other hand, if your products are largely independent of each other, we would recommend using separate projects to keep things simple. Tue, 08 Feb 2011 19:57:35 -05002011-02-08T19:57:35-05:00/Support/Forum/spiratest/best-practices/13.aspx#reply13messageId=33Thomas Hartmann (thomas.hartmann@ubidyne.com)If I follow your suggestion to define all similar products as a release in a project, then I still hIf I follow your suggestion to define all similar products as a release in a project, then I still have the problem that I can assign requirements only to one single release, but a common requirement shall be valid in all releases/products ! How does sharing of requirements work in this context ?Tue, 08 Mar 2011 12:55:14 -05002011-03-08T12:55:14-05:00/Support/Forum/spiratest/best-practices/13.aspx#reply33messageId=34David J (support1@inflectra.com)Could you create a "Common" release for any of the requirements that are common between the productsCould you create a "Common" release for any of the requirements that are common between the products?Tue, 08 Mar 2011 16:01:07 -05002011-03-08T16:01:07-05:00/Support/Forum/spiratest/best-practices/13.aspx#reply34messageId=35Thomas Hartmann (thomas.hartmann@ubidyne.com) Creating a common release is a theorte Creating a common release is a theorte Wed, 09 Mar 2011 14:58:13 -05002011-03-09T14:58:13-05:00/Support/Forum/spiratest/best-practices/13.aspx#reply35messageId=36Thomas Hartmann (thomas.hartmann@ubidyne.com)Creating a common release is a theoretical solution (not likely to be done in our case), meaning thaCreating a common release is a theoretical solution (not likely to be done in our case), meaning that each product is based on a release of the common release !? If this is the case, then this doesn`t prevent me to do some kind of regression testing for a product release which requires also retesting of the "common" release requirements. And this is not supported !Wed, 09 Mar 2011 15:07:45 -05002011-03-09T15:07:45-05:00/Support/Forum/spiratest/best-practices/13.aspx#reply36