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:
Declan,
This article is dated 2012. Should I assume it still applies today to Pega 7.1 and 7.2 ?
I’m new to the detail of Pega but, so far am finding that it doesn’t really help much with the early-stage logical systems analysis and design modelling.
You mentioned “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.”
So is it not possible to include the manual parts ( or just the parts we’re not ready to fully design yet) as part of the system Framework, but exclude it from the Implementation application structure? Is it not possible in fact to treat the Framework as the logical model?
Sorry if you’ve already addressed this. I’ve only come across your interesting website today.
Hello and thanks again, Luc.
That article is a few years old and I would not write use cases today. However, my points are still relevant if a team is working with use cases. The only difference in Pega 7 is that they would document the use case within the “Specification” artefact. See: Pega 7 DCO: a business analyst’s perspective.
Regarding only documenting in Pega what you are going to build in Pega, I continue to argue this. My reasoning is that Pega’s methodology assumes it is the only technology involved in the solution and that it is the only solution needed. This does not fit real life. I think all the Pega projects I’ve worked on have involved at least one other technology and business needs and process steps that cannot be implemented with software. Bear in mind, that article was written when Pega was pushing the use of Discovery Maps. In a DM in Pega 6, every step got converted into a step in a Flow Rule (i.e., got implemented in Pega). There was and is no way to document non-Pega steps in Pega.
When people don’t realise that, it can cause chaos. I worked on one project where the customer sent some business people on a Pega BA three-day training course, re-badged them as “Lead BAs” and then gave them to a Lead System Architect to guide them in modelling one business process (replacing a credit card) using a Discovery Map. There were two key problems with their output: 1) it took them 20-man months to model the process (I did it off the top of my head in 3 hours using BPMN and I was mostly right); 2) they modelled as alternate flows functionality that they might like to have in the future. The result was a Flow Rule that was impossible to implement.
Hope this helps.
Kind regards.
Declan