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

Traceability of requirements to architecture

Tuesday, July 30, 2013
Avatar
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
(To Reply to this thread you first need to Sign-In )
6 Replies
Tuesday, July 30, 2013
Avatar
re: christof.dardel Tuesday, July 30, 2013

Hi Christof

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

Regards

Adam
Wednesday, July 31, 2013
Avatar
re: inflectra.david Tuesday, July 30, 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
Wednesday, July 31, 2013
Avatar
re: christof.dardel 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.).
Monday, August 5, 2013
Avatar
re: inflectra.david Wednesday, July 31, 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
Tuesday, August 6, 2013
Avatar
re: christof.dardel Monday, August 5, 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.
Wednesday, August 20, 2014
Avatar
re: inflectra.david Tuesday, July 30, 2013
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.
Statistics
  • Started: Tuesday, July 30, 2013
  • Last Reply: Wednesday, August 20, 2014
  • Replies: 6
  • Views: 988
Tel: 1-866-572-5878 | Help Desk | Legal Notices | Privacy Policy
Powered by KronoDesk v3.0.1 help desk software | © Copyright 2006-2019 | Licensed to Inflectra Corporation.