Use Case Diagrams for Documenting Scope

Use Cases

I embraced UML as a communication tool some years ago and have found it successful in being able to convey messages in a simple manner. I don’t use every type of diagram – some are too strange for the average business user. I do use Use Case diagrams. These are great and, with a small amount of education, are suitable for use with business users.

Use Case Diagrams for Scope

As a communication tool, Use Case diagrams are great at showing who does what at a very high level. They’re good at showing system solution scope, types of actors and ownership of integration points. In one diagram, I can show the scope of the system in a way that users will understand. Now that’s a powerful tool.

Depth of the Scoping Use Case

Ideally I like to have short Use Cases, perhaps 2 or 3 sentences at the highest level. Used like this, they don’t conform to the more common view of Use Cases, but they do give a good, brief overview of what happens in the solution. More detail is required in later stages, but you can’t beat a concise description to get the ball rolling.

Why use Use Case Diagrams for Change Management?

There’s a system involved. By system, I don’t necessarily mean an IT software application. There are people, teams, dependencies on other organisations, dependency on phone network being available and so on. Often the people in the change team, including the users themselves are not aware of all the interactions that they have with these external organisations (including teams in the same organisation). This is where a simple Use Case comes in. It can show, at a single glance, the main interactions between the team in question and their environment. I use them to gain a joint understanding of what the team does now, or what they’re trying to change to.

Multi-level Use Cases

Originally the concept was that a system had 10-20 Use Cases. If you had vastly more than that, then you were doing it wrong, it you had less than 5, you probably weren’t analysing far enough. Time’s moved on and real-world, practical experience has been added to this. What analysts and software methodologists/project methodologists came to realise was that the power of Use Cases was that they were readable and understandable by users but that to capture sufficient detail, they were becoming unwieldy and cumbersome. Alistair Cockburn has been influential in his work promoting Use Cases at different levels, some will be user and high-level, some more detailed. It does raise the risk of implementing a more traditional waterfall approach where one analysis has to follow on from another.

Use Case Diagrams for Developers

I know that there’s a strong argument for not using Use Case diagrams at all. This comes from developers and I can understand their perspective. That’s fine by me, I expect developers to know what works for them better than I do. In their case, the text of Use Cases counts for more. That doesn’t prevent analysts from using the tool.