[use_cases] Notes upon rereading

Hi Manu,

Here are some notes upon rereading the use cases, which I think are starting to look very good:
 https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html

I was not focused on the content of the use cases, but the document structure, intro, etc. May I do some edits and send you pull request?

Ian

====

INTRO/ABSTRACT

- Update abstract to make this more about use cases 
- Give more of the exec summary in the intro.
- Include relation to other docs in intro; that will make it easier
 later to explain arch/reqs.

TERMINOLOGY

* DEL Merchant, Customer, Credential, Payment Agent.
* ADD Purchase
* ADD examples for payment schemes and instruments and processors
* ADD link (with suitable status) to glossary work and say our goal
 is to provide high-level terms here, and more detailed industry
 terms can be found in glossary and will appear in other documents
 from the IG.

PAYMENT PHASES

* Tweak intro to say:

a) The world of payment involves many types of payments:
consumer-to-business, business-to-business, individual-to-government,
individual-to-individual, and so on.
b) The current use cases consumer-to-business transactions
also the group anticipates <a href="#additional">additional work</a> on
other types of transactions.
c) To help readers understand how use cases relate to one another,
and to help ensure that the use cases in this document do not overlap
in scope, we organize the use cases into four "phases" of a 
consumer-to-business transaction.
d) The phases describe consumer/merchant interactions.
There are many interactions in the background (between payment operators, banks, etc.) that are not covered in this document. We will address transaction details (and accompanying requirements, protocols, APIs, and data formats)
in later documents on payments architecture and requirements. 
e) Each phase consists of a number of steps. We organize the use cases according to these steps, although for some transactions or payment schemes, some steps may not be relevant.
f) may be interrupted. In this document we do not examine the details of these
exceptions, but for some use cases, we include notes on some actions that will need to happen (from a payer or payee perspective) when some types of exceptions occur.

DELETE: "These phases can be applied to a variety of different payment scenarios such as person-to-person, person-to-business, business-to-person, government-to-person, and so forth. "

4. A Basic Example of the Payment Phases

- Add the word "fictional" where appropriate
- Add a link after first paragraph to section 6

4.3. 
- Don't mention Web site. Mention PaytoParty and Jill.
QUESTIONS: What about a world where payment agents talk to one another?
 Does the story happen the same way? Do we make clearer what information
 is sent to PayToParty (showing it's not sensitive)?

5.1
- Again a mention of arch/requirements
- Suggest making this its own high-level section or an Appendix since
  I would like to have only four subsections of 5.

At beginning of 5 discuss how the use cases are organized:
* Priority order. 
  QUESTION: What does "high" really mean compared to "medium"? What does that
  mean operationally in terms of the group doing its work?
* "Goals" indicates what <a>group identified goals</a> the use case
  supports.
*  "Motivation" provides additional explanation for the use case, such as
  how it differs from another one, or some piece of information not explicit
  in the use case text.
*  "Exceptions" Are notes about payer or payee considerations that we will need
to address in requirements and architecture.
* "Privacy/Security" Are additional notes for consideration that we will need
to address in requirements and architecture.

* Section 6.

- The title of section 4 is "A Basic Example of the Payment Phases".
  I think the title of section 6 needs to relate to it (since 6 includes
  more examples of what you find in 4). So maybe the title of 6 becomes
  "Additional Examples of the Payment Phases"

* New Section

- "Additional Work". Mention other flows and other examples (e.g., p2p).

* Acks. Either fix to be generic about the CGs, or add real names.
--
Ian Jacobs <ij@w3.org>      http://www.w3.org/People/Jacobs
Tel:                       +1 718 260 9447

Received on Wednesday, 18 March 2015 12:29:10 UTC