Thread

Skip Navigation LinksForums > SpiraTeam Forums > SpiraTeam Issues & Questi... > Traceability of requireme...

Traceability of requirements to architecture RSS Feed

Tuesday, July 30, 2013
Hi there

We got the new requirement to assure traceability from requirements to the architecture documentation. Thus we have to be able to trace a possible impact of new or changing requirements on the architecture of our product. After archtiecture has been changed we need to find all tests of the affected requirements.
The architecture is described in a word document as well as in the visual paradigm tool.

A possible approach I've found is to add a custom field with the all components of the archtitecture. Not very simple to  handle but OK.
Has anybody implemented something similar? Are there other solutions to handle traceablility?

The following Problem would be to select all test cases that apply to requirements of a specific architecture component.
Is there a way to build a test set based on a filter setup in the requirement view?

Thanks for you opinions and help.

Best regards
Christof


6 Replies
Adam SAdam S
re: Christof Dardel on Tuesday, July 30, 2013
Tuesday, July 30, 2013

Hi Christof

In our next release (v4.1) we've added Components to requirements to make this easier.

Regards

Adam

Christof DardelChristof Dardel
re: Adam S on Tuesday, July 30, 2013
Wednesday, July 31, 2013
Hi Adam

Could you elaborate a bit more on these components in order I can estimate how this may facilitate my task?
Is there any draft documentation about it?

Thanks
Christof
Adam SAdam S
re: Christof Dardel on Wednesday, July 31, 2013
Wednesday, July 31, 2013

Hi Christof

You will be able to define Components for a project (similar to how you can define releases). Then you tag requirements with the Component and filter/report on them. Eventually in future versions (post v4.1), components will be available in other modules of the system (e.g. incidents, test cases, etc.).

Christof DardelChristof Dardel
re: Adam S on Wednesday, July 31, 2013
Monday, August 5, 2013
Hi Adam

Thanks for the details.
What kind of relationship to requirements will be supported for components? 1:n (as implemented for Release to Requirement) or n:n (as implemented for Test Cases to/from Requirements)?

Best regards
Christof
Elise B.Elise B.
re: Christof Dardel on Monday, August 5, 2013
Tuesday, August 6, 2013
Hi Christof,

It's being implemented as 1:n relationship. That is, each requirement can only have one component. 

Also, you asked "Is there a way to build a test set based on a filter setup in the requirement view?" Yes, there is:  Tools-> Create Test Set on the requirement list.
Jon FreedJon Freed
re: Adam S on Tuesday, July 30, 2013
Wednesday, August 20, 2014
We also wanted to do this.  Instead of using the "components" field, we have set up separate requirement items for each of our systems and their components.  We then use associations to create an appropriate relationship between each "business" requirement and its corresponding "system" requirement(s).  

What is nice about this is we can now do traceability in either direction.  We can start with a business requirement and see the related systems and their components.  Or, we can start with a system or component and see all related business requirements that are driving the use of that system.

The reason we have set up requirements for systems and their components instead of using the "components" field is because the "components" field just doesn't offer the same level of functionality as a requirements artifact.  It can't be nested.  It can't have descriptions and comments, etc.
Tagged
Statistics
  • Started: 7/30/2013
  • Last Reply: 8/20/2014
  • Replies: 6
  • Views: 556
Powered by KronoDesk v1.1.0.15 | © Copyright Inflectra Corporation 2011-2016 | Licensed to Inflectra Corporation.