Thread

Skip Navigation LinksForums > SpiraTest Forums > SpiraTest Best Practices > requirements and multiple...

requirements and multiple products RSS Feed

Thursday, September 12, 2013
Hi,

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.

eg:
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!
Filip
6 Replies
Adam SAdam S
re: Filip Baert on Thursday, September 12, 2013
Friday, September 13, 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.

Regards

Adam

Filip BaertFilip Baert
re: Adam S on Friday, September 13, 2013
Monday, September 16, 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?
Jen LegerJen Leger
re: Filip Baert on Monday, September 16, 2013
Thursday, October 9, 2014

Hi,

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

Thanks, Jen

Jon FreedJon Freed
re: Jen Leger on Thursday, October 9, 2014
Wednesday, October 22, 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. 


rd-sw-hernis eatonrd-sw-hernis eaton
re: Jon Freed on Wednesday, October 22, 2014
Thursday, February 18, 2016

Hi,

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.


Cheers,

Durga.




Erwin HusmannErwin Husmann
re: rd-sw-hernis eaton on Thursday, February 18, 2016
Tuesday, June 28, 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.

regards
Erwin
Tagged
Statistics
  • Started: 9/12/2013
  • Last Reply: 6/28/2016
  • Replies: 6
  • Views: 9764
Powered by KronoDesk v1.1.0.15 | © Copyright Inflectra Corporation 2011-2016 | Licensed to Inflectra Corporation.