Requirements Traceability – Link and Ye Shall Find

When embarking on a new change delivery project, do you ever get the feeling that an open call has been posted somewhere for people to highlight whatever gaps they think exist?

This block renders a quote for the post drawn from the post's custom fields. Modify the quote below the content editor in the Quote fields.

Everyone from Business to Business Technology (BT) managers seem to have an opinion and want to get as much out of the project as possible. During a course of software development project, as observed by Capers Jones in his book “Applied Software Measurement,” it is not uncommon that requirements specification changes by 30% or more. These measurements have probably multiplied since and now, in the age of continuous delivery, project scoping is often no more than a recommendation.

To Deliver the Right Change We Must Constantly Refer to Requirements

In this reality, it is easy to lose track of a project business goals and sink in the quicksand of testing and fixing irrelevant defects. For example, a defect related to the claim back procedure on damaged goods may be rendered irrelevant for business processes where a drop shipping requirement has been introduced and the claim is applied to the supplier or courier. Questions like ‘How many test cases are impacted by this change?’ become critical in terms of project time and quality.

———-

_{You might also like our blog}
UAT Testing – Heading into the War Room?

———-

Today, project managers trusted with introducing change are not only challenged with ensuring that their test plan fits and covers all business requirements but – in a broader sense – that the change itself delivers all and nothing but the sought-after business impact. In other words, project managers must ensure that as business requirements evolve throughout enterprise applications’ lifecycle, the application change they deliver never strays off those requirements.

Requirements Traceability – What Is It Good for and Why Should You Care?

Requirements traceability refers to the systematic linkage that allows business requirements and their subsequent fulfillment and validation to be followed in both forwards and backwards directions (i.e. from their origins, through to development and specification, to its subsequent deployment and use, and through all periods of on-going refinement and iteration in any of these phases).

———-

_{You might also like our blog}
Scope It Out: Parsing Risk with Next-Gen Impact Analysis

———-

Granted, linking all requirements and test cases respectively can be a bit labor-intensive if done manually. However, using the right tool, setup is a once-off task and rewards are almost incalculable. No wait actually, they are very calculable indeed. Imagine for example the following scenario: a set of tests that has run OK in the past has now started creating serious problems. What functionality do these tests actually validate? Traceability between the tests and the requirement being tested enables easy identification of the affected functions or features.

With integrated requirements traceability capabilities, change managers have a holistic view of any change. From business requirements to go-live, test managers can assure proper test cases coverage. Audit managers can look back at the application lifecycle and ascertain whether processes and standards have been kept for compliance and compatibility.

Panaya Test Dynamix Requirements module enables you to track your requirements and their related testing activities, ensuring full traceability of all your changes. Enjoy all the benefits of Panaya Test Dynamix such as easy to understand Test Evidence and Defects per Requirement. Track the progress of all test cycles, until requirements have been validated by the business, prior to release to production.