I have had discussions with colleagues about use cases (and seen discussions on LinkedIn) where it is clear that some people do not understand that there are different types of use case, so I hope the following definitions help.
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.
A BUC is often supported by several Software Use Cases.
Software 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”).
A SUC is often supported by a one or more Technical Use Cases.
A SUC is often supported by one or more UI Specifications.
Several SUCs can be represented by a Workflow.
Technical Use Case
A technique to describe, in implementation terms, how the target 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 within a SUC.
The following definitions are useful if you are involved in workflow solutions:
Work Type
A work type defines the kind of item that will be processed in a Workflow System. A work type is represented as a work object to an end user.
Workflow
A workflow can be described as a repeatable collaboration of tasks (each of which may be represented by a SUC) that affect an identified piece of work (work type), across multiple roles. The workflow is governed by business rules. The flow begins with the generation of the work type and ends with the resolution of the work type.
Inexperienced analysts often confuse SUCs with screen flows. A poorly written SUC talks about clicking on buttons. This is not a good idea because the SUC should focus on describing what the business needs the system to do. Buttons, drop-down lists, checkboxes, etc, are all part of how the system does what it needs to do and belong in the realm of high-level design.
Moreover, when analysts write SUCs as if they were screen flows, they cause confusion because they start to talk about clicking the “Cancel” button instead of the “Confirm” button as if it were an alternate flow within the SUC, which it is not.
UI Specification
A technique for describing each required User Interface in terms of what needs to appear on the screen (data) and how the screen needs to behave. This technique describes the screen elements that are needed in conceptual terms (e.g., a widget to enable to User to select among several options), but not in concrete terms (e.g., a drop-down list). A UI Specification represents a single screen.
Screen Flow
A technique for illustrating all possible paths through the screens that support a specific set of SUCs, indicating what concrete UI elements trigger the movement from one screen to another along the path (e.g., “Submit” button).
I hope this helps.
Kind regards,
Declan Chellar
A colleague on my current project has pointed out that in his experience, the label “Business Use Case” is applied to what I have called “System Use Case” above and what I called a “Technical Use Case”, he calls a “System Use Case”.
His point is valid and now that I think back to my early days in analysis, the group I was working for then used the same labelling as my colleague.
The labelling I used above is not my own, but is used by other organisations.
The important thing is that my colleague and I agree on the definitions themselves, regardless of the label. The important thing for you is to make sure there is consistency of terminology within your organisation or at least within your project.
Hi Declan,
This is very important discussion in all projects which are scratching heads to agree upon definitions.
From your definition above, if possible could you take a simple example and explain which use case will have UI details or work flow details please.
Thank you
Radha
Hello, Radha.
A Business Use Case can be modelled as a Business Process Diagram (I would do so using BPMN 2.0). Since a workflow is just a type of business process, then it is either modelled as a whole business process or a sub process (see my series of posts titled “Process Exercise”.
UI details do not appear in use cases of any type. There is no connection at all between BUCs and UI details, simply because BUCs are just about the business processes.
Although UI details do not appear in SUCs (because SUCs only model the logical Actor/System interaction), you can have traceability between a SUC and the candidate screens which support it.
Does this answer your question?
Regards,
Declan
Hello Declan,
Thanks for bringing out this important topic of differentiating the type of usecases.
In my experience, I have developed SUC which primarily captures the System-Actor behavior and also we add lot other information like, UI Screenshots, Data Definitions,Business Rules. From the implementation point of view, we develop Functional Specifications (= Technical Use case stated here) which captures the actual mode of useage to the users.e.g. like Dropdown list, Radio buttons, etc.. and also other non-functional requirements.
I would like to add a Example for each of this here where you can correct me if I am wrong.
Since I have a bit of insurnace domain knowledge and comfortable with that, I will try to quote the example from the same.
Business Use Case (BUC)
The application shall support the claims analyst in Claims processing
System Use Case (SUC)
One of the use case could be – Claims Analyst will be able to ‘Approve Claims’ submitted by a member.
Technical Use Case (TUC)
The technical use case will elaborate the necessary actual implementation UI properties (fields), data definitions, Constraints,etc..
To relate it with the PEGA (I am a beginner) for this example scenario
Work Flow – Is the ‘Process Claims’ buiness process
Work Type – is the Approve Claim
Work Object – The end result of performing the Approve Claim transaction.
Could you please provide your inputs to this which will help us in understanding the concept.
Cheers,
Anand
Hello, Anand.
Your use case statements are worded more like high level business requirements of the kind I would expect to see in a Request for Proposal or a scope document.
An example of a BUC in the insurance industry would be “Process Claim”. Depending on the nature of the process desired by the insurance company, the start point could be (for example) when the claimant chooses to submit a claim or when the claims department receives a claim from the claimant. I imagine the process would end when the claim is either paid, rejected or cancelled.
A related SUC would be “Review Claim” (i.e., a sub process within the “Process Claim” BUC). It is very common to put the word “Approve” into the name of a SUC where someone is reviewing something. Use Case names should reflect the actor’s intention. In this case, the actor does not intend to approve the claim. The intention is to review it and approval is just one possible outcome.
A TUC is a design artefact and contains details about how the technical solution to a particular need expressed within a SUC. The TUC does not contain details of data definitions, UI fields, etc.
A workflow can, but does not necessarily, equate to a whole business process. In order to identify the boundaries of the workflow, we must identify the Work Type. In this case, the Work Type is the Claim. In modelling our claims process, the workflow begins when the Claim itself is generated on our proposed system. The Work Type (Claim) is a conceptual thing from the BA’s point of view. The technical implementation of the Work Type is the Work Object. You could say that Work Objects are actual instances within PRPC of a conceptual Work Type.
The Work Object is not a result. The result is the final status of the Work Object.
I hope this helps.
Regards,
Declan
Hi Declan,
Thank you for responding to my query.
In your work sessions, how do you gather UI requirements and screen flow requirements. Am assuming these requirements are not captured in use cases.
Another question is when you say system use case – will it include the requirement like one below:
– User has ability to search for related services
OR
– Pega will provide local action to search for related services.
Many thanks,
Radha
Hi Declan,
Appreciate your response!
Which tool do you use to capture screen navigation?
Cheers,
Radha
Radha, if your project is all about workflow and being implemented in PRPC, then I would just use the Flow Rules to express the screen navigation.
However, on non-PRPC projects I use Visio. I will make up an example of a screen flow diagram done in Visio. Watch this space.