Continuing on from Use Cases in PRPC – Part 2, the following tables will give Pega Business Architects an idea of how to use PRPC’s “Use Case Rule” to capture details about your Software Use Case.
The “Definition” Tab
| Business Objective | Optional. In any case, PRPC does not show BOs in traceability reports. |
| Trigger | This is not a trigger in the sense of the business event which initiates the SUC, rather it relates to the medium through which the trigger is expressed. The default list is not always ideal. Let the LSA choose the trigger if you are in doubt. |
| Status | Choose an appropriate status. |
| Actors | If the Actor you want has already been documented, start typing and then choose from the list. Otherwise, type and add. Be careful not to add a variation of an Actor that already exists. In a SUC, the Actor represents that which invokes the SUC. Actors can be human, other systems or even an abstract concept such as “Time” (in the case of scheduled events).In an SUC, the System that is being built is never an Actor. |
| 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 of the SUC. |
| Shape | Always choose “Sub process” for a SUC. This will allow PRPC to link your SUC to a Flow Rule. |
| 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) | Provide the names of the people who are the business SMEs for this SUC. |
| Pre-conditions | List any conditions, in natural English, which must be true before the Actor can invoke this SUC. Pre-conditions are mutually exclusive unless otherwise stated.Document dependent pre-conditions in the same row (e.g., Sun is shining and it’s a Tuesday) |
| Post-conditions | List any post-conditions. Prefix them according to the relevant flow, e.g., PF: [any post-conditions for the Primary Flow]; AFn: [any post-conditions for Alternate Flow n]; EFn: [any post-conditions for Exception Flow n].Note: an individual flow through a SUC may have more than one post-condition, but at least one of them must match the wording of the name of the SUC. E.G., a SUC called “Amend address” must have a PF post-condition “Address amended”, although it may have more. By definition, any Alternate Flows should have at least the same post-conditions as the Primary Flow (and sometimes more). Recording the same post-condition for the PF and AFs is not redundancy, but part of the rigour of analysis to ensure that the AFs are genuine AFs and not exceptions. |
The “Description” Tab
Complete the table below for each Software 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.
| BUSINESS DETAIL | |
| Business Context: | Write a statement that sets the greater business context within which the SUC sits. The structure of a user story is ideal:“As a [business role] I/we need to [do something] in order to [achieve something of significance to the business].” |
| Triggering event: | Describe the event which triggers the SUC, e.g.:
|
| Goal (intent): | Provide a single sentence to describe the goal. This must be compatible with both the SUC name and the post-condition of the primary path. |
| Interfaces: | List any other systems this SUC needs to interface with. |
| Includes: | List any SUCs which must be included by this one. |
| Extended by: | List any SUCs which may extend this one. |
| Primary Flow overview: | Describe the primary path succinctly in a single paragraph. |
| Alternate flow occur when: | Identify all the alternate paths by listing the circumstances which trigger them, but do not describe the paths themselves. Label the paths AF1, AF2, etc. |
| Exception flows occur when: | Identify all the alternate paths by listing the circumstances which trigger them, but do not describe the paths themselves. Label the paths EF1, EF2, etc. |
| Volumetrics Primary Flow: | Provide business volumetrics for the primary path. |
| Volumetrics Alternate Flow n: | Provide business volumetrics for each alternate path. |
| Volumetrics Exception Flow n: | Provide business volumetrics for each exception path. |
| Business Priority Primary Flow: | High/Medium/Low from a business perspective. |
| Business Priority Alternate Flow n: | High/Medium/Low from a business perspective. |
| Business Priority Exception Flow n: | High/Medium/Low from a business perspective. |
| Business notes: | |
| TESTING DETAIL | |
| Acceptance criteria: | List the draft acceptance criteria. |
| Testing notes: | |
The “Requirements” Tab
The SUC should link to high-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
During Elaboration, you will visually model the flows of the SUC in business terms. You should attach the relevant Visio file via the Attachments tab. Maintain each version of the diagram on a separate tab within the Visio file and update the attachment each time. Make sure the checkbox to include the file in documentation is unchecked.
Also attach a JPG of the latest version of the diagram. Make sure the checkbox to include the JPG in documentation is checked.
The “Comments” Tab
Optional.
The “Implementation” Tab
The links to Rules which implement the SUC are maintained automatically if the SUC is linked to a Sub Flow.
The “History” Tab
In the Usage field on the History tab, list all the AUCs which relate to this SUC (once they are known).
Related posts:
Leave a Reply