In Lean Use Cases: Part 2, I promised I would talk about documenting business rules and data items relevant to a use case. Here I am, fulfilling that promise.
Imagine a holiday company requires a system that allows it to, among other things, take bookings for holidays. I have modelled a “Take Booking” use case in activity diagram form.
You will notice that I while I have made references to data and business rules, the specifics do not appear within the diagram. Those details are held in a spreadsheet. The reason for this is maintainability and reusability of the rules and data items and to facilitate logical data modelling.
If you look at the diagram and the spreadsheet, you will see that the diagram and the business rules make reference to each other using a combination of use case step numbers and rule ids. You will also see that the spreadsheet can be filtered to see which use cases use which rules and data items.
By documenting the rules and data items in this way, you have a central repository for both. This allows analysts to check for existing rules and data items before adding them to a new use case.
It also allows us to maintain rules and data easily, since the details are held in one place.
The price you pay for this approach is that you cannot understand the full detail of the use case without opening the spreadsheet. Some reviewers will not like that, because it means a little more work for them when reviewing the use case. But I believe that the advantages outweigh this one drawback and so I make it my business to sell the idea to the reviewers.
By the way, the purpose of this post is not to show a perfect “Take Booking” use case, so no suggestions on how to improve the use case itself, please.
Benefits:
- Business rules, data items, notifications, SLAs, etc, are easily maintainable (saves time in the long run).
- Business rules, data items, etc, are easily identified for re-use (saves time and effort in the long run).
- Facilitates logical data modelling, which is essential to good physical data modelling (poor physical data modelling causes worsening system performance over time).
- No voluminous use case specifications
Drawbacks:
- Some extra effort is required in reviewing a use case.
Related posts:
Leave a Reply