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:
Case Types are a key element in Pega BPM development and it is important for Pega Business Architects to have an understanding of them.
Case Type is what Pega used to call a Work Type prior to Pega 7. Although the Type is a Pega implementation device, the concept also has a place in the business world. If you want to figure out whether something is truly business in nature rather than just a constraint of the ethnology you are using, imagine going back a hundred years. If the concept has a place in the world of paper, ink and elbow-grease, then it is probably not a technological constraint.
Can we imagine Types in a technology-agnostic world? Yes, we can.
Anyone who works for a company understand the concept of having to submit a formal request whenever they want to take leave (time off). In a world without computers, you might have to fill out a special form. Let’s call the form a Leave Request. There is space on the form for you to document anything you need to about your requested leave. After completing the form, you take it to your line manager, who has to review your request, noting any comments and the outcome of the review on the form itself. Your manager can approve or reject the request. Under certain circumstances, your line manager’s approval might not be enough. Perhaps you are requesting unpaid leave, which also requires approval of the HR manager. The form is therefore reviewed by the HR manager, who notes any comments and the outcome of the review.
If you have recognised this process as a workflow, then feel free to treat yourself to a neck massage and a slice of chocolate cake. A piece of work is flowing from one role to another, each role assuming responsibility for the work as the process progresses. In this case, the business process is a workflow, although not all business processes involve workflow. You might name this process “Request Leave”.
The thing being processed is not a one-off. It is something that happens over and over in the company. Therefore, the work has a pre-defined type. In this case, you might name the type “Leave Request”. If you are familiar with logical data modelling, you will recognise that “Leave Request” is an Entity Type. In fact, the Case Type in Pega 7 is the implementation of a key Entity Type.
However, in the business world, Entity Types also exist outside the context of workflow and case management. In Pega, when you execute any process (whether workflow or not) a container is created which holds all the information needed about that instance of the process. Such a container is called an Object and its abstract definition is a Type. Identifying all Types, including non-workflow types, is important in designing the class structure for the Pega implementation.
Take a process for amending an address. It does not involve workflow because the work does not move from role to role. A single role starts and completes the work independently. The process is called “Amend Address” and although the Business does not need a work type called “Address Amendment”, the PRPC implementation does.
If in doubt, work closely with the PRPC Lead Systems Architect during the early stages of the project to define Types but make sure you have a robust logical data model to work from!
Kind regards,
Declan Chellar
Related posts:
Update: This post is from April 2012 and has been superseded by one from July 2016: Decision models, user stories and acceptance criteria
One of my readers contacted me recently to ask whether business rules and user story acceptance criteria could be considered the same thing.
Acceptance criteria are the requirements that have to be met for a user story to be assessed as complete.
The Business Rules Group defines a business rule as follows:
- A statement that defines or constrains an aspect of the business. It is intended to assert business structure, or to control or influence the behaviour of the business.
Business rules are normally defined at the organisational or enterprise level rather than the software level for the following reasons:
- Not all of a business’s rules are implemented by a single software application
- Not all of a business’s rules are implemented by software at all (e.g., some business rules govern what an employee should do and it is down to the employee to decide whether to do A or B, based on the rule)
Looking deeper into the first point above, two different software systems might not implement the business rule equally. A concrete example would be the following business rule:
- Details of any bank account may be provided only to the following:
- The verified account holder
- Any verified authorised signatory of that account
This is a realistic rule for a bank which could apply to:
- The bank’s staff in any branch (executed by humans)
- The bank’s call centre staff (executed by humans)
- The bank’s call centre software (executed by software)
- The bank’s website (executed by software)
Imagine, however, that the website (let’s call it BOL for “Banking On Line) will not be capable of handing authorised signatories until a future release, so point 2 above will not apply to BOL yet, even though it currently applies to other areas of the business. The business rule is valid regardless of the release plan for BOL, so the rule should not be edited to fit into that plan. What should be adjusted is the relevant acceptance criterion relating to a user story for BOL.
When we look at this from the point of view of acceptance criteria for the next release of BOL, we might document an acceptance criterion as follows:
- Details of any account are provided only to the verified account holder
So while the acceptance criterion and the business rule are clearly related, they are not the same. They are different in two ways:
- The AC is effectively a subset of the BR
- The grammatical structure (this is not a trivial point, precise use of English is very important in documenting clearly and unambiguously)
It is not correct, therefore, to simply transcribe acceptance criteria and label them business rules.
People often confuse “business rules” with expectations of how the To Be system will behave. The former can govern the latter, but that does not make them the same.
Kind regards,
Declan Chellar
Related posts:
Since my blog post on Pegasystems DCO, several people have asked me to expand upon what I said about Discovery Maps.
The expansion is in the slide deck below. In summary, although Pega Discovery Maps are intended as a mechanism for Pega Business Architects to model business processes in business terms, they are too crude to do that effectively. My own experience is that a business should approach any software development project with their To Be processes already modelled (e.g., using BPMN 2.0). That would be sufficient to allow the appropriate person to built robust Flow Rules. Discovery Maps, in my experience, inadequately and inaccurately model processes and are, as such, an obstacle to success.
Pega Discovery Maps are liked by people who have no experience of, or training in, modelling business processes because they are very simple. But way too simple. Discovery Maps are just not capable of capturing the complexity of a process that has even one alternate flow.
However, while PRPC is an excellent process implementation tool, Discovery Maps just don’t cut it for me. They strike me as a tool designed for analysts by people who have never done analysis. Bear in mind that part of my job on a Pega project is to clearly define the business process in terms of needs and to communicate that to everyone as leanly and as clearly as possible. I have a scalpel that helps me do that job well and it is called BPMN. I don’t need to be lumbered with the blunt pocket-knife that is the Discovery Map.
There is a misconception that you must produce Discovery Maps on a Pega project, but that is not true. Discovery Maps serve only to A) model the business process and B) automatically generate Flow Rules, but as you will see in the slide show below, they don’t do either very well.
If you want to document business process within PRPC, my advice is to do the following:
- Model the process using BPMN before your Pega project starts
- Build your Flow Rules manually based on the process models (it only takes minutes if your models are robust)
- Attach the process model to the relevant Flow Rule (that is DCO too, you know)
What have your experiences of Discovery Maps been?
Related posts:
Does your cover letter or LinkedIn profile state that you are passionate about [name some work-related activity here]?
Mine does not.
Quite simply because I am not passionate about business analysis. Dedicated? Yes. Keen to share my experiences? Certainly. Enthusiatic to learn more? Definitely. Passionate? Nope.
If I was desperate to work for Donald Trump or Alan Sugar, then I probably would claim to be passionate about their business interests. But I would be lying, just as you probably are when you say you are passionate about bridging the gap between business and technology to implement agile solutions so as to deliver added-value to high-end customers in a challenging market.
Pants on fire!
Alan Sugar and Donald Trump don’t believe you when you say you are passionate about their business. But I imagine they still like it when you say it, because it tells them you are probably willing to sacrifice the things you should be passionate about in order to climb the ladder. I am a freelance consultant. I am not passionate about my customers’ businesses. When most of my customers come looking for me, they are looking for my skills and my professionalism, not my fake passion. When they want fake passion, they look for full-time employees.
Passion is usually only real at work is when the work is vocational. When I eat in a restaurant, I can tell whether the chef is passionate about cooking. I expect an artist to be passionate about art, or a writer about writing. When someone in the world of software development is really passionate about what they do, watch out! They will waste your money because instead of giving you what you need, they will spend time crafting that beautiful thing that feeds their passion and drains your budget.
Hyberbole in your profile insults the reader’s intelligence. It would certainly insult me if I were hiring. Where will it lead to when the word “passionate” becomes passé?
“I am concupiscent at the idea of leveraging best practises to bring enterprise solutions in time to market.”
I am a mercenary. My clients do not expect me to be passionate about business analysis, they just expect me to be bloody good at it. They do not expect me to be passionate about their business, they just expect me to give a damn about providing them with the service they are paying me for. They do not expect me to be passionate about their corporate dreams any more than they are passionate about my personal ones.
It’s bad enough that the business world stole the most beautiful word in the English language and perverted it: “blackberry“. Now “passion” has been pilfered. It is no longer the preserve of the poet, the artist, the lover and the athlete. It is now the property of marketer, the java programmer, the project manager and the actuary.
I don’t blow smoke at my clients. I speak plainly to them. Hence my willingness to declare my lack of passion. Were it otherwise, I would be about as useful on business change initiatives as a cocker spaniel. But more expensive and with better table manners. Certainly, not all my clients like the plain truth, but those who don’t should not be hiring a freelance business analyst.
Save passion for your family, for your vocation, for your garden or for your collection of antique chess boards. Let’s be professional at work and passionate at home. And let’s not blow smoke at each other.
Kind regards,
Declan Chellar
 Passionate about you, but useless at modelling your business architecture.
