We frequently find that software development teams defining requirements with use cases face a challenge in finding the right level to target as a starting point for their use cases. There is no widely agreed upon standard and team members often have differing opinions based on their background and experience.
The available tools and templates offer a wide variety of guidance from informal use cases and user stories to extensively detailed templates with sections for alternative and exception flows, «uses» and «extends» relationships, business rules, etc. Unfortunately, little useful guidance is offered to help the team decide where to start. Asking the users “What do you want the system to do?” seems like a particularly ineffective approach.
We know it is not good for use cases to be too big, or to small. The ‘Log on to system’ use case seems to show up in almost every use case diagram with a «uses» arrow from nearly every other use case. But really, what is it good for? And, a 200 page use case covering ‘Purchase Raw Materials’ for example, should probably be broken down into smaller use cases covering less territory. When multiple modelers with different perspectives try to work together the result can be confusion.
So, how do we find the right starting point and level of ‘abstraction’? Process decomposition is a modeling technique for breaking a business process down into progressively lower levels of detail until the ‘appropriate’ level is found. Although decomposition has not gotten a lot of respect in the world of object orientation it can be a very helpful technique if used correctly.
Start with an overall context diagram to encompass the entire business process scope of the project. Identify the high level steps involved in the process. There should generally be three to six of these steps. If you have more than nine or so look for a way to consolidate or group some of them to a higher level. Now, break each of the high level steps down to the next level of detail, again finding three to six sub-steps that make up the higher level step. Continue this process until you find the ‘elementary level’ processes. An elementary level process is one that is performed by a single person, and can be completed from start to finish in one session. (Breaking for lunch doesn’t count.) Stop decomposing at this point. Now you can write elementary or ‘primary’ level use cases where one primary actor performs each use case.
Most often it is best to resist the urge to further decompose the use case model. Use cases are a great requirements communication tool when they are written with that purpose in mind. Object models, collaboration diagrams, and other tools can be much more effective for translating requirements from the ‘language’ of the users to the ‘language’ of the designers. Start and stop your use case modeling at the right level and you’ll be happier and more successful even if you never model another «uses» or «extends».
