Lean Use Cases: Part 1

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

• Lean Use Cases: Part 2
• Process Exercise: 6/6
• Four Monkeys

Kind regards,

Declan Chellar