1

I have a use case for which a user can perform a multiselection. I am writing the use case description and wonder: Should the selection action be documented as a trigger of the use case, or in the main success scenario?

Below are the variants I am considering. I think the last one is probably best, but I'm not sure if selection belongs in main scenario:

Variant 1: Selection as trigger, multiselection as extension:

Use Case 0: Provide brightness property
    ...
    Trigger: User chooses to see the brightness property for selected Thing T in list.
    Main Success Scenario:
      1. System presents brightness property for T.
    Extensions:
      ?a. User selects more than one Thing in list.
          ?a1. System *calculates brightess* for selection and displays result.

Variant 2: Selection in main success scenario, multiselection as extension:

Use Case 0: Provide brightness property
    ...
    Trigger: User reaches main feature view.
    Main Success Scenario:
      1. User selects Thing T from list.
      2. User chooses to see brightness property for T.
      3. System presents brightness property for T.
    Extensions:
      1a. User selects more than one Thing.
          1a1. System *calculates brightess* for selection and displays result.

Variant 3: Multiselection in main success scenario, selection deferred to calculation function spec:

Use Case 0: Provide brightness property
    ...
    Trigger: User reaches main feature view.
    Main Success Scenario:
      1. User selects subset S of Things.
      2. User chooses to see brightness property for S.
      3. System *calculates brightess* for selection and displays result.
    Extensions:
      . . .
1

In short

There are no formal standards for a use-case description, so you are free to present it as best suits your needs, provided you are consistent withe the other use-case specifications and define well your convention.

Considering the widely used practices and the recomendations of popular authors, the second alternative will nevertheless be understood by most of your readers and therefore seems the most suitable. The third could be a good choice only in limited situations.

Some more details

I’ll base my answer on Cockburn’s book, Writing effective use cases, since you seem to specify your use-case based on hist template:

  • Variant 1: it is an acceptable approach. The trigger specifies the start of the use-case. It may either be its first step or an event that precedes the use-case (page 84 of Cockburn’s book). Consistency with your other use-cases in this regard is key. Personally I would not recommend it:

    • despite Cockburn’s claims, I think it creates some fuzzyness about the exact scope of the use-case;
    • having the first step presented differently is not consisten with the other steps. Moreover it creates difficulties, for example if the first step is repetitive or, as you showed it very well, if there are alternative flows (i.e. numbering issue);
    • therefore I strongly suggest to use the trigger to describe events or intents that lead to the use case but are not part of it. Example: User is not satisfied with brightness
  • Variant 2: it is the most common approach. No surprise, no ambiguity, everybody should understand it. Cockburn uses it in a lot of examples throughout his book, and it's certainly not without reason that it's so popular.

  • Variant 3: (EDIT) In my initial answer I misunderstood step 1 and 2 as being alternatives, which would not be a good solution.
    Use-cases are user-centric and related to user goals. It might therefore be misleading to artificially present as a unique main scenario something that is perceived as different cases by the users. I'd therefore recommend to avoid it: the over-generalisation does not help to realize that there are in reality different situations. Such simplification would at some moment require you to catch up, especially if use-cases are used for defining test scenarios or for user-manual production.

The last variant requires however some more thoughts. I don't know your domain of application and I answered by assuming that selection and multiselection is not perceived the same way by the user and may imply different behaviors. But, if the simplification corresponds to a more general description, i.e. in your case the selection and multiselection would indeed work exactly the same, except for the number of items that are initially selected, then this third case could indeed be the best option.

3
  • thank you. I agree that variant #2 is the clearest. Jun 18 at 20:01
  • another thought: is 'selection' an implementation detail? Jun 25 at 14:42
  • @user2132190 “Implementation detail” is indeed what I tried to describe in my last sentence. More generally, I’m a big fan of “essential use cases” where intents are described and the description of how the user performs these is an unrelevant detail
    – Christophe
    Jun 25 at 21:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.