(S.4) Detailed usage scenarios

[mosser]

Examples of interaction between the environment (or human users) and the system, expressed as user stories. Such scenarios are not by themselves a substitute for precise descriptions of functionality (<>), but provide an important complement by specifying cases that these behavior descriptions must support; they also serve as a basis for developing test cases. The scenarios most relevant for stakeholders are given in chapter <> in the Goals book, at a general level, as use cases; in contrast, <> can refer to system components and functionality (from other chapters of the System book) as well as special and erroneous cases, and introduce more specific scenarios.

[mosser]

No text available for review (forgot to push?)

[t-chiang]

Restaurant manager sends invoice through app to mosaic, NOT admin assistant using app to pay. Need to change scenario 3 to match this new usage scenario.

[mosser]

Global:

• We need to chose if one scenario = one use cases, or if we define scenario that crosscuts UCs.
  • If we go the the latter, we need to add in the template which use cases are included in the scenario.
  • I'd be in favor of sticking to 1UC = 1 Scenario.
  • We need to harmonize vocabulary: Web-portal or WebAdmin ?

Usage Scenario 1:

• Student not an actor. Community member?
• Make explicit meal boxes instead of regular menu?
• Should student select their picku-up slot when ordering?
• Should 1.2 be part of the nominal scenario ?
• Cosmetic: Any chance to "shrink" the activity diagrams so that they take less space?
• The "does student wants to pay" decision looks weird in the flow.
• Exit app is present twice
• guest mode was never mentionned elsewhere in the spec. Should we consider it?

Usage Scenario 2:

• Looks like this scenario covers both "List Impeding food order" and "finalize ordr" use cases. We should split them, or merge the 2 UCs if they are a single one (I'm not convinced it's the case).
• Should we put in the scenario that Line cook use a physical device to flush the order (greasy hands)? Needs to be consistent with G5 description.

Usage Scenario 3:

• Should be renamed "Submit Catering order" to match use cases.

Usage Scenario 4

• Cosmetic: I'd switch 4 with 5, as it l;ooks less valued in terms of added value for the Firebird

Usage Scenario 5

• Trigger: "needs a drink" but we're not ordering drinks through the system? Or do we as part of the mealbox?
• Precondition: Picnic at cootes while attending a conference looks like a weird combo.
• This scenario triggers an ambiguity question: what is part of ATCO in terms of food? Only mealbox (the only thing that one can directly order in the app), or complete menu?

[t-chiang]

Global:

We need to chose if one scenario = one use cases, or if we define scenario that crosscuts UCs. If we go the the latter, we need to add in the template which use cases are included in the scenario. I'd be in favor of sticking to 1UC = 1 Scenario. I was trying to maintain 1UC = 1 Scenario. Not sure where there is cross cutting. 5 actors = 5UC = 5 Scenarios

We need to harmonize vocabulary: Web-portal or WebAdmin ? -> website? We used the word portal when talking about it but document doesn't specify web portal for staff

[t-chiang]

Usage Scenario 1:

• Student not an actor. Community member? -> Fixed
• Make explicit meal boxes instead of regular menu? -> Fixed
• Should student select their picku-up slot when ordering? -> Step added. Default to ASAP pickup
• Should 1.2 be part of the nominal scenario ? -> added condition that user is NOT already logged in
• Cosmetic: Any chance to "shrink" the activity diagrams so that they take less space? -> scale reduced from 60% to 40%. A little more difficult to read but can be zoomed in on.
• The "does student wants to pay" decision looks weird in the flow. -> need to provide exit option if community member decides they don't want to eat at Firebird anymore
• Exit app is present twice -> Removed one of the exits
• guest mode was never mentionned elsewhere in the spec. Should we consider it? -> usage scenario 5 is guest usage

[t-chiang]

Usage Scenario 2:

• Looks like this scenario covers both "List Impeding food order" and "finalize ordr" use cases. We should split them, or merge the 2 UCs if they are a single one (I'm not convinced it's the case).

• Should we put in the scenario that Line cook use a physical device to flush the order (greasy hands)? Needs to be consistent with G5 description.

Combined use cases for this scenario, pedagogical moment for cross-cutting

[t-chiang]

Usage Scenario 3: Should be renamed "Submit Catering order" to match use cases. -> updated

[t-chiang]

Usage Scenario 5

• Trigger: "needs a drink" but we're not ordering drinks through the system? Or do we as part of the mealbox? -> removed
• Precondition: Picnic at cootes while attending a conference looks like a weird combo. -> fixed: Hamilton citizen opens browser to look for food options during picnic because they didn't pack enough.
• This scenario triggers an ambiguity question: what is part of ATCO in terms of food? Only mealbox (the only thing that one can directly order in the app), or complete menu? -> Specified mealbox menu

[t-chiang]

Usage Scenario 4 Cosmetic: I'd switch 4 with 5, as it l;ooks less valued in terms of added value for the Firebird -> 4 and 5 swapped

[mosser]

• updated numbering of sections to be consistent with rest of the document
• changed layout of activity diagrams to save space
• S42: removed ack for order, not compatible with the requirements that they used physical devices to flush (or we need another device).
• S5: rewrote intermediate step to include actual ordering and payment. It is an alternative implementation of the first scenario => might indicate flaky used case decomposition.