Describing Alterantive Courses of Action in Use Cases

Title: Describing Alterantive Courses of Action in Use Cases
Type: Rules
Status: final
Version: 2007-08-28
Gist: explain how to model alternative corses in use cases, which can be represtented in purely textual, tabular and grafical fashion. Use case descriptions should provide both an overview and a detailed view. They should clarify for the reader a certain set of scenarios. The use cases context is a set of constants.
Definition: Scenario: one single complete path through the use case
Source: David Gelperin (Modeling Alternative Courses in Detailed Use Cases, LiveSpecs Software, 2003), Tom DeMarco (Structured Analysis and System Specification, Prentice Hall PTR, Upper Saddle River, NJ, 1979), some minor adjustments from my point of view.

R0: The general size rules for use cases apply.

R1: An alternative course of action is either of four types: {Exeption Handler, Required Selection, Optional Action, User-invoked Interrupt}
Exeption Handler: a scenario with an exeption handler does NOT yield a useful business result; in the sense of the use case.
Required Selection: The actor or the system has to select from a number of options and the chosen option determines the next segment of the scenario. the scenario will yield the useful business result in the sense of the use case unless another alternative course says otherwise. It is possible to state "do nothing" as an option, but only if this is not the most frequent option. If it is, use optional actions instead.
Optional Action: some possible segment is included in the scenario. It does yield a useful business result in the sense of the use case.
User-invoked Interrupt: The actor decides to continue with a scenario of a different use case. This other use case has to be described if part of the system. There is NO useful business result in the sense of the use cases (but maybe of the other use case)

R2: There is exactly one sceanrio that represents the most frequent course of events. ' aka main scenario

R3: Each start of a segment of a scenario is associated with a number between 1 and 99. It represents the probability of this segment to occur. The number is the analyst's best guess. Fill it in square brakets.

R4: The sum of all probabilities of a decision point is 100.

R5: Exeption Handlers[text] should begin with "UNLESS". Exeption handlers[graphics] should be signalled by the term "exeption" near the transition between decision and first action of the handler.

R6: Required selection[text] should use IF-THEN-ELSE-clauses. Required Selections[graphics] include an action preceeding the decision, that provides the selection

R7: Optional Actions[text] should use a short and descriptive name in square brackets, placed at the point(s) of insertion into the main scenario. Optional actions[graphics]: same..

R8: User-invoked Interrupts[text] should include an explicit link to the other use case. User-invoked Interrupts[graphics] should make use of "goto" marks

R9: Each use case is supported by real world numbers of its occurence.