Tag Archive for: Requirements Relationships

Impact and change Analysis are two important concepts in requirements management. Understanding how a change made to one requirement, impacts the upstream and downstream relationships is essential in assessing the scope a change may make.  What happens when a change IS made to an upstream requirement, and you are a downstream stakeholder? How will you know and how can you manage this change? This is where suspect notification plays an integral role in informing users of changes to the requirements that they care about. 


RELATED POST: The Essential Guide to Requirements Management


When relationship links are established between requirements, Jama Connect users can utilize the Impact Analysis feature to inform them as to the downstream or upstream impact of changes to a particular requirement. This helps to indicate the scope a particular change may make across the system of linkages. If suspect linking is enabled, and a change is made, users are alerted of these changes through various indicators and views in Jama Connect:  

  • Displayed in the Relationship Indicator column with a red exclamation point icon (which you can hover over to see how the item violates relationship rules.)
  • Displayed in the individual requirement in the “Relationship” view as “Causing Suspect” for each linked requirement that is suspect. 
  • Displayed as a Project-wide view under “Project > Suspect Links” 

If a linked requirement is marked suspect, users can take advantage of Jama Connects’s Compare Versions feature and get a side-by-side visual comparison of the changes between versions of requirements to determine what has changed. This allows them to assess the impact of the change that caused the suspect and make appropriate changes to the linked requirements.  A good example of this is if a set of verification tests are linked downstream to a functional requirement. If a change to the details of the functional requirement is changed, then all downstream verifications will be marked suspect, and the test lead can impact the change and update the tests accordingly. When the changes are complete, the suspect link can be “cleared” (either individually or in bulk). This ability to control and react to change is especially important in meeting regulatory standards, such as DO178C, ISO26262, ISO 13485 (and many others). We cannot assume requirements are static and must have visibility to what changed, and the impact that change will have.   

Suspect linking can be configured in the Jama Connect Org Admin setting, per item type field. This allows for granular flexibility for users to set which field changes will trigger a suspect link. This level of flexibility is extremely important as it allows users to define suspect rules according to their process and what fields are essential to track for change. 

Conclusion: 

Don’t let suspicious requirements scare you! Understand that they are an important part of the requirements change process and are there to help you control and react to updates made to linked requirements.  Let’s face it, requirements change, and getting a clear understanding of when something changes and what changed is essential.