1-888-310-4540 (main) / 1-888-707-6150 (support) info@spkaa.com
Select Page

How a Document actually looks in PTC Integrity Lifecycle Manager

Published by SPK Blog Post
on October 14, 2015

By now you have probably seen literally dozens of articles I’ve written on PTC Integrity Lifecycle Manager, talking about the ins and outs of various pieces of functionality. Today I thought it was time to go into greater detail on documents and how they are constructed in PTC Integrity Lifecycle Manager.

As you probably know by now there are two main categories of item types in PTC Integrity Lifecycle Manager, Process Items and Document Domains (Sometimes referred to as Document Types). While a Process Item is typically a “flat” item, used in things like Defects and Change Requests, a Document Domain is a more complex item type that is actually made up of three separate item types. These item types are the Document Item, the Content Item, and the Shared Content item. The goal behind this design is to allow you to produce something that looks like a document from in a word processor complete with sections and subsections, while allowing the end user to perform functions like tracing, and branching.

SPK the document domain

I will discuss each of these item types below:

  1. The Document Item is the container that binds the whole document together. Typically it contains the metadata regarding the overall document. The structural relationship that binds the document together (the Contains/Contained by relationship) starts at the highest level here in the Document Item.
  2. The Content items are the individual pieces of content that make up the document. Content items come in two main forms, meaningful items and non-meaningful items. The meaningful items are the content that is truly important in the document. In a Requirement Specification, these are the items that explain exactly what the required design should look like. In short, these are the items you will want to establish trace relationships to in other documents.Conversely, non-meaningful items are those things like headings and comments that while useful in organizing your document don’t advance the subject matter in any way. These are items that you do not want to use for trace relationships.Another thing to notice about the content items, is the structural relationship. Notice in the drawing above how the structure initially starts with the Document Item, but later on the lower content items have a structural relationship seeming starting off of another content item. This corresponds to how you layout your sections within your document. The lower sections are Contained By the section one level above. (Often section headings can contain several content items underneath them.)One further thing to mention about content items, is that content items are defined within the context of a given document domain. This means that if you have a Requirement item that was originally defined as part of a Requirement Specification, you cannot place that Requirement item directly within a Design Specification or any other document type for that matter, other than a document that is also a Requirement Specification.
  3. The Shared Content item is that last part that makes up the document domain. Basically the shared item is a hidden item, the average user may not even know it exists. It’s on the Shared Content item where the important information about the content is actually maintained. In the diagram below you can see an example of how this works.
    spk content vs. shared
    The content item and the shared content are linked together by way of the References/Referenced By relationship. The important fields, in this case the Category and Text fields, are actually maintained on the shared content item. What you see on the Content item are Field Value Attribute fields (FVAs). Think of an FVA as an interactive reflection of what’s in the corresponding shared field. Although, this looks strange, the purpose of this will become clear when we talk about how branching works. That of course will be discussed in a future blog article.

I have attempted in this document to shine a light on what happens behind the scenes with documents in PTC Integrity Lifecycle Manager. As you are now aware a Document Domain in PTC Integrity Lifecycle Manager is a complex type made up of several different parts all working together to give the end user a Word like experience while still allowing for things like tracing and branching, things you can’t necessarily do within a word processor application.

Next Steps:

Latest White Papers

Atlassian Cloud: Understanding Zero Trust Security

Atlassian Cloud: Understanding Zero Trust Security

Where To Start & Why It Matters What is the Atlassian Cloud Zero Trust Security model? Well, for decades, enterprise security controls were built to protect a large, single perimeter around a corporation. Often described as castle-and-moat security, This approach...

Related Resources

Windchill PTC Data Migration In Under 3 Months

Windchill PTC Data Migration In Under 3 Months

Data migration doesn’t always go to plan. Yet growing out of one system architecture and migrating to another is critical for a business to survive, thrive and grow as technology evolves.  When considering a  Windchill PTC RV&S migration in a company with over...

Top 6 Ways To Improve Your DevOps Journey

Top 6 Ways To Improve Your DevOps Journey

Knowing how to improve DevOps can be challenging. But, creating an integrated DevOps toolchain can set organizations apart from the rest. This is because having a well-defined business DevOps journey can reduce errors, improve collaboration and drastically increase...

Use Nessus To Harden Your Cybersecurity

Use Nessus To Harden Your Cybersecurity

Cybersecurity should be baked into the onset of IT and product development processes. Additionally, treating cybersecurity as an afterthought opens your organization up to vulnerabilities and risk. Therefore hardening your IT product cybersecurity with a tool like...