ID: UC 17
Preconditions:
- The student is enrolled in the university.
Postconditions:
- None
| User Intention | System Responsibility |
| Student identifies himself
Choose seminar Confirm enrollment |
Verifies eligibility to enroll via BR129 Determine Eligibility to Enroll.
Indicate available seminars Validate choice via BR130 Determine Student Eligibility to Enroll in a Seminar. Validate schedule fit via BR143 Validate Student Seminar Schedule Calculates fees via BR 180 Calculate Student Fees and BR45 Calculate Taxes for Seminar. Summarize fees Request confirmation Enroll student in seminar Add fees to student bill Provide confirmation of enrollment |
Essential use cases are typically written in two column format, the column on the left indicates the intention of the user/actor and the column on the right the system’s responsibility to hopefully respond. The actor(s) will try to do something and receive one or more responses to that action. As you can see the flow of the use case is apparent from the spacing of the actions and responses, although you may decide to number the steps to make it more apparent.
The use case refers to business rules but does not embed the rule in the use case, reflecting AM’s practice of Apply the Right Artifact(s). This is a style issue, albeit one that over the years has enabled me to travel light by only recording information in one place (other artifacts will need to refer to business rules as well).
Notice how I’ve chosen to indicate a unique identifier for the use case as well as its preconditions and postconditions. These three pieces of information are optional although very useful. I indicate an identifier whenever I need to reference an artifact somewhere else – for example the use case itself references business rules, each of which have a unique identifier. The preconditions, if any, indicate what must be true before this use case is allowed to run. The postconditions, if any, indicate what will be true once the use case finishes successfully.
A significant advantage of essential use cases is that they enable you to stand back and ask fundamental questions like “what’s really going on” and “what do we really need to do” without letting implementation decisions get in the way. These questions often lead to critical realizations that allow you to rethink, or reengineer if you prefer that term, aspects of the overall business process.
When you are essential use case modeling you can be technology independent but you will never be perfectly “system independent”. You will always be bound by the scope of your effort, but the vision/goals of your project. As a result the perceived system that you’re building, be it manual, automated, or a hybrid of the two, will always affect your how you write your use cases.
Why essential use cases? Traditional/system use cases typically contain too many built-in assumptions, often hidden or implicit, about the underlying technology implementation and the user interface yet to be designed. This is a good feature during your analysis and design efforts, but not so good for your requirement efforts. An essential use case, on the other hand, is based on the purpose or intentions of a user, rather than on the concrete steps or mechanisms by which the purpose or intention might be carried out.
Source
This artifact description is excerpted from Chapter 5 of The Object Primer 3rd Edition: Agile Model Driven Development with UML 2.