Requirements portal

A document is considered to be either a well-defined document, such as a Passport, or a less-defined equivalent document, that users know will meet certain criteria, such as an equivalent proof of address.

A well-defined document can be used across multiple requirements, whereas an Equivalent document can only be used to fulfil the requirement it was originally uploaded for.

Each document needs to be explicitly marked as a reusable document, in order for it to be re-used across multiple requirements. For example, a Passport belongs to a party and describes attributes of that party, so typically it could be used whenever a Passport is needed for that party. Conversely, a Partnership agreement forms a relationship between two or more parties, and therefore must not be reused by other requirement cases, which could be for a different party.

In the following image, click the + icons to learn more about the settings for a document using an example of a Passport: 

A Requirement provides a granular view of business requirements and typically consists of one or more documents that relate to a particular scenario. You can edit requirements in the Requirements portal and Designer Studio (rule form). For example, personal identification requirements can include documents like passports, tax ID, or social security numbers.

The Requirements should be defined with a default satisfaction logic. That satisfaction logic is a logical expression that determines with which documents the requirement can be considered satisfied. In addition to the default satisfaction logic, users can add additional satisfaction logic that apply under specific business scenarios. For example, a proof of identity could be generally satisfied with a passport, but minors may need to present a consent from their parents. In that case, we can configure the requirement to have a default satisfaction logic that accepts passport and an additional business scenario for minors with a different satisfaction logic, where the need of the consent is imposed.

In the following image, click the + icons to learn more about requirements configuration (for example, using "Verification of identity"):

The Requirement set rule contains a grouping of one or more requirements based on business logic and provides a way for the system to determine the subset of requirements that is quickly applicable. To provide maximum reuse of requirements, the requirement’s applicability is defined in the requirement set, and the requirement’s scenarios further refine which document satisfaction logic is applicable.

Three additional filters: Purpose, Key, and Locator are used to improve system performance by providing filters for limiting the requirement sets required to be considered. This is faster than taking into account the applicability of each requirement set. For example, an application is configured to only consider requirements for an Individual (as opposed to a Business) Customer Identification Program (CIP), because the task is to onboard such a customer. In that case, the application can be configured to request for that specific category only.

In the following image, click the + icons to learn more about requirement set configuration: