If the alarm is important, you may need to include a Confirming Step:
This variant has the following different consequences to the main pattern:
A pattern for alarms
We have identified at least 18 use case patterns overall, and space does not
permit us to include them all in this paper [6]. Figure
presents a précis of one of the first patterns we
identified, the Alarm Use Case Pattern. The problem this pattern
addresses is to write an essential use case to model an interaction where
the system needs to notify an actor about an important event, such as a
change in its internal state or a potential violation of an internal
invariant or business rule. The full pattern form includes rather more
discussion, more variants, and a list of known uses: all of which have been
elided in the figure.
The key to this pattern is that the essential use case to model this interaction begins with the system's responsibility to signal the user, rather than beginning with a user's intention to trigger some kind of alarm: in the first example in the figure (to warn of an undersold performance in a theater) this is the only step in the use case. While perhaps straightforward in retrospect, our experience teaching and working with essential use cases is that use cases following this pattern are counterintuitive at first sight: it is not obvious that a use case can simply involve the system's responsibility for communicating some information to an action, without any requirement for the actor to initiate or confirm that information. Early in our essential use case modeling work we came across several examples that clearly fit this pattern, and generally chose to tolerate them grudgingly. Further experience seeing more examples of this kind of interaction lead us to realize that these interactions could all be modeled using this pattern.