InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Iterative Requirement Traceability Technique

IP.com Disclosure Number: IPCOM000200430D
Publication Date: 2010-Oct-11
Document File: 3 page(s) / 48K

Publishing Venue

The IP.com Prior Art Database


Disclosed is a template solution for improving the traceability of requirements during an iterative development process. The core idea is to extend the existing requirements traceability verification matrix to include traceability at the iteration level, rather than track it through separate worksheets.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

Page 01 of 3

Iterative Requirement Traceability Technique

With increasing demand for iterative development and agile methodology to be used,

solution development teams have a daunting task in being able to incrementally deliver,

develop, and test requirements. Requirements can be targeted to a specific iteration or

evolve across several iterations. Several issues arise as part of incremental

1. A requirement might be partially elaborated, but sufficient for development and

testing to produce a partial solution for a given development iteration.
2. A development team may decide to partially implement a completely elaborated

requirement in a given iteration with the intention of tackling the rest of the

requirement in ensuing iterations.

It is not uncommon for a development team to incrementally build a solution based on

technical complexities and dependencies, as well as partially elaborated (but not

baselined) requirements. It is imperative to know the following:
1. What is the traceability of the partially elaborated requirement to development

and test components in a given iteration?
2. What is the traceability of the fully elaborated requirement from #1 above to a

larger set of development and test components in a subsequent iteration? And

3. What is the traceability of the fully elaborated requirement from #2 above to the

    fully defined set of development and test components in a subsequent iteration? While all of the above are occurring it is likely that while the development team is

working with a partially developed (but baselined) requirement, the requirement team

might already be further elaborating this requirement.

The current form of requirement traceability in document form (non-tool based) provides

only a single level of traceability from requirement to development and test components.

There is no capability to show the enhancements to requirements, and as a result,

enhancements to development and test components through many development

iterations. Thus solution development managers will be hard pressed to find the

answers to the three questions posed above.

A method is needed to create a requirements traceability verification solution or

template that allows requirement traceability...