At times, gathering requirements can be tedious, difficult, and not much fun. Not nearly as fun as using stick figures and shapes to tell a story. Giving in to creativity like this is so appealing that my three-year-old daughter does it without prompting. She just likes to draw pictures that tell stories. So do I.
Thus, I remain convinced that the allure of use cases is rooted in the idea that requirements can now be specified by simply drawing shapes and arrows on a diagram. Gone are the days of laboring through the process of gathering and managing countless requirements spread throughout different documents. It seems too good to be true. Because it is.
In reality, those details will still exist in the information behind the simple figures on your diagram. But if all that detail is still there, why bother with the diagrams? Well, let's talk about what a use case diagram is and what role it plays in specifying requirements.
What's On a Use Case Diagram
Use case diagrams have just three things on them:
- Actors
- Use cases
- Relationships
That's it. The stick figures symbolize actors - the roles played by users of the system. The ovals symbolize use cases - the things actors accomplish with the system. The lines show how actors and use cases are related. In the example above, we can see that a Subscriber can Read articles or Leave comments; only Authors can Post articles; and Moderators can Moderate comments.
The most important word in the previous paragraph is symbolize. On the diagram, those ovals aren't actually use cases. Each oval is an indicator that a use case exists - the detail that describes the use case is still there, written in textual form and somehow linked to that oval. The link might be supported by a tool - or it might exist only in your mind.
At the risk of insulting use case experts - I want to clear up a common misconception among people new to use cases. A use case diagram is NOT like a flow chart. The diagram is not meant to show the sequence of steps an actor takes when using the system.
Why Create Use Case Diagrams?
If you're thinking that use case diagrams seem a tad simple, it's because they are. They don't contain a lot of information. So why bother creating them?
These diagrams are yet another way the use case approach differs from traditional methods of gathering requirements. The use case diagram is a roadmap, a high-level view of the requirements that exist in the system. No other approach to gathering requirements has this element.
The purpose of gathering requirements is to communicate. As I said at the beginning of this post, requirements gathering can be tedious, difficult, and not much fun. Requirements grow to contain a lot of detail and and become increasingly more difficult to communicate and understand.
Use case diagrams make requirements more approachable and understandable by allowing someone to quickly visualize what the system needs to do. They allow you to brainstorm at a whiteboard as you decide what major functions your system needs to perform. In short, use case diagrams make it easier to communicate your requirements.