In Part 1, we took a look at Pega’s definition of a Use Case and what the Application Profile Wizard allows Pega Business Architects to capture. In Part 2, we shall now take a look at four different types of Use Case and how they relate to PRPC.
Business Use Case
A technique for describing (in technology-agnostic terms) a repeatable business process which is invoked by business actors (people or external systems), often working in collaboration, in order to achieve a specific goal (or goals) that provides clearly defined business value to the actors (e.g., process a customer order). A BUC can describe both manual steps, such as greeting a customer, as well as steps which are expected to be supported by an IT solution, such as recording customer details. The term “Business Use Case” is just another way of saying “business process”.
PRPC Constraints on BUCs
It is not possible to model start-to-finish business processes (Business Use Cases) within PRPC because the tool can only model what is to be implemented in PRPC.
Software (System) Use Case
A technique for describing the repeatable interactions between a business actor (e.g., a person or external system) and the To Be system in order to achieve a result of clearly defined business value to the actor. A SUC will describe what the system will do for the actor but not how it will achieve it. A SUC will not describe any actions outside the actor/system interaction. A SUC is implementation-agnostic and does not make reference to screens, screen elements (e.g., buttons and drop-down lists) or screen activities (e.g., “clicking”).
The PDN refers to SUCs as “Comprehensive” use cases, but does not give any guidance on whether or how to model them. See Use Cases in PRPC – Part 3.
Atomic Use Case
This is a concept used in PRPC which equates to a single step in a SUC. Pega urges the use of Use Case Rules to capture details of AUCs. See Use Cases in PRPC – Part 4.
PRPC Constraints on SUCs and AUCs
The structure of the Use Case Rule is more suited to traditional UML SUCs, rather than individual steps within a SUC. This can lead inexperienced analysts to try to enter a lot of detail about an individual step which may not be relevant, e.g., “pre-conditions”.
Technical Use Case
A technique to describe, in implementation terms, how the To Be system will achieve what is described in the corresponding SUC, in order to provide the business value described in the SUC. There may be a TUC for a whole SUC or a TUC for an individual step (AUC) within a SUC. Technical Use Cases are outside the remit of the BA. See Use Cases in PRPC – Part 5.
PRPC Constraints on TUCs
There is no Rule in PRPC specifically for documenting TUCs, nor does the PDN mention them. However, the Use Case Rule can be used.
Use Case Linking
PRPC does not allow Use Case Rules to be linked to each other. This is an area for improvement in Pega’s traceability model. However, you can use the Usage field of a Use Case Rule’s History tab to note what “child” UCRs it relates to.
The SUC author analyst can note any AUCs which sit under the SUC (forward linking). SUCs can have more than one AUC because AUCs are individual steps within a SUC. Each AUC can relate to more than one SUC, which indicates re-use.
The TUC author can note any AUC or SUC the TUC relates to (backward linking). Each TUC should relate to a single SUC or TUC. Not all AUCs will require a TUC.
Use Case Categorisation
PRPC does not cater for different levels of use case and this is another area for improvement. However, the following prefixes can be used in the names of Use Case Rules:
- Software Use Case: SUC
- Atomic Use Case: AUC
- Technical Use Case: TUC
Related posts:
- Use Cases in PRPC – Part 1
- Pegasystems’ DCO: an analyst’s perspective
- PRPC Work Types
- Pegasystems PRPC Discovery Maps
Leave a Reply