Use Cases in PRPC – Part 1

Use Cases are a key concept Pega Business Architects should understand if they are planning to use PRPC’s Application Profile Wizard.

If you are familiar with UML, Pega’s notion of a Use Case might confuse you at first. It is important to distinguish between a “Use Case Rule” (which is a container within PRPC for holding the details of a Use Case) and an “Atomic Use Case”.

The Pega Developers Network (article PRKB-26123) defines an Atomic Use Case as follows:

At the individual processing level, use cases entered for steps in the flow are atomic.

My own definition is:

In a logical process, an Atomic Use Case represents any single step which cannot be broken down into further steps.

However, I only use the term “Atomic Use Case” on Pega projects.

I feel Pega does not place enough emphasis on Software Use Cases. Their training materials and PDN articles instruct you to derive AUCs directly from Business Use Cases. However, not everything in a BUC is in scope and AUCs are too low level for the kind of initial pass through that we want when we are using the APW during the Inception phase. The SUC is ideal for this.

However, in fairness to Pega, the PDN does distinguish between what it calls “comprehensive” Use Cases (i.e., SUCs) and Atomic Use Cases (PRKB-26123), although it does not go into any detail about what CUCs are or how to use them within the tool. That’s why I’m here to help.

So what does the Application Profile Wizard allow us to capture? What should we capture?

Our guide should be that we only record in PRPC what we are going to implement in the To Be PRPC system currently in scope. Immediately that eliminates Business Use Cases, since they will include manual steps and steps performed in other systems.

If you are following SmartBPM, or any RUP-based methodology, for each identified Work Type, during the Inception phase, my approach is to specify one or more SUCs, each with high level information. Bear in mind that the purpose of Inception is to establish the scope of the project and reach an initial estimate of effort. You do not need low level requirements for that. Keep the Inception phase short and don’t document process steps during Inception unless you find yourself with spare time on your hands. Low level requirements and process details should be elaborated during the Elaboration phase; that’s what it is for.

The PRPC Use Case form – Definition tab:

• Business Objective: Select a BO from the list defined at the start of the Application Profile Wizard.
• Trigger: This is not a trigger in the business process modelling sense of the event that initiates the process; rather, it refers to the mechanism through which the trigger is expressed, e.g., web browser, email, phone call.
• Status: “New”
• Actors: Select from already defined Actors or add new ones.
• Complexity: High/Medium/Low. Within your project team or organisation, you should agree what each level of complexity means. Normally, “complexity” should not be confused with “difficulty” (more on this here).  However, I have discussed this with some Pega Certified LSAs, and they said they use this field to record “difficulty of implementation”, so not complexity at all. My recommendation, therefore is that you leave it to the LSA to select a value.
• Shape: “Sub Process”.
• On Behalf Of: You can ignore this field. It refers to another Actor that the current Actor might be representing. However, a System does not care, it only cares about the Actor it is currently interacting with.
• Subject Matter Experts: List all project staff who are considered sources of business information regarding this SUC.
• Pre-Conditions: List all applicable pre-conditions. Make sure you understand what pre-conditions are first!
• Post Conditions: List all applicable post-conditions, clearly identifying to which path each post-condition applies (e.g., Primary, Alternate 1, Alternate 2, Exception 1).

The PRPC Use Case form – Description tab:
The description tab provides you with a formatable text box in which to document the description of the SUC. However, I feel that more structure is desirable. Fortunately, PRPC allows you to use a Word document as a template. If you complete and import such a Word template (click here to download an example in PDF form), the full structure of it will be displayed within the Description field, which is great.

The PRPC Use Case form – Requirements tab:
During Inception, document any high level requirements that this SUC supports or link to HLRs that were already documented.

The PRPC Use Case form – Attachments tab:
If you already have an activity diagram for this SUC, you can attach an image file or VSD file. Alternatively, this can be attached during Elaboration. Remember, your image file might not have to be a formal artefact; it could be a photo of an activity diagram drawn on a whiteboard during a customer workshop.

Ideally, your business SME should know all of that level of information about the SUC before Inception starts. There is no time for head-scratching during Inception. I recommend you not start Inception if the SME is not already armed with the information to be captured in the APW.

In Part 2 we will take a look at four different types of Use Case and how they relate to PRPC.

Kind regards,

Declan Chellar

Related posts:

• Use Cases in PRPC – Part 2
• Pegasystems’ DCO: an analyst’s perspective
• Pegasystems PRPC Discovery Maps
• PRPC Work Types