ALM User's Guide

You can control the integrity of system being developed regarding the requirements or the functional hierarchy. For example, in "TS implementation" process you control the integrity regarding technical specification. In lightweight processes, you control the integrity regarding the functional hierarchy since you don't have a full description of requirements (or TS). You can select the most suitable variant of integrity control independently of the process being used.

The system provides metrics to monitor number of obsolete artifacts, as well as the specific modules, e.g., "Obsolete scenarios" and "Obsolete documentation sections".

Functions (product features or functional architecture) is a way to fix the functional framework which is filled with requirements, test and operational documentation. Such approach is convenient when there are no full and comprehensive requirements, or when it's impossible or impractical to trace all significant project artifacts to source requirements.

Lightweight processes

"Mark project documentation of bound function as obsolete" system action is set up for the states of user story. User story should be bound with the function that implements it. Then, when the user story is implemented, this system action will be invoked marking project documentation as obsolete. In update mode, system displays the list of new stories which should affect the text of project artifact.

Processes with preliminary design

In processes with preliminary design, functional hierarchy is detailed by means of formalized requirements, e.g., functional requirements registered in the form of use cases. "Mark project documentation of bound function as obsolete" system action is set up for the states of requirements. When a requirement passes to the required state, all project artifacts for the bound function are marked as obsolete.

During the update, "New requirements" field will be displayed instead of "New issues".

When creating derived requirements, test scenarios, and documentation sections traces to source requirements are created automatically. You can also create such traces manually. When a source requirement changes, the application automatically marks all derived artifacts as obsolete. Click on the icon next to the obsolete artifact to navigate to modification mode. In this mode, modifications to source requirement are displayed on the right, and obsolete text to be updated is displayed on the left. When update is completed, select "Restore coverage" action. That means that the integrity is confirmed by a project member.

Since there may be lots of changes in a source requirement, and they may have purely technical nature (text layout, spelling, etc.), it's better to mark derived artifacts as obsolete during the particular stages of requirement lifecycle. Obsolescence mark is implemented using system actions. For example, it is invoked when the requirement is passed to Ready or Reconciled state. You can set up a convenient mechanism exactly for your change control process.