The opinions expressed by the bloggers below and those providing comments are theirs alone, and do not necessarily reflect the opinions of Ryma Technology Solutions. As they say, you can't innovate without breaking a few eggs...

  • Home
    Home This is where you can find all the blog posts throughout the site.
  • Tags
    Tags Displays a list of tags that have been used in the blog.
  • Bloggers
    Bloggers Search for your favorite blogger from this site.
  • Archives
    Archives Contains a list of blog posts that were created previously.
Posted by on in Community
  • Font size: Larger Smaller
  • Hits: 1698
  • 2 Comments
  • Print
  • PDF

Traceability in FeaturePlan

FeaturePlan allows you to create links between Requirements with the purpose of determining Prerequisites and Dependencies. However, this feature coupled with the ability
to assign Requirements to multiple Releases means that it is possible that conflicts may occur. For example, a prerequisite Requirement may be assigned to a later Release than it’s
dependent Requirement, or you may have a Circular Reference Violation.

To avoid these types of errors, these links are monitored by the Traceability engine within FeaturePlan. When the Traceability engine detects any violations, they are displayed in the
Traceability Violations screen.

The Traceability engine uses the Actual GA date of a release to validate Prerequisite and Dependency links for requirements assigned to the release. If no Actual GA date is present,
the Target GA date is used. Since a single requirement can be assigned to multiple releases, the Traceability engine compares the dates for each release to which a requirement has been
assigned and applies the earliest one.

If a release has no Actual or Target GA date filled in, then it is considered to be dated later than any other release in the system. All undated releases are considered to be dated equally
and therefore do not automatically cause a violation.

You can turn off these kinds of traceability checks in the FeaturePlan Administrator Utility. Circular Reference Violations will always be checked, however. For more information on
enforcing the traceability checks, refer to the “FeaturePlan Administration Guide”.

Circular Reference Violations are triggered when an attempt is made to assign a requirement to a Release that would cause a loop with its Prerequisites and or Dependencies. For example, if you attempt to make Requirement X a Prerequisite of Requirement Y, Requirement Y a Prerequisite of Requirement Z, and Requirement Z a Prerequisite of Requirement X this will trigger a circular reference violation.

About the Traceability Violation Screen
The Traceability Violation Screen displays any records (either requirements or releases) that have triggered a traceability violation.

The Requirement(s) involved in the operation that triggered the violations is identified at the top of the Traceability Violation screen. In some cases, there may be more than one Requirement that has triggered a violation in which case each Requirement is displayed in its own tab. Clicking the tabs will display, for the requirement selected, any Prerequisites or Dependencies in violation.

NOTE Due to the fact that the Traceability Engine checks all traceability links for a particular requirement, including the Prerequisites of Prerequisites or Dependencies of
Dependencies, the Prerequisite or Dependency in violation, may not be one immediately linked to the Requirement in the operation.

The Traceability Violation screen also displays the following information for each record for which a traceability violation has been triggered:
• The Summary of the Requirement.
• The TIDor record ID number of the Requirement that is in violation.
• The Traceability Link/Type, which indicates whether the Requirement in violation is a Prerequisite
or a Dependency of the Requirement on which you were working.
• The Message which provides you with the reason the Requirement is in violation in light of the operation performed.
• The Release Used for Validation/Current Earliest Release indicates which release was considered in the validation.