Use Cases in PRPC – Part 4

Continuing on from Use Cases in PRPC – Part 3, the following tables will give Pega Business Architects an idea of how to use PRPC’s “Use Case Rule” to capture details about your Atomic Use Case.

The “Definition” Tab

Business Objective Ignore this field. It is covered by the relevant SUC.
Trigger Ignore this field. It is covered by the relevant SUC.
Status Choose an appropriate status.
Actors “Actor” takes on a different meaning in the context of an AUC.In a SUC, it represents that which invokes the SUC.In an AUC, it represents that which is performing the current process step, which could be a human or the System itself.
Complexity In PRPC terms this actually refers to technical difficulty rather than process complexity. Bear in mind that one flow might be complex but easy to implement and another might be simple but difficult to implement (e.g., because one step requires a troublesome interface).The LSA should decide the complexity (difficulty) of the AUC.
Shape Ignore this field. It is not up to the BA to decide what Flow Shape will implement the AUC. This will be selected by the LSA during the Elaboration or Construction phase.
On behalf of Ignore this field. It is intended to be used when the Actor is acting on behalf of another Actor. However, in UML, this makes no sense. The System only cares which Actor is interacting with it.
Subject Matter Expert(s) Optional. This is already covered by the SUC.
Pre-conditions Irrelevant to an AUC. The pre-conditions of the SUC are the pre-conditions to the first AUC, since AUCs are just steps within SUCs.The pre-condition of each subsequent AUC is that the previous step has completed.
Post-conditions Irrelevant to an AUC. The pre-conditions of the SUC are the pre-conditions to the first AUC, since AUCs are just steps within SUCs.The post-condition of the last AUC in a flow is covered by the post-conditions of the SUC.The post-condition of each previous AUC is that the next AUC starts.

The “Description” Tab
Complete one of the tables below for each Atomic Use Case, then copy and paste it into the “Description” tab. When updating, you may find the “Edit in Word” option does not work. In which case, select the table cut and paste it into a Word document, make your changes, then copy and paste it back into the “Description” field.

You should feel free to amend and adapt the tables as necessary.

For Generic AUCs

BUSINESS DETAIL
*Related BRS Requirement IDs:
*Required Business Rules:
Business notes:
Related Business Service:
TESTING DETAIL
Acceptance criteria:
Testing notes:

For Error Message AUCs

BUSINESS DETAIL
*Related BRS Requirement IDs:
*Required Business Rules:
Business notes:
Related Business Service:
Error Message Trigger Error Message Ids (add a row per Message Id)
 
TESTING DETAIL
Acceptance criteria:
Testing notes:

For Confirmation Message AUCs

BUSINESS DETAIL
*Related BRS Requirement IDs:
*Required Business Rules:
Business notes:
Related Business Service:
Confirmation Message Trigger Confirmation Message Ids (add a row per Message Id)
 
TESTING DETAIL
Acceptance criteria:
Testing notes:

For Correspondence AUCs

BUSINESS DETAIL
*Related BRS Requirement IDs:
*Required Business Rules:
Business notes:
Related Business Service:
Correspondence Trigger Correspondence Ids (add a row per Correspondence Id)
 
TESTING DETAIL
Acceptance criteria:
Testing notes:

* Use these rows only if the decision has been taken not to document low-level requirements inside PRPC as Requirement Rules. If Requirement Rules exist, link to those Rules instead.

For screen requirements more complex than a simple on-screen message, use the Screen Specification Template.

The “Requirements” Tab
The AUC should link to low-level requirements only. Low-level requirements will be linked to Atomic Use Cases. Either add them or link to them through the Requirements tab.

The “Attachments” Tab
In most cases, you are unlikely to need to attach anything to an AUC. However, in the case of AUCs which have screen requirements, you should attach a Word document which contains a completed Screen Specification Template.

The “Comments” Tab
Optional.

The “Implementation” Tab
The links to Rules which implement the AUC are maintained automatically if the AUC is linked to a Flow shape.

The “History” Tab
BAs: Optional. However, do not list any SUCs which relate to this AUC. SUCs should know which AUCs they need, but AUCs should not. This allows for re-use across SUCs.
SAs: Provide the name of any Technical Use Case which has been written for this AUC.

Related posts:

LinkedIn
Follow by Email
RSS

Leave a Reply

  

  

  

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>