Web Payments IG Use Cases Task Force -- 19 Mar 2015

<manu> Ian: I want to have a greater discussion on whether this document should have requirements. My emerging understanding, and the one I heard, is that use cases don't need to include any requirements. It could just say "here's the scope of the work".

<manu> Ian: When we get to the next level down - concrete requirements, we can derive them from the use cases. I think it's tempting to include, but I think it's unnecessary and we'll be duplicating information between architecture and this document.

DavidE: I think I agree with Ian at this point...I was looking at Chaal's material...I think probably we need to pursue Ian's path
... requirements would reference the use cases that led to them.

Manu: I disagree slightly.
... we've seen other WGs put their requirements in their use cases doc...and it's worked out for them.
... the biggest concern I have is that developers who look at use cases may be confused because we don't say anything about requirements.
... it may feel toothless without requirements.
... we could "list" requirements in use cases doc and then link to them in a separate reqs document.
... we should link "goals" to exec summary
... we could do same with requirements.
... the down side is that we have to keep the docs in sync

<manu> Ian: I feel like the requirements flow from the use cases and not vice-versa - it is quite possible that in real life we find that we reach a steady state with the use cases (at least in the first iteration)

<manu> Ian: If we're satisfied with them at some point, we don't end up touching that document at all - or if it's combined, we don't focus on it too much - then all attention will shift to requirements document.

<manu> Ian: Since the purpose is narrow in scope - then the rest of our work will turn the implicit requirements into well document requirements that point back to use cases that generate them.

<manu> Ian: Yes, we can put everything in one document. Aware of costs/benefits of everything in one document. I think the use cases document is going to become stable at some point, and we may not touch it after that.

<manu> Ian: If we have references back to use cases, they should all have their own IDs.

<manu> Ian: It's not clear to me, functionally, that people would look at the subscription use case and then say "Ok, what requirements would be derived from this."

<manu> Ian: In order to get to FPWD, we can try it without requirements - given work that needs to be done and timeframe, let's not focus on requirements yet.

<manu> Ian: Without saying it'll be in the same document or another. I don't think we'll be fleshing out a bunch of requirements, don't think that'll be in FPWD.

<Zakim> manu, you wanted to mention he doesn't feel strongly about this.

<CyrilV> +1 to a "list only" of requirements in "use case doc" and details in another document

Manu: I agree we should not do requirements before FPWD
... meanwhile, I don't feel that strongly about this...we can put the doc out...and see how people respond.
... part of me is trying to figure out a way to head off comments

[IJ suggests a note up front that we will use these to create technical requirements and those are forthcoming]

<manu> Ian: We should set the expectation that there will be requirements. In the intro, etc, without making a commitment on where they'll be.

DavidE: Yes, I think the requirements come next
... I also agree too much to add before FPWD

+1 to not committing to who we will implement them when we have them

Manu: We can add note to the status section we'll do reqs next
... ok with that?

<CyrilV> +1

<manu> https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#discovery-of-accepted-schemes

Manu: In 6.2.2.1 high priority...there's something called MANUal selection ;)
... it has bulleted items in manual
... each one is a different way of looking at the manual selection use case
... we're trying to gather them into a single block.
... is it ok for use to intersperse single line and bullet items?

<manu> Ian: If I'm correct, this is the approach I had labeled groups - this is more or less.

<manu> Ian: Visually, at first I thought there was a problem with the use case... I wonder if the bulleted list could be a sub-bulleted list of a single line. For example, short higher-level statement, and then subbullets.

<manu> Ian: For example: "Manual selection has multiple ways of happening, for example:" - these are thematically related... when I hit just five bullets and have no framing, I don't know why I have five and how they relate. I'd like to keep it extremely short - multiple illustrations of something.

<manu> Ian: Rough criteria would be - if they would be illustrating different things, they should be on their own... or if they're showing N different instruments, and we found it annoying to break all of them apart, let's characterize them differently.

<manu> Manu: Yes, I think that would work.

Manu: I think that would work...

<Zakim> ShaneM, you wanted to ask about one of the use cases

Shane: I think it makes sense to use the bullet list and can see why there is an intro sentence to explain why there is a bulleted list.
... but they should all have the same motivation..other wise it becomes mixed up.
... so the same goals and motivation => group them together.
... my second comment has to do with specific wording in 6.2.2.1

"Claire has multiple credit cards from the same bank as well as one debit card. " =>

"Claire has multiple credit cards and a debit card from the same bank. She chooses her debit card"

Manu: Yes, the bullets need review and cleanup

<Zakim> Ian, you wanted to discuss minor suggestion

Manu: Summary - if we have a bulleted list, let's have intro sentence to justify the list. And one way to determine whether to have a bullet list is to look at motivation/goals

<manu> Ian: This is a very minor comment - finding deeply nested numbering system annoying - I get freaked out at hierarchies... can we remove numbers from high priority.

<ShaneM> +1

<manu> Ian: What if we don't need the high priority label at all.

<Zakim> manu, you wanted to mention hierarchy and priority.

<ShaneM> I sort of like reinforcing that things are high priority

Manu: I agree that the deep hierarchy is annoying; we can remove the numbering

IJ: My proposal is to say up front "Unless we say otherwise, it's a high priority"

Manu: We have 140 use cases that we've not yet reviewed...I feel like we are going to end up where we are now

<manu> Ian: I want us to prioritize them, but from an editorial perspective - don't say high priority - just say everything is high priority until we say otherwise.

Manu: Ah, ok. Makes sense to me.

