Tweaks to Use Case and Requirements doc and process

[mmccool]

• user story prioritization
  Why: what should we work on first? Where should we invest our resources?
  What: High, Medium, Low
• user story status
  Why: Where do specs lie in addressing this story?
  What: Satisfied, Partially satisfied, work in progress, not implemented
• naming:
  Why: Different and diverging definitions of "Use Case" cause confusion
  What: rename as follows
  • Use Case -> User Scenario
  • Horizontals -> Technologies
• User Story motivation
  Why: Sometimes the need for a feature is technical and cannot easily be motivated by a single user scenario,
  ... but it still needs a motivation
  What: change the issue template as follows
  • make purpose mandatory
  • make links to Use Cases (User Scenarios and Technologies) optional

[mmccool]

So one thing I just thought of is that priorities only really make sense (I think) for user stories that are not "Satisfied". Once they are satisfied it's irrelevant - there is no more work to prioritize. So maybe we can have an additional priority of "Completed" that can only be used when the status is "Satisfied".

Alternatively we can make priorities optional and for "satisfied" user stories can leave them out.

[mmccool]

The "Partially satisfied" status should also have some additional information on what the remaining gaps are.

Finally... there may be User Stories that are "ongoing" and never completed, like "Support all relevant IoT protocols"... maybe these should be something else than a User Story, however. Epics? I'd prefer to see User Stories that are finitely satisfiable.

[mmccool]

Note captured in the above: how to deal with high-level vs. low-level requirements (e.g. onboarding generally, vs. onboarding with a particular protocol).

[mmccool]

Thoughts from meeting: Priorities may not be appropriate to include in this document, can be managed by the people actually doing the work, e.g. TFs.