I’m bumping this post because of some updates, as highlighted in green below. Note that this post relates to Pega 6.1 and was originally drafted in 2009.
Some of you Pega Business Architects were wondering how the modelling techniques I use relate to Pegasystems’ Direct Capture of Objectives approach, so here is a brief introduction.
Pegasystems says that “Direct Capture of Objectives (DCO) is a suite of features that enable project team members to directly capture, organize and manage business specifications inside of Process Commander and associate them with the specific parts of the application that are implementing them.”
Continue reading Pegasystems’ DCO: an analyst’s perspective
As an analyst, it’s not enough to know what your customer wants. It is essential to unearth what the customer needs and how the customer’s business will benefit by fulfilling that need.
Customers are often the last to understand what their business truly needs, even when they have a clear idea of what their software requirements are. Over the years I have often wondered why this is so and I think I have some answers.
Continue reading What is the business benefit?
Wrong answer!
We don’t care.
That is, presenting Yoda Rowan Manahan (to whom I am a mere presenting padawan) and I don’t care.
Rowan explains why in an excellent post titled “I don’t care how you make the sausages“.
“Hhhmm… Bullet points…. Harrumph… Generic graphics… A presenting Jedi seeks not these things.”
Just as functional requirements are traced from business need to implementation, data requirements should be traced to eliminate redundancy and ensure coverage.
The following slideshow lays out my procedure for tracing data requirements.
|
|