requirements and multiple products

Thursday, September 12, 2013

part of our organization works with multiple products (each having their own releases), sharing some requirements.

How do I manage requirement coverage for this? As requirements can only be linked to 1 release, I cannot link them to each product(release) the apply to.

requirement A is applicable for
- product 1 release 2.0
- product 2 release 1.5

how to organize releases to cope with this?
Will spira 4.1 introduce products in requirements? and if so, how do they relate to releases?

thx for your reply!
6 Replies
Friday, September 13, 2013
re: FilipBaert Thursday, September 12, 2013

Hi Filip

Version 4.1 is adding Components to projects, so those could be used as ways of decomposing a system down into smaller sub-products.

I'm not sure if this will address the multiple release issue though. Currently each requirement is only capable of being associated to one release.



Monday, September 16, 2013
re: inflectra.david Friday, September 13, 2013
indeed, that does not solve my problem.

My wish would be that you have a following logical relation:

requirement <-> product + release (n on n relationship)
so if you only have 1 product, situation would be as it is now in version 4.0
if you have multiple products, one can assign a requirement to each individual product if needed.
Test cases would not be touched as you already link them now to multiple releases.

any thoughts?
Thursday, October 9, 2014
re: FilipBaert Monday, September 16, 2013


We also have the same need - to share requirements across multiple projects.  Has there been any additions for this? 

Thanks, Jen

Wednesday, October 22, 2014
re: jen.leger Thursday, October 9, 2014
FYI, we have resolved this through the following structure:

1.  We only have one SpiraTeam project.  It is our "Enterprise" project.  So, that allows us to keep requirements in one place across multiple products and releases.  (Incidentally, the Spira roadmap says that a future release will allow items to be referenced in multiple projects.)
2.  We don't use the component field.  Instead, we have a hierarchy of requirements and one branch in the hierarchy is products/systems.  (So, within that branch we have requirement line items that represent products and things within those products, like screens.)
3.  Instead of tying business requirements to components, we instead tie requirements in the business requirement branch to requirements in the product branch. 

Thursday, February 18, 2016
re: jfreed Wednesday, October 22, 2014


We have similar issues on sharing same requirement on multiple projects. For example we have HW and SW side projects for each product line. The same requirement has to be shared in both HW and SW projects.

The report has to be from the business requirement to both SW and HW project tests. Right now it is very hard as we duplicate requirement in both the projects and reports also are 2.

Jon, I dont quite understand your solution for this issue. Could you please explain with an example on how did you workaround?

Anyone can throw light on this would be highly appreciated.

Thank your for the reply in advance.



Tuesday, June 28, 2016
re: rd-sw-hernis Thursday, February 18, 2016
I agree with Jon.

one SpiraTeam project  should be sufficient for sharing requirements among different products.
You might try to create products as test cases (or vice versa).
Requirements can be shared among test cases
Try to use releases to test cases, not in requirements.


Spira Helps You Deliver Quality Software, Faster and With Lower Risk

And if you have any questions, please email or call us at +1 (202) 558-6885


  • Started: Thursday, September 12, 2013
  • Last Reply: Tuesday, June 28, 2016
  • Replies: 6
  • Views: 16647