ALM: User Guide

Responsible, high-quality development of software requirements requires a management process of its own.

A unique requirement identifier is used to refer to a requirement, when creating dependencies, or when exporting and printing documents. By default, ALM itself assigns requirements identifiers of the form R-NNN, where NNN is a number. This identification runs through all documentation entered in the system. It guarantees that the identifier is unique and lets you refer to a requirement unambiguously.

You can define your own scheme for identifying artifacts, different from the one used in the system by default. To do this, open the settings of the "UID" attribute and set a formula there for calculating the default value.

As the formula for calculating the Requirement identifier, write an expression following the example from the description. Here are several variants of custom identification of Requirements:

• {PageType.ShortCaption,R}.{Id} - the Requirement ID starts with the short name of its type, for example, SR.123
• {PageType.ShortCaption,R}-{IdProject} - the "IdProject" field value is filled by an automatic counter within the project. In each project the counter starts at 1. This way you can get identifiers such as: BR-1, SR-2, and so on.
• {PageType.ShortCaption,R}-{IdType} - the "IdType" field value is filled by a counter for each Requirement type. This way you can get identifiers such as: BR-1, SR-1, and so on.
• {PageType.ShortCaption,R}-{IdHierarchy} - the "IdHierarchy" field value is filled by a counter within the hierarchy (document), that is, the counter increases for each next child element inside the document.
• {PageType.ShortCaption,R}-{IdParent} - the "IdParent" field value is filled by a counter within the parent section, that is, the counter increases for each next child element inside one section.

You can form an identifier using leading zeros; for example, given the expression {Id,6}, the system forms the identifier as 000001, 000002, and so on.

It is convenient to mark requirements that have different purposes with different types. In the application, use filters or grouping to work on different requirement types. Each requirement type can be associated with a default template. When a requirement is created, that template is used as a blank to be filled in.

Each requirement type can have its own set of custom attributes.

A requirement, as a project decision (in the business domain or in the technical implementation), passes through several stages of evolution: it is developed (documented), clarified (with designers and testers involved), agreed with the customer, and then implemented in program code.

The lifecycle can differ in different projects or for different requirement types. The project team configures the requirement lifecycle for its project itself. In the "Requirements-driven development" process we have already configured several useful rules, for example:

• Prohibition on editing the requirement text after approval. To edit the text, the requirement must be returned to the "In progress" stage, and the source of the change must be specified — the source Issue, or a business requirement that has changed.
• Marking derived artifacts as outdated. So that every change (down to a missing comma) does not make the test documentation (or other derived artifacts) outdated, this operation is performed only when the requirement is moved to the "Done" state. In this way, when restoring the integrity of the project documentation, we work with batches of changes at once.

Synchronous (cascading) changes to the states of parent or child requirements can be used to speed up status management. For example, when approving a document it is enough to approve the root section (the document title) for all of its subsections to be marked as approved as well. Such synchronous operations are configured in the requirement lifecycle using the corresponding system actions. Because this is a bulk operation, the user may get an unexpected result. To warn the user that such operations will run, select the checkbox when adding the system action:

Before a transition is performed or the status is changed, the system warns the user that this system action will be executed.

Requirements and primary requirements also have useful attributes related to the lifecycle:

Traces between requirements are formed by cause-and-effect links and by coverage. Traces are formed while you work on project artifacts. Traces can be created and edited manually on the "Traces" tab.

Traces are used for the following tasks:

A tabular view of dependencies between different types of requirements, for example business and system requirements, is called a traceability matrix. This tool lets you:

• Control the integrity of the product being developed, and detect discrepancies between what is required and what is implemented.
• Substantially reduce the time spent analyzing the changes that follow a new Request from users.
• Keep derived requirements up to date.

The traceability matrix lets you get instant answers to questions such as:

• exactly how the source Issues were taken into account, and when they will be implemented;
• whether we have taken all important Issues into account in the next version of the business requirements or in the product version;
• where a business requirement came from, and what its importance is;
• how business requirements will be implemented, by studying the system requirements;
• whether all the necessary business requirements are reflected in the system requirements, and so on.

To configure requirement filtering in the Source requirements or Derived requirements columns, use the button with dots.

To assess end-to-end traceability of requirements down and up the requirement levels, use these modules:

• Forward traceability matrix (by type) — the columns contain requirement types, and the cells contain the requirements of a specific type that are linked to the current one. The matrix can be used to check that traceability from the upper requirement level to the lower one is complete.
• Forward traceability matrix (by document) — the columns contain requirement documents, and the cells contain the requirements of a document that are linked to the current one. The matrix can be used to check that traceability from the upper requirement level to the lower one is complete from the point of view of documents: regulations, legislative requirements, constraints, safety requirements, and so on.
• Backward traceability matrix (by type) — the columns contain requirement types, and the cells contain the requirements of a specific type that are linked to the current one. The matrix can be used to check that traceability from the lower requirement level to the upper one is complete.
• Backward traceability matrix (by document) — the columns contain requirement documents, and the cells contain the requirements of a document that are linked to the current one. The matrix can be used to check that traceability from the lower requirement level to the upper one is complete from the point of view of documents: regulations, legislative requirements, constraints, safety requirements, and so on.

There can be many requirement types and documents, which makes the forward and backward traceability matrices harder to use. To configure the matrices, use the view settings button:

View settings:

• Query for columns — lets you set an expression that limits which columns are selected for this view. For example, you can list only the requirement types that matter for assessing traceability.
• Expression for the cell — lets you set the cell display format. By default, a link to the traced requirement is shown. Here you can set an expression that displays the attribute you need, for example {UID}, to show only the requirement identifier.

The "Effort by requirements" report shows planned effort and actual effort, so you can assess budget overrun or, conversely, free capacity. Planned effort (Estimate) is specified for each atomic requirement that will be implemented. Actual effort is calculated by the application from development tasks, testing tasks, and other tasks.

Values on a red background mean the budget has been exceeded; values on a green background mean free capacity is available. Use the report to decide whether requirements can be changed without renegotiating the budget.

You can break planned expenses down by requirement by decomposing requirements into tasks or Enhancements. In that case, the report shows a breakdown of planned effort by type of work.

When you use the "Project finance and budget management" module, you can see this information in terms of the cost of the time planned or spent by a project Participant. Use the "Expenses by requirements" module for this.

When a Baseline is created, the system stores the values of the estimate, the effort, and the cost, so in comparison mode you can see the changes (in parentheses) in these indicators between different versions of the document.