ALM: User Guide

The integrity of the system being developed can be controlled against requirements or the functional hierarchy. For example, in the Technical specification execution process, integrity is controlled against the technical specification. In lightweight processes, integrity is controlled against the functional hierarchy, because there is no complete description of the requirements (or a technical specification). You can choose the most suitable variant of integrity control, regardless of the process you use.

The system provides metrics that track the number of outdated artifacts, as well as modules such as "Outdated scenarios" and "Outdated documentation sections".

Functions (product features, or the functional architecture) are a way to record the functional framework, which is filled with requirements, test documentation, and operational documentation. This mechanism is convenient when complete and exhaustive requirements are absent, or when it is impossible or impractical to trace all significant project artifacts to the source requirements.

Lightweight processes

For User Story states, configure the system action "Mark the project documentation of the linked function as outdated". The User Story must be linked to the function that it implements. Then, when the Story is completed, this system action is invoked and marks the project documentation as outdated. In update mode, the system shows the list of new Stories that should affect the text of the project artifact.

When derived requirements, test scenarios, and documentation sections are created, Traces to the 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 outdated. Click the icon next to an outdated artifact to enter change mode. In this mode, changes in the source requirement are shown on the right, and the outdated text that needs to be updated is shown on the left. After the update, choose the "Restore coverage" action. This means that a project Participant confirms the integrity.

Because many changes can be made to a source requirement, and furthermore they can be purely technical (text markup, spelling, and so on), it is better to mark derived artifacts as outdated at specific stages of the requirement lifecycle. The outdated mark is implemented with system actions. For example, it is invoked when the requirement is moved to the Done or Approved state. You can configure a mechanism that suits your change-management process.