Request Spec

A request specification represents the occurrence of all the events and changes that can happen to the agreements sold for the modelled product.

General tab

The General tab contains all the main information about a request spec:

Name:

  • Use the known business term to name the request spec.
  • Avoid repeating the word ‘request’ as that is implied in the type of the object.
  • Start the name of the request spec with an active verb, like convert, add,cancel, accept. Then complete the name with an indication of the object the request acts upon, like beneficiary in accept beneficiary.
  • In case the request spec is specific to a product, then also include an indication of the product in the name, like in Issue automobile insurance certificate.

Documentation:

  • The definition should be seen as an additional description to complement the name. It should shortly describe what the requested action is supposed to do.
  • The definition can be reused from the mapped elements in the Analysis Process Model.

Other elements from the General tab:

  • The default for abstract is no and visibility is public and these should not be modified. Request specs do not have a super-type and the package structure is not used in the IPS deliverables (but could be used in projects to add additional structure).

Stereotypes tab

The keyword is used to classify the request spec dependent of the source of the request. Allowed keywords are:

  • external request
    • A request originating from the customer, the intermediary, the beneficiary, but not the insurance company itself. For example, the cancellation of a policy by the customer, the replacement of a car on a car-insurance policy, the conversion of an agreement into another one or an increase of the sum insured as decided by the customer.
  • internal request
    • A request originating from the insurance company itself. For example, the cancellation of a fire-insurance agreement for non-payment of the premium would be an example of an internal request. In this case there is a data condition, which can be expressed as a rule of kind trigger condition. In practice, the request will be triggered by another process which contains the logic to test for the triggering condition.
  • temporal request
    • A specific case of an internal event. A temporal request happens as a consequence of reaching a certain date. For example, the automatic renewals of a car-insurance policy every year on the policy’s anniversary date.

Attributes tab

This is where you can add a property spec or a constant spec to a request spec. See the relevant sections on property spec and constant spec for more details.

Relationships tab

You can browse existing or create new associations between the request spec and other types in the Product Model (product, request behaviour spec, role spec, constant role spec, rule spec and calculation spec).

The association is named after the end types and their nature.

Navigating to the selected association brings you to the association properties showing the details of the relationship, such as its cardinality.

The cardinality only needs to be provided for the natures relevant in product modelling. For request spec, the cardinality is relevant for the has role and has constant role natures.

Mapping to other models

  • Actual class mapping to the Business Model
    • The request specs can be mapped to the Business Model using the Abstraction type with the prefix of BOM in the name.
    • This mapping indicates the Business Model class used to instantiate the requests based on the request spec. For example an accept beneficiary request spec has as actual class Contractual content change request. It means that all the requests based on the accept beneficiary request spec will be contractual content change request instances.
    • The mapping is done to types from the actual side of the Specification – Product And Agreement package, to sub-types of agreement request.
  • Kind mapping to the Analysis Process Model
    • The request specs can be mapped to the Analysis Process Model (APM) using URL with refine type and APM Mapping : prefix in the name.
    • This mapping points to the business process or global task that describes the processing of the request in the APM.
    • If relevant, the description of the business process or global task can be appended as part of the description for the request behaviour spec.
    • The mapping is done from the Product Model to the Analysis Process Model.

Assigned to Terms tab

The role specs can be mapped to the Scopes from the Insurance Business Glossary in Information Governance Catalog (IGC).