| Note |
|---|
The Diagrams on this page are partly outdated. We’ll only use a small part of them for the early MVP versions. They could potentially be relevant again in the futureoutdated drafts. |
Following page will cover USCT (Unconditional Social Cash Transfer) minimum “Happy” flow and BB involvement in it. Minimum requirements from USCT MVP workflow perspective.
...
CR and IFMS registries created using UNCTAD functionality (see Registries )
User for SRIS/BOMS (OpenIMIS) created using MOSIP functionality (see Identity and verification )
Happy flow:
Login to the SRIS - user will be verified (see Identity and verification )
Register citizen to SRIS (OpenIMIS) - when entering citizens personal ID, citizens personal data will be pulled over x-road and personal data fields filled automatically with mocked data in CR Citizen Registry (UNCTAD) (see Registration )
Link benefit program to citizen - list of mocked programs is provided (OpenIMIS) (see Registration )
Add additional benefit related information (payment due date, payment amount, account no …) to the BOMS form (OpenIMIS) (see Registration )
Submit benefit package to the citizen - payment request triggered from OpenIMIS, which is background functionality
Check if the payment due date is reached, trigger the benefit payment to the citizen by MIFOS functionality - this is the backround functionality, the verification of banc account is triggered towards IFMS mocked database (see Payments )
Notification of payment completed sent to the BOMS and Citizen - backround functionality will be mocked
...
Activity | Comment | Goal | Status | Result | ||||||
|---|---|---|---|---|---|---|---|---|---|---|
Describe MVP | Describe the MVP helps everybody to concentrate to very concrete items to pay attentions to | To describe the MVP eg. Happy flow, on what we could concentrate when working with first BB candidates. |
| |||||||
Describe assumptions for MVP | As this is the MVP, there are many assumptions that should be defined | To provide the common understanding of the assumptions that are there for MVP |
| |||||||
Define pre-requisites for MVP | As this is the MVP, there are Pre-requisites, including some mocked data, that should be available to run the MVP flow | To provide the common understanding of the pre-requisites that must be there to run the MVP |
| |||||||
Define Definition of Done DoD | The Agile definition of done is a collection of criteria that must be completed for a MVP to be considered “done.” It is essentially a checklist to create a common understanding of what is required to make a product releasable. | To provide the common understanding/criteria's when MVP is done |
| |||||||
Provide high level vision on BB involvement in USCT MVP flow | High level vision includes the user interactions in the “happy flow”, where each interaction is using one or more BB functionalities. | To understand and have the high level overview of BB involvement to run the USCT MVP flow |
| |||||||
BB integration to the Sandbox | All MVP BB candidates will at first be installed to the sandbox environment. | To learn and document the activities, obstacles and suggestions Outcome : minimum req. for BB providers |
| |||||||
BB integration alignment with BB providers | Meeting with all BB providers to get the common starting point for BB integrations and developments | To have the common plan and understanding of MVP |
| |||||||
Detailing the BB APIs in sandbox to be used for MVP | Document the MVP interaction details (diagrams, development input documentation, …) This will also be input for API testing | To have the sandbox APIs described with the minimum set of inputs and endpoints to run the MVP |
| |||||||
Integrations development and other related activities | All BB providers should be involved and active this time | All involved partners have cleare understanding of Happy Flow and can identify own responcibility area for completing MVP scenario (create specific API endpoints/ create adapter solution for MVP / modify existing API for complient run through) |
| 18.04.2023 1st meeting Apr 18, 2023 - Alignment Meeting # 1 | ||||||
UI requirements | Requirements for UI to run the MVP flow. | To have MVP UI requirements in place as the input for UI developments |
| |||||||
UI development | We are using our own UI, because there are many BB involved and switching between UIs in MVP case is not possible “The sandbox modeling the Use Case Process is more important than the details of the UI” by Wes | To have the common simple UI for each user interaction shown in MVP happy flow |
| |||||||
Testing the APIs | If the MVP BB requirements are in place, the testing plan can be formed | To have testplan and test to validate the meeting of requirements |
|
...