• Work in progress

    • Minimum Viable Product (MVP) eg. Happy Flow

    Owned by Heidi Kuum (Deactivated)
    Last updated: Jun 02, 2023 by Martha Vasquez
    4 min read

    The Diagrams on this page are outdated 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.

    USCT description: https://solutions.dial.community/use_cases/unconditional_social_cash_transf

    MVP eg “Happy flow” will cover only very minimum part of USCT workflow and will use only some fragments from BB functionality, there will be no errors, corner cases and non-compliances.

    In “Happy flow”, Civil servant will only perform few steps in our UI:

    Pre steps before the Happy flow starts:

    Happy flow:

    • Login to the SRIS - user will be verified (see )

    • 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 )

    • Link benefit program to citizen - list of mocked programs is provided (OpenIMIS) (see )

    • Add additional benefit related information (payment due date, payment amount, account no …) to the BOMS form (OpenIMIS) (see )

    • 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 )

    • Notification of payment completed sent to the BOMS and Citizen - backround functionality will be mocked

    Out of the scope: ConsentBB, WorkflowBB, MessagingBB, ScedulerBB.

    Note: There are no adapters used to data and protocol translation (OpenIMIS uses FIHR protocol ) therefore workaround to build the API is done

    High level overview of BB in USCT “Happy flow” Draft

     

    Planning

    Activity

    Comment

    Goal

    Status

    Result

    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.

    DONE

     

    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

    DONE

    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

    DONE

    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

    NOT started

     

    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

    review

    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

    In progress

    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

    in progress

    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

    In progress

     

    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)

    in progress

    18.04.2023 1st meeting

    UI requirements

    Requirements for UI to run the MVP flow.

    To have MVP UI requirements in place as the input for UI developments

    NOT started

     

    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

    NOT started

     

    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

    NOT started

     

    Assumptions

    NB! The requirements below rely on the following assumptions:

    • Only MVP of USCT workflow is used (eg. happy flow)

    • Our UI will be used

    • Each BB will provide only some parts of the functionality

    • The BB used in MVP flow have developed their side of APIs that are compliant with GovStack API specifications

    • BB has API management gateway where the main configuration for the BB is done including communication to other BB.

    Prerequired registries

    All registries, presented in Happy Flow diagram should be deployed and preconfigured (data input) for running the Happy Flow scenario.

    Before connecting all BB and running the flow, pre-required registries must be in place and users for Social system must be created to access the system:

    • Users

      • User unique ID

      • Name

      • Last name

      • Role

      • Region (address)

      • District (address)

    • CR- Citizen registry

      • UID - system ID generated by MOSIP

      • ID (personal ID)

      • First name

      • Last name

      • Birth Date

      • Gender

      • Region

      • District

      • Municipality

      • Village

    • BOMS

      • benefit programs list (to choose)

      • eligibility criteria (positive response)

    • IFMS - Integrated Finance Management Information System

      • Personal ID (Citizen)

      • Bank Account