Re: [use cases] Why pre-conditions/post-conditions?

Hi Manu, Hi all,
Thanks, Manu, for coming back to this point.
And thank you as well for the page about pre/post-conditions on batimes.com
that helps me (and I guess many of us) to understand how to use these
categories.
I still would like to precise what is my question and concerns about
"pre/post-conditions" in the new layout (really better than the previous
one) : it is about how to use it, on a practical way, and if this could
drive to some new requirement on how to precisely define each use-case.

I feel uncertain about how to fulfill these items, taking into account what
seem to be the results of our F2F : we decided to produce generic use
cases, "generic" meaning indifferent to jurisdiction's and scheme's
requirements.
Avoiding any confusion between regulatory and technical requirements, and
thinking in terms of practical and technical "pplication functions" we
shall define, it is a persistent reality that the pieces of information or
checks and controls mandatory, and therefore steps,  in completing a
payment transaction, are far different depending on many elements of
context as : the payment instrument chosen, who initiate the payment, the
legal rules and regulations to comply with, the possible additional
scheme's rules, ...

For instance :

   - about exchange rate, for a transaction in $ : in the USA, it is normal
   currency: no question ; in Africa, as far as I know, there are almost no
   requirements, at least "regional" ones ; In the EU, under the current PSD,
   if payee is outside the EU, no european requirement about prior information
   on exchange rates will apply (national rules could or would apply) but if
   payer and payee are in the EU, transaction shall keep evidence that prior
   information has been released about exchange rate and the transaction must
   be operated according to this rate and no other ; under PSD2, same
   requirement as for "payer ad payee i the EU" under PSD, will be mandatory
   even if only the payer OR only the payee is in the EU. This drives to a
   practical set of pre and post conditions: something like : "Exchange rate
   information delivered prior to payment" / "Exchange rate info delivery
   recorded/transaction's rate". This is not required in every situation when
   use-case could be performed, but for quite a bunch of them, at least in
   Europe.
   - about how the choice of payment instrument impacts pre/post-conditions
   : basically, a direct debit requires different initial steps from a four
   corner card scheme payment. And a card scheme payment will happen
   differently in a 3D secure context. Similar rules will drie to different
   pre/post conditions for the same paymet instrument depending on if the
   trascation is intitated by the payer or by the payee. And so on ...

So far WPIG seems to keep reluctant to integrate regulation's requirements
or differences between UC according to the payment instrument.
But what are we talking about when David draws our attention about 2
factors identification in the EU ? And this requirement is only one among
many (the major and not minor ones) requirements that the EU jurisdiction
is now making mandatory, for any payment service, starting from the very
first step of "payment initiation".
In Utrecht, we didn't conclude about regulatory requirements. My feeling is
that they are back now and will pervade through "pre/post conditions". So
we shall decide how should we deal with them, in this part of the new layout

>From a practical perspective, I see three possible ways to fulfill pre/post
items in the lay out for each use case, with respect of regulation's
requirements and payment instrument's compulsory rules :

   - We decide to ignore it ("Utrecht's position") and cross fingers...
   - We try to manage them inside "generic" use cases (and as exposed
   during the F2F, it is likely to drive us to define a "parametrical"
   framework of analysis),
   - we have to divide use cases in more specific ones, integrating
   "environmental" context and this could make difficult to produce "world
   wide" use cases...

Manu's link wisely explains that: "it’s impossible to show in a use case
diagram differences in user authorization; if one role (actor) is
authorized to initiate one set of the bundled functions and another role
(actor) is authorized to initiate a different set." and "A use case
precondition cannot refer to a condition in the physical world that isn't
represented within the system "

In order to summarize my question : how do we deal with both classes of
regulatory/P instrument's conditions in the Pre/post conditions of the new
layout ? Which option of the 3 above do we decide to choose ? Or is it a
fourth option ?
Best

Jean-Yves ROSSI
+336  51 24 77 94
jean-yves.rossi@cantonconsulting.fr
[image: logo_CANTON-Consulting] CANTON <http://goog_1803985827/> -
Consulting <http://cantonconsulting.eu/>
*Découvrez NDP, le meilleur outil de veille
<http://cantonconsulting.eu/edition/abonnement/abonnement-decouverte-formule-d-essai-incluant-4-numeros>
sur
les ruptures du monde du paiement !*

2015-02-23 16:14 GMT+01:00 Manu Sporny <msporny@digitalbazaar.com>:

> Hi all,
>
> Jean-Yves asked a question during the last Use Cases TF telecon that we
> were not able to get to during the call. The gist of his question was this:
>
> What's the purpose of the pre-conditions and post-conditions sections in
> each use case?
>
> To see an example of this type of section, look here:
>
>
> https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#h4_pre-conditions
>
> David Ezell suggested that we change the "Requirements" section to this.
> I think it has helped clarify expectations related to each use case. A
> very brief definition:
>
> A use case's pre-conditions indicate what the system will ensure is true
> before letting the use case start.
>
> A use case's post-conditions indicate what will be true after the use
> case finishes.
>
> There is a good, but lengthy, introduction to
> pre-conditions/post-conditions here:
>
>
> http://www.batimes.com/articles/use-case-preconditions-a-best-kept-secret.html
>
> The reason that pre-conditions and post-conditions are important is
> because they help us understand how all these use cases fit together (or
> if we're missing a use case). They also spell out what we expect the use
> case to do w/o having to prescribe requirements.
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: The Marathonic Dawn of Web Payments
> http://manu.sporny.org/2014/dawn-of-web-payments/
>
>