Use cases are a good mechanism for modelling functional requirements. However, I have met many skilled developers in the BPM world who disdain them and I think I know why.
Use cases were invented for Object Oriented development using an OO programming language and so have certain characteristics that facilitate that type of development. They detail every interaction between the Actor and the System because the next step after a use case is to produce the corresponding Object Sequence Diagram. OSDs can be used by analysts to validate the logic of the use cases but the main purpose of the OSD in design is “to show the interactions between objects in the sequential order that those interactions occur” (Donald Bell of IBM). Without detail in the use case, the corresponding OSD cannot be produced.
However, if you are using a BPM development tool such as Pegasystems’ PRPC, you will not need an Object Sequence Diagram and so you will not need to produce a use case in the same detail as you might see traditionally.
I feel the main drawback of traditional use cases is that when you produce use case specifications, you can end up with quite a weighty document. Iterative methodologies such as the Unified Process help, but you still end up with a thick tome which takes time to produce and to review.
On one project I realised I needed to adapt the use case approach. A considerable amount of time had already been spent on producing very weighty, but hard to read requirements documents. I was brought in to mentor the analysis team.
They had presented the detailed requirements in the form of a requirements catalogue. In my opinion, requirements catalogues are fine for high level requirements that define the scope of a project, but are unsuitable for the lower level of detail because they do not make flows of functionality clear.
I recommended that the analysts switch to a use case approach for the functional requirements. This was approved by the various managers and I proceeded. The analysts were inexperienced but capable and keen to learn. However, it soon became clear that writing out full use case specifications was consuming time that we simply did not have. I think this is why some BPM developers don’t like them. I had to come up with a technique that would be quicker without losing any detail.
I took inspiration partly from the RUP principle that you should model visually. Years ago, as a junior analyst, I was taught to produce the textual use case specifications first and the visual model as an afterthought. As I gained more experience, I realised it should be the other way round. Of course, a visual model of a use case (such as an Activity Diagram) cannot hold such details as logical data and business rules, just references to them – but then the textual use case specification just held those same references.
Then it dawned on me that the textual specification was mostly redundant (the Activity Diagram covered all the steps of every flow). However, I had continued producing them out of habit (see Four Monkeys).
I further realised that the Activity Diagrams still detailed all the User/System interactions as if they were going to feed into OSDs. One of the Pega architects challenged this.
For example, in a use case called “Add Student”, you might see the initial steps as follows:
1. Actor elects to add student
2. System requests Student Details
3. Actor provides Student Details
My Pega colleague wanted to know why last two steps were not covered by just one step which said:
2. Actor captures Student Details
My initial response was that use cases are meant to show every User/System interaction.
But I went away and thought about it (as I tend to do whenever I am convinced I am right). I quickly realised that without proceeding to a full OO design, there was no point in such detail. “Actor captures Student Details” sufficiently represented the functional requirement, so I taught the analysts how to adjust all the Activity Diagrams accordingly.
To support the diagrams, I adapted a spreadsheet format the team was already using to record the logical data and logical business rules. There was a single spreadsheet for the whole project, which minimised the risk of different analysts logging the same data item or business rule more than once. The steps in the various “lean” Activity Diagrams made references to unique identifiers in that spreadsheet.
The result was a success. The requirements documentation was easier to understand from the point of view of the developers and testers and was quicker to review for everyone, including the customer, simply because there was so much less to read.
To illustrate what I mean, in Part 2 I will compare a textual use case specification with its corresponding activity diagram.
Takeaways
- Keep requirements documentation as lean as possible
- Do not be afraid to question current approaches
- Always be ready and willing to adopt new approaches
Related Posts
Kind regards,
Declan Chellar
Within this post you stated:
To illustrate what I mean, in Part 2 I will start to elaborate the use cases identified in my Change Request Workflow Diagram
I read Part 2 (and then parts 3 and 4) but there is no elaboration of use cases relating back to the Change Request Workflow Diagram. Have you done this somewhere else in separate post(s)? I was hoping to see this as I read the other posts re the process example, moving from “as-is” workflow diagram to “to-be” workflow diagram etc (which have been explained very well by the way) and I was hoping to see derived SUC’s relating back to this…..
Regards
Adam
Hello, Adam.
You’re right. I never got round to elaborating those Change Request use cases. I will get onto it in the next couple of weeks. Before that, I have to update the CR workflow diagram itself to bring it in line with BPMN 2.0.
Earlier this year I took a course in BPMN 2.0 and got myself certified. I did this because I realised that while I was using the BPMN 2.0 shapes in my process diagrams, and I was using them consistently, I was not always using them correctly. I have since updated the diagrams for the CR process itself, but I have yet to update the workflow diagram. Once I have done that, I will elaborate the use cases as promised.
Thanks for pointing this out, as I had not noticed the omission.
Regards,
Declan
Hi Declan,
Fantastic, I look forward to seeing those.
I’ve only been using BPMN 2.0 myself since November last year. I brought a copy of Bruce Silvers ‘BPMN Method and Style’ and have found it to be an excellent resource. At the company I work for, I’ve since modelled with it quite extensively on a number of projects and the feedback from the business stakeholders has been great; most importantly, they can read and understand what is going on. I like the fact that BPMN gives you the ability to easily model event-driven behaviour (such as your SLA example on the leave request example in your ‘Introduction to Workflow’ series).
I’m a big fan of using (system) Use Cases and have been using them for some time now to help specify functional requirements where a software solution is involved. I like your piece on ‘Light Use Cases’ and am trying that out on a current project. One thing you might be able to clarify for me – and this may indeed become clear when you elaborate the use cases – from what I’ve read on your site so far:
1. When modelling Workflows/Business Process you are using BPMN
2. When using (Light) Use Cases to help model functional requirements you are using UML activity diagrams.
From your ‘Leave Request Workflow example’ from stated requirements you mention “The last four statements are worded in such a way that they could be investigated either as use cases or as user stories. This is an important point: the high level statements of requirement should not impose or suggest a particular methodology.”
Assume for this example that I chose to go with (light) Use Cases for each, it seems to me that from a modelling point of view I could use UML activity diagrams or BPMN to visually express those Use Cases. Your thoughts?
Thanks
Adam
Hi, Adam.
You are right. In modelling the internal logic of each SUC, you could use either an Activity Diagram or a BPMN Process Diagram. In fact, the sub-set of the BPMN palette of shapes is very similar to the palette of shapes you would use in an Activity Diagram, so I’m not convinced there is much of a difference.
If you follow this link and scroll down on the page that opens up, you will see a chart that highlights the different uses for UML and BPMN:
http://www.bcs.org/content/conwebdoc/6862
You will notice that for modelling process behaviour, the British Computer Society agrees that you can use either Activity Diagrams or BPMN Process Diagrams.
All the best,
Declan