Shane: I have a weak disagreement.
... the factor out approach presumes people are reading the whole doc (which people may not read)
... I'm happy to try this out but expect there will be confusion and I get to say "I told you so"

+1 :)

Manu: I agree with Shane that's the reason we have these labels

<ShaneM> [H] Ubiquitous Schemes

<ShaneM> [H] Emerging Schemes

<manu> Ian: I think any time you're going to have a formal system, you need to have definitions on what "High/medium/low" means.

<manu> Ian: Maybe we have lower-priority for the group - throw everything in one category - hold funds and trial-ware, for example. For FPWD - we're still working on priority - then definition becomes "this is where group defines priority"

<Zakim> manu, you wanted to argue against "low priority category"

<manu> Ian: If it was a high priority to make them have the ability to be quoted independently - then I'd agree with your assessment.

Manu: We had, Ian, what you suggested 3 or 4 weeks ago...we had high/med/low.....

<manu> Ian: As an example - look at section 6.1.1 - without a label - start w/ high priority ones... then group all medium/low use cases - don't think there's a good difference between medium/low - still working out priority.

<manu> Ian: Some sections won't have a label, others say we're still working on it. Now that there are only two labels - these are "high priority", "we're working on these".

<Zakim> manu, you wanted to say "must have", "nice to have"

Manu: I think the categories we have today are "we agreed" and "we have not yet agreed"
... but those categories are going to change to "must have" v. "nice to have"
... I hear you saying we have no label for the ones we've agreed to, and we have a single label for where we are still working.

IJ: +1 to telling people how we are thinking about how the doc will evolve. +1 to having "decided/not decided" today

with an explanation of future plan

(which is "must" v. "nice to have")

Manu: Any disagreement with that approach for FPWD?

(None expressed)

+1 for that approach

<dezell> +1

<Jackson> +1

Manu: Any other thoughts on how use cases are structured?
... if not I will apply today's discussion to the text
... and do integration of FTF-approved use cases

[Thanks Manu!]

Payment Phases Applied to the Real World

https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#the-payment-phases-applied-to-the-real-world

<manu> We want to do something like this: https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#a-basic-example-of-the-payment-phases

Manu: We should have a small number of them that tell stories to help people understand the flows that we have in mind

<manu> for section 7: https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#the-payment-phases-applied-to-the-real-world

Manu: Do people like this approach of having more involved stories at the end of the doc to ground the steps into real-world examples?

DavidJ: I have a question...How much more detail are you looking for for each use case?

Manu: Section 4 gives you the story of a complete transaction.
... those details line up as a full example.
... we want to take that idea and do the same in section 7 with recounting complete scenarios (in the terms of our flow)

<dezell> david: section 7 is a set of proofs that we have defined things that are useful.

<manu> Ian: Why do we have the document in this structure? It's useful to talk about hoof shapes of different types of mammals... The use cases talk about all the different types of hooves. Section 7 talks about the shape of the animal... you can't just talk about the hooves, you have to also talk about the animal.

<manu> http://en.wikipedia.org/wiki/Farrier

Manu: Any volunteers to contribute stories to section 7?
... it takes about 2 hours to do one in my experience

DavidE: I will try Apple Pay but can't promise

David: If there is a sub-interaction you want to do ... if I can help edit and send by email.that's fine.

Manu: +yes
... e.g., copy section 4 and write your own, then send email
... we'll drop in the doc and people can review

IJ: Manu, who has volunteered already to write stories?

<manu> Ian: Who have volunteered so far?

Manu: Kepeng said he would write one for Alipay

<manu> Ian: Kepeng volunteered, I think Laurent volunteered as well.

<manu> Ian: One other comment - as I look at the edited stories in 7, my sense is that some of them may not fit with the payment phase that we have described - government entitlements disbursement.

<manu> Ian: We might want to have a new appendix for other payment flows that we're going to work on - partly meant to answer questions that are likely to arise - "What about /my/ use case?"

<manu> Ian: We are going to get to person-to-person, government-to-individual, etc. Having some of those in a new section on future payment flows might make more sense.

<manu> Ian: We're only trying to do so much in the first pass - 7.6-7.8 might fit elsewhere.

Manu: Agreed in general...I think 7.6, 7.7, and 7.8 fit into our current flow.
... but we can't also do everything in the FPWD
... i think the place to put this is in the status section
... e.g., status section
... maybe we need a loud statement in status on future work:

* Use cases

* ISO alignment

* Real-World payment stories

<manu> Ian: I think it should be in an appendix - "Future Plans"

IJ: How about an appendix and a link from status to keep status short

Manu: proposal is a big warning on "future work" that we have more plans
... Work for people?

[No disagreement]

Manu: Thanks all!
... I think we are getting into good shape for FPWD

Next Meeting

<CyrilV> thanks

26 March at 10am ET for 1 hour

<manu> s/Next Meeting:/Next Meeting/

- DRAFT -

Web Payments IG Use Cases Task Force
19 Mar 2015

Attendees

Contents

Look at current use cases doc

Revised Use Cases Documents

Payment Phases Applied to the Real World

Next Meeting

Summary of Action Items

Scribe.perl diagnostic output

- DRAFT -

Web Payments IG Use Cases Task Force 19 Mar 2015

Attendees

Contents

Look at current use cases doc

Revised Use Cases Documents

Payment Phases Applied to the Real World

Next Meeting

Summary of Action Items

Scribe.perl diagnostic output

Web Payments IG Use Cases Task Force
19 Mar 2015