The Requirements functionality implements the passing of data between the parent case and its requirements at two points in requirement processing.

When a requirement is instantiated, data can be passed from the parent case to the Requirement object to initialize it. If the data is used to validate individual documents, the Requirement rule can name an activity that is run to distribute the data appropriately among its document entries after it is passed to the requirement.

When a requirement is validated, data can be passed from the Requirement object to the parent case to update it with information gathered during the validation process. If the data is gathered from individual documents, the Requirement rule can name an activity to collect the data appropriately from its document entries prior to passing it back to the parent case.

There are two methods of passing data between the parent case and the Requirement object.

For passing simple scalar values between the objects, you can use the Parameter tabs of the Requirement rule and the Requirement Set rule to specify the data that is passed.

Advantages:

• Does not require that the Requirement rule know anything about the parent case internal data structure, or that the parent case know anything about the internal data structure of the requirement. This is useful if the requirement is used with parent cases of different work types.
• Minimizes the degree to which Requirement rules must be kept in sync with changes in the parent case structure, and vice versa.

Disadvantages:

• As implemented, the approach is limited to scalar values. It cannot be used to pass pages and lists.
• If many scalar values are being passed, configuration can be somewhat cumbersome.
• If the passed data is used by individual document validations in the requirement, an input activity to distribute the data to the documents (at initialization time) and an output activity to collect data from the documents (at validation time) must be defined for the Requirement rule. This is because the parameters always pass data at the requirement level, not at the individual document level.

For passing data such as page data or lists, or to process more complicated initializations or updates, the requirement Input and Output activity can open and work with the parent case directly.

Advantages:

• This approach can handle arbitrarily complex updates.
• Can be configured completely in the Requirement rule Input and Output activities, including the passing of data to and from individual requirement documents as needed.

Disadvantages:

• Requires that the Requirement rule know about the parent case internal data structure, and that the parent case know about the internal data structure of the requirement. This may be problematic if the requirement is used with parent cases of different work types.
• You must pay more attention when making changes to the parent case structure to ensure that Requirement rules are kept in sync with changes in the parent case structure.

• Passing scalar data using parameters
• Passing data without parameters

• Pega Foundation for Financial Services requirements guide