Now the serious work starts. Aurele from the Virtual Assembly invites us to describe the different use cases that we share. But… what is a use case? Well in our food services activities, we all do similar things. Like for example, whatever the platform and service we propose to the producers, we need to be able to reference a producer in our systems. So this for example, is a use case : “referencing a producer”.
How do we describe a use case?
To describe a case, one must tell:
The triggering event. “The producer has products he wants to sell and wants to be identified by one or various distributor hubs”
The objective. “For the producer, the objective is to be identified and known by one or various distributor hubs”
The actors. “Producers + Software companies (hosting the producer profile or hub profile) + Distributor Hubs”
The flows. “The producer’s info (profile, localization, product categories associated, etc.) can be consulted by distributor hubs and final buyers + the information can be transmitted to third party websites”
The rules / constraints (including confidentiality and access to data) : “The producer chooses to which platforms / distributor hubs he gives access to his information. He can put all his data as open data that anyone can access. Or he can choose to give access to his data to a specific platform/hub. Access right: the producer can authorize a third party to create his profile for him.”
The pre-requisites. “the producer needs an email address and an internet access to be able to reference his profile”
It’s interesting, when we went through the use cases, to discover some specificities of our respective platforms, how we handle things differently. A nice co-learning experience :-)
What are our use cases?
We managed to list the following use cases. Some of them are a bit crazy, but still, no judgment in a brainstorming :-) The list is not exhaustive.
Referencing a producer : we all need a producer profile to be created in our system
Creating a products catalog : we all need to allow the producers to create a list of the products they propose
Modifying a products catalog : either the producer or the distributor hub need to be able to modify the product catalog
Referencing a distributor hub : we need to create a profile for a distributor hub in our system before a shopfront can be created
Sell products : we need the products to be sold either by the producer himself, either by a distributor hub
Modify the list of products available for sale : a hub or producer need to be able to change the list of products that are for sale
Set up a sales session : a distributor hub needs to be able to set up a sales period during which the sales are open, corresponding to a specific delivery date.
Share stock levels : distributor hubs need to have an accurate real time information of the available stock they can sell.
Receiving an order : producers need to access the aggregated information about what has been ordered through a specific distributor hub and when and where it has to be delivered
Transport/deliver the products: producers and hubs need to be able to organize the transportation of the products and respect all the legal / administrative constraints attached.
Trace a product : we need to be able to trace some legal information attached to a product (like the expiration date)
Localize a product : we need to be able to know at each moment where is the product sold.
Invoice products : hubs need clients to receive an invoice for the products they have bought.
Contact a producer : buyers and hubs needs to be able to contact a producer
Share statistical data : all platforms share an interest to promote the local food sector as a whole and institutions/associations need access to general statistical data in order to share a global picture of the sector
Let’s narrow this down to what is needed for our first prototype.
In order to learn and experiment on a simple case the interoperability of our platforms, we need a prototype. An MVP (Minimum Viable Product) that we can then iterate on. To avoid all the hard questions of data governance and sensitive contents, we decided to start on a very simple case : a directory. An external platform would be able to display cross-platforms information, like producers and distribution hubs, and would allow requests in all those platforms. For example, on this platform, you would be able to search for a product, and you would see which distribution hubs you can buy this product from on a map. Easy, no? Thibault who started Mooveat is willing to host that first prototype.
So in order to move forward on that prototype, we decided to stick to the first 4 use cases, which we believe are the ones we need to implement the prototype.
Now that we have our main use cases ready, and we have agreed on a common description, next step will be to describe the semantic model of business concepts. Out of those use cases, we will list the different concepts (actors, things, actions, places, times, etc.) and then draw a model and link those different concept. We’ll share the result in a following post when it’s done, be patient :-)