Associating Incidents across Projects

Thursday, February 16, 2012 6:26:44 PM
Do you envisage allowing Incidents from one Project to be "associated" with those in another?

Currently, I believe we can only "associate" Incidents within the same Project?

(I know there is an "export" feature, but "associating" without exporting would also be useful for us!)

A.
7 Replies
Monday, February 27, 2012 8:38:04 PM
Avatar
re: astrium_tm on Thursday, February 16, 2012 6:26:44 PM
It's something under discussion, no definite plans at the current time though.
Monday, March 19, 2012 10:43:54 PM
Avatar
re: astrium_tm on Thursday, February 16, 2012 6:26:44 PM
I'd like to add my support to this concept.  We have a number of scenarios where it would be useful to be able to associate Incidents across projects. 
Wednesday, April 11, 2012 6:25:48 AM
Avatar
re: lyndeelu on Monday, March 19, 2012
I also would like to lend my support to this.

But we would like to Associate/Trace requirements between projects.

ie. We have a list of Business/User Requirements in one project and a number of design projects have been started to implement these requirements. We are using Spira to manage the design also.

Roames
Tuesday, July 31, 2012 11:59:27 PM
Avatar
re: astrium_tm on Thursday, February 16, 2012 6:26:44 PM
It's possible to use a requirement or test case across projects.
We have many requirementes that we need to associate across n projects?

It's possible?
Monday, August 26, 2013 11:00:24 AM
Avatar
re: webrafa on Tuesday, July 31, 2012
Hi all!

We are interested in this functionality, too.

I can see that i can associate Requirements across projects, it would be good the same for incidents.

Best Regards,

Rafael Baena

Sage
Wednesday, August 20, 2014 2:49:38 PM
Avatar
re: inflectra.adam on Monday, February 27, 2012
We are interested in cross-project functionality for data including requirements, or at least more security granularity within a project.

We currently have a "enterprise" level project, where we keep a master copy of requirements and releases and iterations.  Our developers and testers are setting up separate projects for specific releases and iterations.  Separate projects seem desirable because they allow us to isolate and sandbox our developers and testers.  

However, we are not looking forward to trying to sync artifacts (requirements, incidents, status, etc.) back and forth between the master enterprise-level project and the more granular level release and/or iteration-specific projects.  It's going to be a huge headache, especially when two people modify two copies of the "same" artifact that lives in two separate Spira projects.  I could easily see this happening when developers and testers and business analysts go back and forth while seeking clarity about some requirement or incident.

Part of the reason for separate projects is so we can outsource development and/or testing to contractors.  Yes, we have contractual protections in place, like Non-Disclosure Agreements, but it is still best if the contractors simply don't have access to everything.  Currently, the only effective way to prevent contractors from having access to too much is to isolate them in their own project.  It would be best if security roles CRUD permissions could be assigned at something a little more granular than the artifact type.  For example, only allow a role read access for specific requirements and everything below them in the hierarchy of requirements.  Of course this would get very complicated very fast, but I don't think it's worse than trying to maintain and sync copies of artifact data across separate projects.
Friday, August 22, 2014 1:28:16 PM
Avatar
re: jfreed on Wednesday, August 20, 2014
FYI, this topic is related to a SpiraTest forum topic, "Syncrhonizing requirements in different SpiraTeam projects".

Incidentally (and as I stated there), having separate forums, like for SpiraTest versus SpiraTeam, tends to unnecessarily silo conversations about common features.  Maybe the forums should be combined and entries could be tagged regarding both the user's product and the relevant artifact type(s), if any.  (e.g. requirements, incidents, etc.)
Statistics
  • Started: Thursday, February 16, 2012 6:26:44 PM
  • Last Reply: Monday, February 9, 2015 3:17:40 PM
  • Replies: 7
  • Views: 1646