The following event table describes three typical interactions a customer would have with their bank:
Each of these events can be drawn as a separate use case:
These individual use cases (fragments) are only half the picture however. Today developers don't write individual software programs for each event, particularly when multiple events will have numerous common components e.g. database enquiry, ID validation, etc. What we do want is to be able to combine use case fragments into a single use case. We do this by identifying and sharing common actors (in this example the customer):
While we still need to write individual descriptions for each use case, we've given the developer a concise package of functional requirements, offering them the best opportunity to write efficient and effective code. For an example of writing formal use cases see the paper How to use Use Cases.
Author: Jan Kusiak, Training Services Manager, IRM Training Pty Ltd
brought to you by enabling practitioners & organizations to achieve their goals using: