Build a use case diagram based on user interviews.
Building the Use Case Diagram based on user Interviews
You saw all the use case diagram notation in the previous lessons.
What you have not seen is how to build the diagram using a problem description. Use the simulation applet to step through a sample build process for the
use case diagram using the following problem statement.
Our bank wants to redesign our checking account system to find opportunities to take advantage of new technologies.
By improving the system, we hope to provide our customers with more options for using their checking accounts.
"Currently, customers are required to use our tellers to make deposits and withdrawals. With ATMs and home banking,
customers should be able to perform these transactions themselves. Furthermore, we should be able to make transfers between checking and savings types of accounts simpler too.
Our bank staff will still need to be able to make adjustments. You know how unreliable computer systems are."
"Please do not forget that our preferred customers do not have any holds placed on their deposits.
All preferred customer deposits clear immediately. It would be a disaster if the new system changed this rule."
What the UML describes is a use case diagram, which shows how use cases relate to each other.
But almost all the value of use cases lies in the content, and the diagram is of rather limited value.
UML is silent on the content of a use case but does provide a diagram format for showing them, as in Figure 1.
Although the diagram is sometimes useful, it is not mandatory. In your use case work, do not put too much effort into the diagram.
Instead, concentrate on the textual content of the use cases.
The best way to think of a use case diagram is that it is a graphical table of contents for the use case set.
It is also similar to the context diagram used in structured methods, as it shows the system
boundary and the interactions with the outside world. The use case diagram shows the actors, the
use cases, and the relationships between them:
Which actors carry out which use cases
Which use cases include other use cases
The UML includes other relationships between use cases beyond the simple includes, such as
I strongly suggest that you ignore them. I've seen too many situations in which teams
can get terribly hung up on when to use different use case relationships, and such energy is wasted.
Instead, concentrate on the textual description of a use case; that's where the real value of the
Build Use Case Steps
In the next lesson, the use case narrative will be discussed.
Use Case Diagram Steps
Steps in building a use case diagram.