Define use cases and how they are used in the use case diagram.
Define Use Cases
Use cases define the required features of the system. Without these features, the system cannot be used successfully.
Focus on system goals
Each use case is named using a verb phrase that expresses a goal the system must accomplish, for example, deposit money,
withdraw money, adjust account. Although each use case implies a supporting process, again the focus is on the goal, not the process.
Defining Use Case Requirements
By defining use cases in this manner, the system is defined as a set of requirements rather than a solution. We do not describe how the system must work. We describe what the system must be able to do.
The use cases describe only those features visible and meaningful to the actors who use the system. Keeping this in mind will help you avoid functional decomposition, the breaking down of procedures and tasks into smaller and smaller processes until you have described all the internal workings of the system.
Pitfalls of Systems Development
One of the pitfalls of systems development is going over budget, which happens when we don't limit the scope of each task or we make a model too inclusive.
The UML provides seven other models for fully describing the behavior of the software solution for the system, so remember that you can save some ork for later. Step through the process of adding use cases to the use case diagram:
Add a use case to the diagram and label it, to represent a required feature of the system.
Add a second use case to the diagram and label it.
Add the third and fourth use cases and label them, to further describe what the system must be able to do.
Use Case Flows
Reference cited from Alistair Cockburn's Gold nuggets found in his book Writing Effective Use Cases .
Cockburn points out, "We will not actually write every scenario separately from top to bottom. That is a poor strategy because it is tedious, redundant, and hard to maintain." A use case can be written nonredundantly, starting with an unconditional main flow that is subsequently enhanced with conditional additional flows of different kinds, where a flow is a sequence of steps. The main flow equates to the main success scenario and each additional flow represents a portion of one or more of the remaining scenarios.
The UML does not deal with flows. Cockburn only refers to the main success scenario (main flow) and extensions (additional flows). Refining this view, the following sections present five different kinds of flow by providing a definition, diagram and simplified example for each.
The purpose of the examples is to illustrate a clear, consistent and scalable writing convention for representing a use case's structure (they are not meant as full-fledged use case specifications).
In the next lesson, associations and association stereotypes will be discussed.