About Request Baseline Template Selection Criteria

Request baseline templates enable you to specify rules for selecting Dimensions CM requests that will be used as input for creating a baseline from their related items. They comprise one or more rules that are made up from the following:

- Request type.

- Request status.

- Baseline status code, which itself comprises one of the following keys:

- EQS – specified state only.

- SUP – specified state and upward.

When a baseline is created specifying a request baseline template and a set of starting parent requests, all the requests that:

- Are related to those parent requests, and

- Match the template rules

will be collected together for processing.

The template rules will be processed in exactly the same way they are for item templates, that is, requests will be selected based on the type, status, and the baseline status code that was specified. For example, if a template had a rule that specified:

- All requests of type PR

- At status ACCEPTED

- With the baseline status code EQS

then all the requests of type PR, at the status ACCEPTED only, would be used for inclusion into the baseline.

Once this list of requests has been determined, then only those items that are related to those requests with either an In Response To or, optionally, an Info relationship will be included in the baseline. However, because the baseline that is being created is a release baseline, only one revision of each item will be included in the baseline (not all revisions, as would be the case for a design baseline). This means, that even though the requests being selected may contain multiple revisions of the same item, the final baseline can only contain one revision of all these possible items.

To ensure that only one revision of an item is included in the final baseline in circumstances where multiple item revisions are related to requests, only the latest item revision will be selected using that item's pedigree.

When the baseline has been created, the requests that were used to create it will be related as In Response To that new baseline.

Constraints

To enforce a consistent model with its behavior with respect to items only, the following additional constraints apply to creating a baseline with respect to cited requests:

1. Requests that are either at a closed or off-norm lifecycle state will not be processed by the SUP baseline code.

2. Only requests in the primary catalog will be processed.

3. Only requests related through a dependency relationship, that is, DEPEND, will be included in traversal scans.

4. If a request related through a dependency relationship does not fulfill the criteria specified in the request template rules, then that request will be ignored, as will every other request that is a child of that request. This means that for a situation where N levels of requests are related together in a chain through dependent relationships, for example, CR_1 > CR_5 > CR_7 > CR_9 > CR_12, if CR_7 fails to match a template rule, then it, together with CR_9 and CR_12, will be ignored in any further processing.

5. Only requests that are owned by the product on which the baseline is being created will be processed. Any requests owned by other products will be ignored. This includes children that such requests might have.

6. Only parts or items that are owned, or have usage relationships to the parent part specified when the baseline is created will be included in the final baseline. This means that, if a request refers to affected parts and/or items that may be out of scope (not owned by or related to the parent part or any of its children), then these parts and items will be ignored.

Related Topics

Item Baseline Templates

Creating a Baseline Template