Integrity trace types

[doehr]

Hello PTCers,

Very soon I'm going to inherit the administration duties of a new Integrity database linked to our Windchill that is getting set up by a consulting company for us. One particular question I have is on Traces between document/object types.

I've been reading up on Traces in the documentation that we have been provided, and I know that to get to them within the Integrity Admin GUI you go to Workflows and Documents/Types/MKS Solution, select Edit Type and go to Properties, and the Trace lines in there are the ones with the name MKS.RQ.trace.<a document type>. However, the documentation that I have and can currently find is a bit light on some specific details that hopefully could be answered here.

1) There are document types listed in the Name and often several in the Value for these lines. For the document type listed in the Name part of the line what is the significance of that entry? I.e., does this mean while I am in an instance of that document type I can make the corresponding traces listed in Value, and does that automatically make a bi-directional option where I could make a trace from one of the documents listed in Value back to the one set in Name?

2) There seems to be quite a few different trace types settable in Value and I can't find a list of all the options or what they mean anywhere. Could someone please either direct me to such a list or explain the significance of each of the following trace types and why we would choose them for a Trace line:

• Authorizes Changes To
• Decomposes To
• Validated By
• Verified By
• Modelled By
• Mitigates
• Mitigated By
• Caused By
• Detected By
• Assesses
• Assessed By
• Effected By
• Drives
• Driven By
• Contributes To
• Implements
• Implemented By
• Scopes
• Associated With
• Satisfied By
• Tests
• Provides Context For
• Documented By

Please advise,

Daryl

[LLawton]

Hello Daryl,

Personally, I think it's impossible to answer your questions in a forum thread. These are big questions.

If you're new to Integrity, you need to understand how relationship fields work, how traces work, how the ALM solution is put together, and much more.

The documentation is not very useful in your case, but there are quite a few useful training videos there and also some KB articles like this one.

I would recommend to start with attending a training class for requirements management end-user, to get a feel for what your users will experience and get ideas for what you might want to improve. Then administrator training to learn how to do it.

To get back to the questions, and in a very small nutshell:

1) You should not have to modify any solution properties at this point, and this is not the place to start if you want to understand how it works. The quick answers are yes and yes, but I know that doesn't really help understanding how this works.

2) You can get a feel for what these traces do by watching some of the training videos or getting training. The only difference between them are the names given to them, and the item types they apply to, which are just a logical way of organizing data. You can start here.

[doehr]

Hi there,

Thanks for the responses, wouldn't have thought question 1 was a big question . The main reason I'm asking about traces is that our project team leads are having a bit of trouble making specific traces between specific documents. I've already received some training from the consultants and they've sent documentation, but this particular aspect was missing from it.

I'll take a look at what you've linked, thanks.

Daryl

[JoeBartlett]

In addition to the resources Laurent has linked, Article CS115058 has an overall look at all of the solution objects and how they relate to each other. This includes traces between the different types. I agree that this is a really complex area of the Integrity Lifecycle Manager product so it would do you well to get some training or study-up on how the feature(s) work. The User Guide is a pretty good starting point as well (see the "Managing Trace Relationships" section on page 681).

[doehr]

Well...that's helpful to a point, but the article looks to be the out-of-the-box trace types allowed and the user guide just shows how to make traces between documents within the program itself, but I'm looking at more of a fundamental level. Our implementation will include several new custom document types and we need to define what kind of traces can be made between them. And those MKS.RQ.trace lines in the MKS Solution Properties field is where I see those defined. So in another way of wording my original question 2...

Why would I choose a particular Trace Type? Does setting a trace as Documented By do anything different than making it Tested By, i.e. each of those two trace types have different internal attributes that controls how the two linked documents would work? Or are these just special name labels for the baseline "trace", and if I wanted I could make traces called Sparkle Dragons or Banana Sundays between two document types and they would function in the tool the exact same way as any other?

Please advise,

Daryl

[LLawton]

Didn't I say these were big questions? Look at how many more questions you just added to this one thread.

I found another interesting link: Traceability in Integrity

But again, I'd recommend a different approach to answering your questions than using this forum.

[doehr]

Lol...that's actually a copy of my primary documentation file on traces and is the central reason why I'm asking the above questions; it doesn't have answers to any of them.

Guess I have to do some more digging.

[doehr · Accepted solution]

So...I managed to get on a conference call with some technical experts at PTC directly about this, and the answers to my questions are a bit different than I expected. Since this stuff isn't very clear in the documentation I figured it would be a good idea to put everything I've learned up here.

First off, the MKS.RQ.<document type> lines in the Properties area of the MKS Solution object are not the primary area to define allowed traces, it's more of a surface dressing that I'll get to later. The key place to define allowed traces between document types is in fact in Fields, under Workflows and Documents.

You have to create a "relationship" field type, and the key setup info is in the Values tab. You pick a Type on the left, then one of the Types on the right and add it to the Allowed Types list which defines a "forward" relationship, they do have to be created in forwards-backwards pairs. You also select the toggle of it being a Trace. Lower down in this screen is a pair of Forward and Backward tabs; clicking on Backward allows you to define what name the backwards reverse entry will have. Cool note, doing this will actually create two Field entries; one for the forwards one and one for the backwards one you defined in the first one. You can take a look at the out-of-the-box ones like Validated By/Validates for a reference. You can also add a Flag, namely a Suspect flag, which will make notifications go out if one of the linked documents changes (such as a Test, which Validates a Requirement and the requirement is Validated By a Test, has a Suspect flag so if the Test changes notifications go to the users of the linked Requirement). You obviously have to make sure that the two relevant documents actually have these corresponding fields on their layouts and attribute sets to make the links.

However, although all of the above allows you to make the allowed links it's a bit of a clickathon for users to actually do it in the interface for each document. That's where the MKS.RQ lines in the MKS Solution Properties function come in. Entries in there must match the Field configurations precisely, but if entered correctly it allows for a fast drag-and-drop interface for making the traces.

Although I wish I could directly name the PTC techs who gave me this information I shouldn't since I don't know if they would prefer to remain anonymous, but thanks to them nonetheless!