Team 3 - Homework 5 - Categorization review

[bourdelin]

Hypothesis :

• The list follows temporal TRANSPORT CUSTOMER travel
• The travel can be composed with trips; each trip with one or many leg.
• "aftersale" = can happen before/ during / after

List of categories we agree today
A. Inspire & Plan​
B. Shop & Price​
C. Order & Book (+ begin of reservation)​
D. Pay (CHARGING MOMENT (complete or not)​
E. Ticketing & Fulfilment (FARE CONTRACT creation + Traveld oc distribution + end of reservation)​
F. Pre‑trip (service and aftersales)​
G. Validation – inspection / In‑trip (services and aftersales)​
I. Post‑trip (+ end of payment (CHARGING MOMENT)), ​
J. After trip (aftersales + claim + receipt)​
K. Settlement (repartition between actors) & Reporting

Homework :
Take one point and start writing a "business use case" covering all the cases pointed out by the use cases/user-action/endpoint given in inputs/. Organize each as refer to all points listed in inputs/ (sub-use case / alternatives, ...)

[OlivierBigex]

Looking at all inputs, that is a huge work ! Especially since the sources on wiki are numerous and with an heterogeneous granularity.
However, @TOP-PHE has provided us a neutral basis which gathers all inputs as business requirements: the Excel files on Sharepoint (BRM_EUDIT_V2.3.xlsx, "BRM" sheet).

To write these generic business use cases by category. I suggest the following method:

1. Everybody reviews the Excel file and corrects it for minor corrections (row R for comments and row S to note that you have reviewed the requirement). Don't take into account the Priority at this stage. Deadline: next planary meeting.
2. If a requirement need to be discussed here (or in planary meeting), set "Yes" in row T. Should be exceptional.
3. When reviewed and discussed, @bourdelin sets row Q as "Validated".
4. Write manually one (or max 2-3) macro BUCs by category only based on this Excel file.

And the work will be even more efficient if we prioritize or even select requirements before step 3 --> discuss and validate priority (row P), to make BUCs a little simpler to write. But not mandatory, if you dont want it.

Hypothesis: the forge will take into account macro BUCs + related requirements on that Excel file.

What do you think @bourdelin ?

[oangeras]

link to excel file is broken

[OlivierBigex]

link changed to directory to stabilize it.

[oangeras]

Thanks for correcting the link. the file aggregates the use cases from the mode-specific APIs. It misses the use cases that involve several modes and several operators/actors

[OlivierBigex]

About post-payment (open payment EMV, post-payment Fairtiq-like and post-payment with NFC card).
Since:

• post-payment process are mainly internal to one single Product Owner.
• the only distributed API could be optional subscription and consultation of trips and Invoices.
• No Fairtiq representive in EUDIT.
• but above all, normalisation processes about interoperabilty in open payment EMV are handled by another project (at least French mirror group GT12) who works on ISO 24851.
  ==> In order to focus on what is doable, I wonder if EUDIT is legitimate to include these use cases for now.

[edwinvandenbelt]

Ok. I'd say, we focus on the process to let the traveller purchase and execute the trip (including the after-sales), and -as said before- the actual payment should be outside scope. None of the APIs (maybe BoB a bit) covers this.

[bobvinke]

There is a great difference between the Fairtiq way of working and the EMV one. Please do not mix these up

Yes they all determine the price of the trip after words, however Fairtiq seems more in line with EUDIT, than EMV based processes.

fairtiq finds out the itinerary, during the trip. After the the price of a specific itinerary can be collected using the EUDIT API, just the same way as if you would ask for the offer (package) based on a result from a planner. This might be the same for other parts of the EUDIT processes.

Even for EMV, we might be able to find a connection, reusing parts of EUDIT. however my sugestion is to maximise the scope of EUDIT to the processes supported by the standards that currently participate. In a later phase we can expand if someone requests to join.

[bourdelin]

For the Open-payment use case, I will add in the business use case A that the adherence between BUC A and open payment ends when the customer chooses in the catalogue or with trip planner to use the open-payment to travel. After, it is not in EUDIT scope (API inside ticketing backoffice, payment system, banks). No more interaction with retailer. No Customer PURCHASE PACKAGE definition, nothing in TRAVEL BASKET.

[einarbjorkevoll]

For this meeting, should we go throug the list of use cases here, and define which one to create use cases for?
https://maasallianceeu.sharepoint.com/:x:/r/sites/europeandigitalticketinginterfaces/Shared%20Documents/General/Working%20documents/EUDIT%20use%20cases.xlsx?d=wecf7aa95af5a47f5a579405dcabbc0fa&csf=1&web=1&e=4Ta2Rs

For the other Excel sheet, this is more use cases for the systems below, not on how the API should be, or am I wrong?
PS: I was not participant in last meeting, so may have missed some details

[bobvinke]

Thank you Einar, usefull to have a list of all use cases from the different standards with the potential macro use case that we can create to cover the related source use cases.

I do not know who created this list and if it is the only one.

• it is up to the representatives of the different standards to cover in EUDIT, to make sure all relevant source use cases from their standard is represented in the list.
• when detailing the macro use case, all related source use cases should be taken in to acount. For this reason it could be practical to add the link to the source use case in list of use cases.
• it is then up to the representatives of the different modes to check if their use case is well covered in the macro use case.

if this use case list is correct, we should need to create at least 34 macro use cases.

Can we share the work, or does Sonia, need to create all concept macro use cases by her self?

[bobvinke]

@einarbjorkevoll; you are refering to system use cases, where Sonia is creating higher level business use cases. Further more, @edwinvandenbelt started a simular discussion in #41

[bobvinke]

The list of 34 macro use cases combines several usecases of one existing standard. Should we not try to combine system use cases at the lowest level?

[bourdelin]

Sure, we have a little issue with vocabulary when speaking about "use case" and their level/content... I would use "Business use case" terminology to speak about the highest level of use case we need in EUDIT project. After, yes, each representative has to check that his contribution to EUDIT scope is taken into account (I do a check when writing the use case but I am not sure to understand everything underlying every inputs).
So, yes, the method is 1 - write Business Use Case defining the flows needed between customer-retailer and distributor. / 2 - the needed flows will be "translated" in APIs (by the next team :))
Thanks to all, also, to add in the Word document comments the missing links between the BUC-A and each contribution.

[bobvinke]

Thank you Sonia. I understand we need the Business cases to express how EUDIT fits in the complete sales proces. However in the end there seems also a need to create system use cases describing in detail how the API interaction is used in specific situations.

For now I understaand that we can use the low level use cases from the different standards in scope, to check if all relevant situations are covered in the business use cases. Each representative of a standard can check for it self if that is the case.

[bourdelin]

Comments taken into account