5 Functional Requirements

The Functional Requirements section lists the technical capabilities that this building block must/could have. These requirements should be sufficient to deliver all functionalities that are listed in the Key Digital Functionalities section. These Functional Requirements do not define specific APIs - they provide specifications and information about any functionalities that must be implemented within the Building Block.
The functionalities described in this chapter apply to any government registration use case. Therefore, they also apply to the following use cases:
1.Postpartum and Infant care- https://solutions.dial.community/use_cases/postpartum_and_infant_care​
2.Unconditional social cash transfer
https://solutions.dial.community/use_cases/unconditional_social_cash_transf​
5.1 No-Code Development Platform
The no-code development platform is composed of:
Rules engine
User interface and flow builder
Controls configurator
It is used by authorized personnel, called “analysts”, entrusted by the entities in charge of the registrations to develop the corresponding online services.
Pre-requirements:
The analyst is authenticated and authorized to use the no-code development platform.
The analyst has a computer/smartphone with an internet connection.
Post-requirements:
When the no-code development is finished, the analyst publishes the e-service, which becomes available to users (applicants and operators);
Applicants can submit applications;
Operators can process the applications.
5.1.1 Rules Engine Functional Requirements
The Rules Engine is a module where an analyst defines:
1.Who are the subjects of the registration
2.For each subject, the result of the registration, e.g. a credential
3.For each subject, what are the requirements of the registration:
4.​
1.Claims required
2.Credentials required
3.Payments/fees required
The rules can be:
Entered in the rule engine by an analyst, on the basis of the regulations
Provided by external rules providers (e.g. rules DBs at ministries level)\
REQ-#
Requirement
Type & UC
RE-1
Creation of Services
An analyst (user) must be able to create, in the rule engine, one or more services, each service encompassing one or more registrations.


A “Service” is a name given to a registration, or to a combination of registrations which can be undertaken simultaneously.
To create a service, an analyst will:
Give a name to the service
Link one or more registrations to the service
Must have
RE-2
Publish service to external instance


Each service can be published in the same or in a separate instance, together with the rule engine. Instance must be configured and interoperable with Registration BB service definitions.
May have
RE-3
Creation of one or more “Registrations”
An analyst can create one or more registrations. For each registration, the analyst defines in clear language, in the rules engine:
The name of the registration
The entity in charge of the registration
Must have
RE-4
Definition of the subjects of a registration
For each registration, an analyst must be able to report/input in the rule engine, in clear language, rules defining who/what are the subjects of the registration.
To this end, the analyst can select one or various of the following options:
1.The registration is mandatory to all
2.The registration is mandatory to specific subjects
3.The registration is optional to all
4.The registration is optional to specific subjects
1 and 2 can’t be selected simultaneously; 3 and 4 can’t be selected simultaneously.
Specific subjects (in 2 and 4) can be defined through determinants or a combination of determinants. Determinants can be combined by “AND” and “OR” operators. Combinations can be grouped into “groups of determinants”. Group of determinants can be combined through “AND” and “OR” operators.
Examples:
1.Registration is mandatory for attribute “resident” (all residents must register)
2.Registration is mandatory for attribute “resident” AND attribute “foreigner” (all residents who are foreigners must register)
3.Registration is mandatory for {attribute “resident”} AND {attribute “foreigner” OR attribute “have children”} (all foreign resident must register; national residents who have children must register)




Must have


RE-5
Definition of the results of a registration
An analyst must be able to report/input in the rule engine, in clear language, rules defining what are the results of a registration.
The result of a registration has a name (example: registration number, registration certificate, permit, license, etc.). To this name, the analyst must be able to associate a template/document (see RE-11).
In some cases, some subjects of the registration will receive a different result. The analyst can define through determinants (or combination of determinants) the different categories of subjects and can link each category of subjects to a specific result.
Examples:
1.Future truck drivers that apply to a driving license and pass the exam will receive a driving license for “large vehicles”, while car drivers will receive a driving license for “light vehicles” (attributes: “truck driver” or “car driver”)
2.Enterprises with assets below US$5,000 will receive a “Cottage Industry Certificate”; enterprises with assets above US$5,000 will receive a “Business License”, when applying for an activity license (attributes: “assets below US$5,000” and “assets above US$5,000”)
Must have


RE-6
Requirements of a registration - Documents/Credentials
An analyst must be able to report/input in the rule engine, in clear language, rules defining what are the documents (= credentials) that must be provided.
A document/credential can be defined by a name
One registration can have several required documents/credentials
A document/credential can be physical or digital
For each required document, the analyst can select one of the following options: has to be brought to the front desk;
​
has to be uploaded
has to be signed in front of an Operator.
The required documents can differ according to the categories of subjects. The analyst can define, through determinants (or combination of determinants) the different categories of subjects and link them to specific required documents.
Examples:
1.Married applicants must provide a copy of their wedding certificate (attribute: “married”)
2.Foreigners must provide a copy of their residence permit (attribute: “foreigner”)
3.Applicants that can’t provide a copy of their birth certificate must provide a certified copy of their ID (attribute: “can’t provide a copy of the birth certificate”)
Must have
RE-7
Requirements of a registration - Fees
An analyst must be able to report/input in the rule engine, in clear language, rules defining what are the fees of a registration.
The fees of a registration has a name (example: State fee of MCTS programm, license registration fee etc.). To this name, the analyst must be able to associate an amount and a currency.
Fee can be calculated or fixed;
One registration may have 0..n fees;
All fees must have an assigned currency. The system may allow multiple currencies;
A fee can have a description.
When the fee is calculated, a formula builder will allow the analyst to build the formula, using values from any field in the service and numeric values, combined with the usual operators (+, -, *, /).
In some cases, some subjects of the registration will receive a different fee. The analyst can define through determinants (or combination of determinants) the different categories of subjects and can link each category of subjects to a specific fee.
Examples:
1.Mothers with one child that apply to a registration to MCTS program will receive a identity card for 10 EUR, while mothers with two children or more will receive the identity card for 15 EUR (attributes: “one child” or “more than one child”)
2.Farmers with farming land area > 10 000 sqm that apply to registration of farm land will receive registration certificate for 10 EUR, while farmers with land area <= 10 000 sqm will receive registration result/credential certificate for 5 EUR.
Must have
RE-8
Requirements of a registration - Data/Claims
An analyst must be able to report/input in the rule engine, in clear language, rules defining what is the data (= claims) that must be provided.
A piece of data is defined by:
A name (e.g. date of birth, nationality, first name, last name, etc.)
A type (text, number, date)
mandatory/ optional (See Control configurator element for more options)
As for the other requirements, some data can be required only for a specific category of subjects. The analyst can define, through determinants (or combination of determinants) the different categories of subjects and link them to specific required documents.
Examples:
1.Married applicants must provide the first name, last name and date of birth for their spouse (attribute: “married”)
2.Owners of farm land should provide the number and date of registration of their property; applicants who rent farm land must provide the name and ID number of the owner (attribute: “own land”, “rent land”)
Must have
RE-9
Possibility to combine various registrations in one service
In many cases the process for the user/applicant contains multiple pre-and post registration steps in order to achieve the final goal (e.g. apply for a healthcare program).
For example, in order to register a mother and a newborn child to the Mother and Child support program, both of the subjects must be previously registered in the Civil/Population registry. Civil registry registration service could be a separate service, but it is much user friendlier and less time consuming for the applicant to merge the two registrations into one service that can be filled at the same time. This service type is called Single Window- or integrated registrations service.
To facilitate the combination of various registrations in one service:
Registration requirements (documents/credentials, results, fees) must be reusable inside the service. One registration may re-use another registration result credentials as input requirements.
Overlapping requirements and/or results must be automatically eliminated.
Fees of all registrations must be merged into one sum, so that the applicant could see and pay total fees. Fee information is stored and segregated per registration.
In one registration the document/credential may be issued as a result and in another registration the same document/credential may be required as an uploadable requirement. The system must eliminate the overlapping results and/or requirements if the requirements overlap inside the service.
Examples:
One service has two registrations and both of them require a passport to be uploaded. When an applicant chooses to apply for both registrations then the system must ask for the passport upload only once.
One service has two registrations. First registration’s result (credential) is the second registration’s requirement. The system must not ask this requirement from the applicant as the result will be generated during the process. However, if the user chooses to register for only the second registration then the requirement must be asked.
Must have


​
​
​
RE-10
Creation and functioning of determinants
The analyst can define through determinants (or combination of determinants) the different categories of subjects and can link each category of subjects to a specific element of a service. An element of a service can be a field, block, button, message, processing role, result, requirement etc.
Simplest case being, is this claim data field on the screen relevant for all subjects or only for a specific category of subjects? If all then no determinant is needed as all users will see and use it. If a specific (e.g. “applicant is married”) category and this category must fill in additional information (e.g. “Spouse name”), then a determinant must be added to control the field visibility for this category of subjects. If the user is married, then the determinant is true and the “Spouse name” field is visible; if the determinant evaluates to false, then the spouse name field is not visible for the subject.
Analyst must be able to:
create and manage determinants (CRUD);
search the existing determinant;
reuse determinant inside the same service;
use formulas - calculate math functions on the form with user input value and use the calculated value in the determinant.
E.g. math functions (SUM, MIN, MAX, AVG, COUNT, MEDIAN, CEILING, FLOOR, ROUND, CONCAT, CONCAT_WS, LEN, REPLACE, UPPER_CASE, LOWER_CASE).
Apply determinants to:
Any element of a service (registration, claims/data fields, screens, roles, templates etc.)
Any element of a registration (results/credentials, requirements/documents)
Determinants can be combined by “AND” and “OR” operators. Combinations can be grouped into “groups of determinants”. Group of determinants can be combined through “AND” and “OR” operators.
Must have
RE-11
Definition of a template associated to the result of a registration
An analyst must be able to create an electronic template (a screen with images, text, fields, QR code) and to link it to the result of a registration.
A template can be:
Filled with values coming from fields in the service or from external databases;
Printed as a pdf file.
Generated and uploaded to the system as a PDF file.
On each template, an analyst can create data fields that must be filled by the system and place them on the screen of the template. Fields will have the following characteristics:
A name (e.g. date of birth, nationality, first name, last name, select option, submit application, etc.)
A type (text, number, date, selector, catalogue, button etc.)
Source of information/capture data from. Function to capture data from application screens upon creation of PDF.
In addition to fields, the analyst can create information texts and add images, QR codes on the template screen.
QR code must be generated with the ISO/IEC 18004:2015 standard.
Determinants and groups of determinants created in the rule engine can be assigned to each field on a template. A field will be displayed/printed only if the determinants assigned to it are true.
Fields can be grouped into containers (blocks, tables etc). A container is defined by a name.
Fields can be moved to and on the screen by “drag-and-drop, inside/outside of and between containers.
Must have
6.1.2 User Interface and Flow Builder Functional Requirements
The purpose of the Screen and flow builder is to define and display the screens, and the fields on each screen, in the application file and processing parts, and to pre-fill or capture the data entered by the users of these screens in:
The application file, where applicants provide claims (= fill a form), credentials (=upload files) and fees (= pay online or upload a payment receipt) and send his/her request to one or more entities in charge of the registration
The processing part, where one or more human or automated (“robot” or “BOT”) operators can review the information (i.e. the data and documents) provided by the applicant, approve or reject an application, send claims to a registry and issue a credential
REQ-#
Requirement
Type & UC
SF-1
Application file - Creation of screens and of their sequence


An analyst must be able to create one or more screens that will allow to show information to the applicant and to display fields that the applicant will have to fill to provide the requirements of the registration.

The analyst can define the sequence/order in which the screens will be displayed to the applicant.


To this end, the analyst will be able to activate or inactivate, through a toggle, the following screens:
Guide screen: this is a screen where the analyst can create text for the information of the applicants (guidelines) or ask questions (through fields) to determine what category of subjects the applicant belongs to (i.e. if the applicant is subject to the registration and what data, documents and fees are required).
Applicant form screen: this is where the applicant will provide the required data.
Documents upload screen: where the applicant will upload scanned copies of the required documents/credentials.
Payment screen: where the applicant will see a list of fees that must be paid and can be redirected to an external online payment service.
Send screen: where the applicant can be reminded of any information missing in his/her application (if some fields have not been filled or documents not uploaded) and will be requested to confirm his/her will to apply for registration.
The above screens, when activated, will be displayed, in the predefined order (guide, applicant form, document upload, payment, send).


The flow of screens can be visualized by the analyst.
Must have
SF-2
Application file - Creation of fields on each screen


On each screen, an analyst can create data fields/claims that must be filled by the applicant and place them on the screen. Fields will have the following characteristics:
A name (e.g. date of birth, nationality, first name, last name, select option, submit application, etc.)
A type (text, number, date, selector, catalogue, button, etc.)
The name of the registration(s) the field is associated with (i.e. the corresponding data is a requirement for this registration)
Mandatory or optional
Determinants and groups of determinants created in the rule engine can be assigned to each field. A field will be displayed only if the determinants assigned to it are true.


Every time a field is created it is recorded in the “data” part of the rules engine.


Fields can be grouped into containers (blocks). A container is defined by a name.


Fields can be moved to and on the screen by “drag-and-drop, inside/outside of and between containers.


In addition to fields, the analyst can create information texts, images that, contrary to fields, do not expect any input from the applicant.
Must have
SF-3
Processing part - Creation of screens/roles


The processing part relies on the flow builder because roles are part of the process flow.


An analyst can create one or more screens allowing human operators to process the application files, i.e. to review the information sent by the applicant, to add data or documents to the application file (e.g. a number, a date, a credential, etc.), to approve an application, to reject it or to send it back to the applicant when more information is required.

We call “processing role” (or simply “role”) each successive processing an application file will go through until final approval is given and the registration is completed.

Usually, different roles are ensured by different government entities. It happens that successive roles are ensured by different units in the same entity.

Example flow:
1.Unit 1 reviews the application file, checks that all data and documents provided seem true and correct
2.Unit 2 approves the application
3.Unit 3 issues and signs the credential and sends it to the applicant
For each role, two screens are necessary:
A first screen (list screen) where the operator will be able to:
​
see a list of application files, filtered by status (pending, validated, rejected, sent back to the applicant)
select a file for processing (if pending) or for consultation
A second screen (processing screen) where the operator will be able to:
​
review the selected application file (data and documents provided by the applicant, fees paid or not)
add data or documents to the file
Make decision- approve the file, reject it or send it back to the applicant


Therefore, an analyst must be able to create one or more roles, each role coming automatically with one list UI and one processing screen UI. Each role will be defined with the following elements:


Name of the role
Name of the registration the role is associated with
Entity in charge of the role
Position in the process flow.
Determinants and groups of determinants created in the rule engine can be assigned to each role. A role will be displayed/activated only if the determinants assigned to it are true. If Role determinants evaluates to false, then the application file passes the processing role without stopping.
Must have
SF-4
Processing part - Ordering of screens/roles in Flow Builder


An analyst will be able to define, for each role, a list of possible statuses, by selecting which of the following statuses are possible for the role:
Pending (the file is waiting to be processed by the role)
Approved (the file successfully passed the role)
Rejected (the application is denied, the file is closed)
Send back to the applicant for correction (the operator sends the file back to the applicant and requests that some information be corrected or added)
For each activated status, the analyst will be able to indicate where the application file will be sent in the processing flow:
To another processing role
To the applicant role (for consultation or payment)
To end- the application file is closed/ end of processing
Therefore, the roles/screens in the processing part will come in an order specified by the analyst and this functionality is called Flow Builder.
The analyst must be able to visualize the flow of roles/screens.
Must have
SF-5
Processing part - creation of fields on processing screens

On each screen, an analyst can create fields that must be filled by the role operator and place them on the screen. Fields will have the following characteristics:
A name (e.g. registration number, date of registration, type of registration, validate application, etc.)
A type (text, number, date, selector, catalogue, button, etc.)
The name of the registration(s) the field is associated with (i.e. the corresponding data is a requirement for this registration)
Mandatory or optional
Every time a field is created it is recorded in the “data” part of the rules engine.


Fields can be grouped into blocks, columns, field sets and other containers (tables). A container is defined by a name.


Fields can be moved on the screen by “drag-and-drop, inside/outside of and between blocks.


In addition to fields, the analyst can create information texts and images that, contrary to fields, do not expect any input from the applicant.


Only human roles have the option to build processing screens.


Determinants and groups of determinants created in the rule engine can be assigned to each field. A field will be displayed only if the determinants assigned to it are true.
Must have
SF-6
An analyst must be able to add QR-code/barcode scanning function to the service screen
An Analyst can add a form field element (e.g. button) to a screen and configure an action to trigger the capture of data from a QR-code.
Expected result- Analyst will build a service that has a button on the screen and a field on the screen to store the captured data. An applicant/user can trigger the “Read QR code” button on the screen of a service that opens the mobile phone’s (or other device) camera, reads the QR-code and captures the data from QR code to a field on the screen. Example data extracted from the QR-code is “MCTS123”.
QR code must be generated with the ISO/IEC 18004:2015 standard.
Must have
UC2
SF-7
Actions - the analyst must be able to configure triggering of actions when a user or system initiates an event on a screen of a service.


A triggering event can be a button click, a form element click, data being entered into a field, or a row being added to a table.


The action attribute specifies one or more of the following data mapping (BOT):


where to send the form-data when an event is triggered (Data BOT action) and where to store the received data (response). For example, the user will enter first name and last name and after entering the last information the system will initiate a data BOT action to search data from the external data source and store the answer(response) phone number to the correct data field;


where to pull data (from an external registry API) and where to show the answer in the user interface fields;


where to send user (screen flow action). For example, the button click will take a user to the next screen. The next screen can be internal screen or external URL;


validate captured data integrity (required fields must be filled);


save entered information;


send message (screen message, sms, e-mail, API message etc.)
Some actions can be activated only for a specific category of subjects. The analyst can define, through determinants (or combination of determinants) the different categories of subjects and link them to specific actions.


Examples:
1.User enters a person's identifier (tax number) and the button pulls first name, last name and date of birth from external API on the screen.


1.Married applicants must provide the first name, last name and date of birth for their spouse (attribute: “married”) and when data is entered, then the application screen will validate the entered persons name from the Population Registry and return validation answers on the screen (Success, Fail). Actions are only triggered if the user has entered the data AND “person is married”- determinant.


2.User clicks the “Validate and send” button on the screen, then the system will activate three actions: Save user data action, validate user data action, send user data action.


3.User clicks the “Print” button and the system triggers “Print to PDF” data action where a template is used as base for creating a new PDF document. System will enable the user to see, print or download the generated PDF.


4.User submits application and system will trigger BOT Role in the flow and it in turn activates data action bot -e.g. POST/GET message to external API.


Must have
UC1
SF-8
Formulas - Analysts must be able to add formula calculations to and between the fields. The Formulas can be added to numeric fields, int, decimal, date. Calculated values allow calculating values based on the values in other fields of the form. E.g. If the registration subject has more than 2 children, then multiply the social payment times the number of kids.
Must have
UC2
SF-9
Preview- Analyst must be able to preview service User Interfaces before publishing the service to the applicants.
Following preview functions must be available.:
1.Preview of user interfaces one by one;
2.Preview of full service;
3.Preview of full service in test instance with the functionality to test the full service before publishing to live instance. .
Must have
UC1
SF-10
Import/Export of service descriptions- Analyst must be able to import/export full service description.
Service descriptions must contain at least:
1.User interfaces, screens, fields;
2.Process flow;
3.Service settings.
As a result, the service can be imported with minimal effort from another instance and published for users/applicants to use. Instance specific configurations must be done in each instance and are not target to import export.
Must have


6.1.3 Control Configurator’s Functional Requirements
Control configurator, to check if the claims (claims and credentials of registers) are complete and true. This is done through:
Define if the field is mandatory(required) or optional.
Add input masks (e.g. only numbers, text , alphanumeric, etc)
Checks between fields in the screens, web services with external databases, or human revision (by an operator of the entity in charge of the registration)
Pre-requirements:
User is authenticated and authorized to use this administrative Control Configurator functionality.
REQ-#
Requirement
Type & UC
CC-1
Controlling the data capturing- Form field value validation
An Analyst must be able to configure field specific validation options e.g.:
required;
number, bigger, smaller, min, max;
text, regular expression, contains, mask;
date, earlier, later, today, older than age (The age of the applicant must be >=18);
File upload size max limit;
File upload type allowed.


Must have
UC1
CC-2
Controlling the data capturing- Form field value validation from external API
An analyst must be able to configure screen field(s) validation from external API data source.


Examples:
Applicant name and ID must match with data in Civil Registry record;
Subject (first name, last name, DoB) must not been entered to the MCTS registry.
Must have
UC1
CC-3
Controlling the data capturing- data integrity validation
The system must verify that all claims/fields are correctly captured and all required documents uploaded.
The system must generate on screen meaningful error messages if any requirements are not fulfilled.
The system should not let user to submit application file if screen data capturing is incomplete.
Must have
UC1
5.2 Online Registration Services Functional Requirements
The purpose of the online registration services (from here on e-services) module of Registration BB is:
to enable Applicants to apply for and receive registration claims(certificated documents);
to enable the Back Office staff, i.e. Operators to process applications, register information and issue registration certificates.
Example UC: Maternal and Newborn Health USE CASE
Sona registers Sowmya in MCTS program. With Sowmya’s consent, Sona registers Sowmya’s child’s name, address and birth certificate, and Sowmya’s name and ID as the caretaker of the child into the MCTS system, which automatically validates the birth certificate and Sowmya’s ID with the government’s citizen records system. Sowmya then creates an account in MCTS for her electronic health records (EHRs) and a barcoded unique ID card for getting further assistance. MCTS connects Sowmya’s mobile phone number to her ID and enables permission for Sona to electronically coordinate various MCTS services for Sowmya.
User story
As an Applicant I want to use an e-service, so that I can apply for multiple logically grouped registrations with one integrated service and receive all needed claims/certificates simultaneously.
As an Applicant I want to:
1.go through the filling process and submit an application to receive a registration (certificate);
2.apply for multiple registrations within a single service;
3.monitor the processing status of my application;
4.see the history of all applications submitted by myself.
Pre-requirements:
User/applicant has access credentials;
Electricity and internet is available.
Post-requirements:
Applicants can log in to the system and see available e-services;
Applicants can select relevant services and apply for a registration(s);
Applicants can submit applications to relevant entities;
Applicants can see applications in draft, rejected, validated and sent back for corrections status;
Entity operators can see list of received applications and process the applications;
Operators can make decisions (three types) and upload the decisions to the system as results;
Operators can see statistics of the processings.
Each back office operator can only see relevant data of the application. Operators are authorized to see and process their role related applications. . \
REQ-#
Requirement
Type & UC
DS-1
User Account (A0)
The User Account page, A0, is the first page that all users see when they authenticate (log in) to the system.
A0 must contain the following sections:
"My applications" part with various tabs:
​
list of applications (can be filtered and queried by status);
list of documents in the account and access to each of them;
application file content - the data sent with the applications;
messages received.
"Services available" part listing the services available for applicant to use. For each service there is a button, an icon, a title, an explanation text.
In order to make the service usable and personalized, Applicants must authenticate to the system - then the Applicant’s information is automatically attached to the application file when sending the application for processing.


The system must enable to:
1.see the User Account screen(Dashboard);
2.select an e-service from the list of e-services and fill a new application;
3.open the Applicant’s own applications to see the content;
4.save and continue filling the Applicant’s draft applications;
5.filter applications (search free text from application name, submission date, deadline date, and status);
6.delete draft applications;
7.see the content (Data, documents) of the submitted applications and the status of the application;
8.see “My documents” - certificates and/or approvals issued for the Applicant;
9.see and give approval for applications waiting for the Applicant's approval;
10.see, correct and resubmit applications sent back for correction;
11.see applications rejected by the Back Office;
12.see messages sent for the Applicant;
13.see and CRUD all documents uploaded by the Applicant;
14.see a list of registration application files, filtered by status (pending, validated, rejected, sent back for correction);
15.send on screen messages and e-mail, sms, etc. messages to applicant(s) and users based on application statuses;
16.see the status of the application file of registration(s) process.
Must have


DS-2
e-Service screens
An applicant must have an option to see all screens of the e-service. The e-service may have one or more screens. Service screens are preconfigured in Screen and flow builder as service schema. Example screens:
Guide screen: this is a screen where the analyst can create text for the information of the applicants (guidelines) or ask questions (through fields) to determine what category of subjects the applicant belongs to (i.e. if the applicant is subject to the registration and what data, documents and fees are required).
Applicant form screen: this is where the applicant will provide the required data.
Documents upload screen: where the applicant will upload scanned copies of the required documents/credentials.
Payment screen: where the applicant will see a list of fees that must be paid and can be redirected to an external online payment service.
Send screen: where the applicant can be reminded of any information missing in his/her application (if some fields have not been filled or documents not uploaded) and will be requested to confirm his/her will to apply for registration.
The above screens, when activated, will be displayed, in the predefined order (guide, applicant form, document upload, payment, send) as a wizard. If not activated, then applicant will not see the pages.
Must have


DS-3
e-Service data capturing
When an applicant is entering data the system must capture data entered.

Applicant can save their applicant file as a draft and continue data entering later.
Must have


DS-4
e-Service data validation
When an applicant is entering data the system must validate the data based on configuration made by Analyst in the Control Configurator.
Must have
DS-5
e-Service registrations
The system must tell applicants which services are applicable.
The system must have the list of applicable registrations where the Applicant can make a selection before continuing to the next form page. A registration may be optional or mandatory.
The system will not allow the Applicant to continue or submit the file if mandatory registrations are not selected.


Applicants can select multiple registrations in the same application.
Example: the UC-Postpartum infant care- Registrations in Civil registry, mother and child tracking program (MCTS) and optionally to pediatrician first meeting registration - three simultaneous registrations within one service.
Must have


DS-6
e-Service required documents(requirements)
When an applicant has filled data/ selected registration to apply for, the system must show which additional information/documents must be uploaded with the application. Duplicate requirements are merged. If a requirement is an output of one registration and at the same time the input to the next registration, then this document must not be asked/visible in the requirements list as it will be acquired during the process.
An Applicant must be able to upload documents or take the documents to the counter service as originals.
Must have


DS-7
e-Service required fees/payments
When an applicant has filled data/ selected registration to apply for, the system must show which fees are relevant.
Applicants must see the list of all fees to be paid, displayed both as sum and separately;
Fees can be paid in bulk;
Fees can be paid in the beginning of the process (prepeyment) ; in the middle of the process after a decision or after the process is finished upon receiving the result/output (cash payment);
Payment options may include: online payment; cash payment; mobile payment, etc;
All payment-related transactions must be logged;
All payments received must be available in the payment registry (or equivalent registry) as successful transactions.


Must have


DS-8
e-Service movement on screens, roles and submission
Applicant can move between the screens and change the data up to the point of submission.


Applicants can submit application for processing(flow). All submitted applications are recorded in processing flow engine and first role defined in the flow builder will receive the the registered application file as a task for processing.


Movement on the screens can be done by clicking a button (Next) or by clicking on a tab/page name.

Movement between the processing roles is done via decisions (approve, reject, send back)


System must validate inconsistencies of the application upon submission.
Must have


DS-9
e-Service application history
Applicant must see the application and flow history, process registration time and processing status in a flow. It should be possible to see which Institution is currently processing the application.


Applicants must see the expected processing end time for each application.
Must have


DS-10
Read information from QR-code/barcode and insert to the form
Applicant can use a function (e.g. button) and the action to capture data from QR-code.


Expected result- applicant can activate (mobile phone) camera, read the QR-code and capture the data from QR code to a field. Example data to be captured: “MCTS31”; “www.registrations.org”
​<Example UI>​
Must have




UC2
DS-11
System audit log functionality
System logs all user action in the system.


User action log is visible for admin users.


By default user action log is stored for 1 year after which the system will delete the log. The storage length is configurable in the Rules Engine.


Statistics are entered to statistics log table.
Must have


UC3
DS-12
Back office Operators must have a view to see the list of applications to be processed (task list dashboard).


The system must have the function for an Operator to pick assignments from the common task dashboard.


The system must have the view for an Operator to see assigned roles and assigned tasks for this role.


Operators are linked to Institutions (or sub-units) and roles, thus can only see the tasks relevant for their role and Institution.

Optionally (configurable) - an operator could be able to claim a task from the application task dashboard. When task has been claimed, then the application file will be taken off from the common pool.


​<Example UI>​
Must have
DS-13
An Operator of a role must see the received application file screen containing all information submitted by an Applicant and information complemented by other Operators while processing the same file.


Required documents relevant for this role and registration linked to the role;


Required data relevant for this role and registration(s) linked to this role.


An Operator must not see any information that is not relevant/required for the registration that this role is serving.


Must be able to see the history of the application file processing.


Must be able to see the status of the application file.


​<Example UI>​
Must have
DS-14
An Operator must be able to make a decision in the system by selecting the right decision type (approve, reject, send back for correction).


At least one decision option must be available in order to process the application file.


The system must enable a form for an Operator to draft a decision text and select/fill additional information on the form.


In case of errors in the application, an operators must be able to mark which document and/or data field is incorrect. Applicants must see the highlighted information.
​<Example UI>​
Must have
DS-15
Operators must have the option to print, sign and upload a certificate.


The system must not let an Operator make a decision in case a required document/result certificate is missing.


The system can display, print and upload a filled certificate from a template.
Must have
DS-16
Operators must have the option to edit application information if corrections are needed.


The system must highlight if an Operator has made any changes to the information submitted by the Applicant.


The system should enable the Operator to remove and/or upload required documents.
Must have
5.3 Coverage Map
The coverage map shows how the Functional Capabilities (by an applicant and a registrar) in specific use cases match the functional requirements as described from page 10 in that document.
User Interface- Provide data in an online form, upload copies of credentials/claims/ documents.
Case management described in the following table is functionality description defined in the Dial use cases. In this document the used terminology is flow builder.
Use Case
User Journey
Functional Capabilities
Technical requirements
of No-code development platform (5.1)
Technical requirements of Online registration services (5.2)
Registration


Postpartum and Infant Care
1. Capture Basic Details
Rules engine (5.1.1);
User interface and flow builder (5.1.2);
Control configurator (5.1.3);



5.2 Online registration services functional requirements:
DS-1; DS-2; DS-3; DS-4; DS-5; DS-6; DS-8;


Registration


Postpartum and Infant Care
2. Optional- registration payment
Rules engine (5.1.1);
User interface and flow builder (5.1.2).


DS-7
Registration
Postpartum and Infant Care
3. Optional: Validate with foundational ID system
User interface and flow builder (5.1.2)


DS-2; DS-3; DS-4
Registration



Postpartum and Infant Care
4. Capture Registration Details
Rules engine (5.1.1);
User interface and flow builder (5.1.2);
Control configurator (5.1.3);
DS-3; DS-6; DS-5
Registration



Postpartum and Infant Care
5. Optional where legally required: Get Citizen Confirmation
User interface and flow builder (5.1.2);
DS-3; DS-6
Registration




Postpartum and Infant Care
6. Update Register.
The local register is updated for later use.
Rules engine (5.1.1);
User interface and flow builder (5.1.2);
Control configurator (5.1.3);
DS-3; DS-5
Registration



Postpartum and Infant Care
7. Capture Card Details
User interface and flow builder (5.1.2);
Control configurator (5.1.3);
DS-10
Registration



Postpartum and Infant Care
8. Assign Card to Parent
User interface and flow builder (5.1.2);
DS-3; DS-8; DS-5
Registration




Postpartum and Infant Care
9. Update Registry
The card number and mothers details are sent to the Govn. Registry for update, e.g. Department of Health or Home Affairs.
User interface and flow builder (5.1.2);
DS-3; DS-5; DS-8
Registration



Postpartum and Infant Care
10. Capture Basic Details
Rules engine (5.1.1);
User interface and flow builder (5.1.2);
Control configurator (5.1.3);
DS-3; DS-5
Registration




Postpartum and Infant Care
11. Update Register
The local register is updated for later use and submit the information for the remote Govn. Department Registry.
User interface and flow builder (5.1.2);
DS-3; DS-5; DS-8
Registration




Postpartum and Infant Care
12. Request Birth Certificate
Rules engine (5.1.1);
User interface and flow builder (5.1.2);
DS-3; DS-5; DS-8; DS-12; DS-13; DS-14; DS-15
Registration





Postpartum and Infant Care
13. Give Reference Number.
Once the request is successfully committed the mother is given a reference number.
User interface and flow builder (5.1.2); SF-7
DS-1; DS-14; DS-15
Registration





Postpartum and Infant Care
14. Search Patient Case
Generate a new folder for case records and link it to the child ID. If no case exists, create one and link the Card, otherwise identify the correct record and store the case UID.
User interface and flow builder (5.1.2);
Control configurator (5.1.3);
SF-7
DS-14; DS-15
Registration




Postpartum and Infant Care
15. Update Registry
The card number, mothers details, childs details and birth details, are sent to the Govt, e.g. the Department of Home Affairs.
Rules engine (5.1.1);
User interface and flow builder (5.1.2);
SF-7;
5.2 The online registration services functional requirements;
DS-3; DS-5; DS-8; DS-9; DS-12; DS-13; DS-14; DS-15










Payments




Postpartum and Infant Care
1.HC worker logs into the postpartum payment registry system
User interface and flow builder (5.1.2);
DS-1
Payments



Postpartum and Infant Care
2.Mother presents program membership ID card to the HC worker, e.g. barcode
User interface and flow builder (6.1.2);
DS-10


Payments


Postpartum and Infant Care
3. Capture details for the Mother
Capture data to verify the mother and prevent fraud per legal requirements, for processing later.
API spec.




User interface and flow builder (5.1.2);
DS-3; DS-4
Payments




Postpartum and Infant Care
4.1 Validate the mother has completed all steps
User interface and flow builder (5.1.2);
Control configurator (5.1.3);
DS-3; DS-4
Payments




Postpartum and Infant Care
4.2 Verify mother has no pending incentive voucher for this milestone?
User interface and flow builder (5.1.2);
Control configurator (5.1.3);
DS-3; DS-4
Payments



Postpartum and Infant Care
4.3 Ask HC worker to certify that all steps have been completed




User interface and flow builder (5.1.2);
Control configurator (5.1.3);
DS-3; DS-4
Payments


Postpartum and Infant Care
5. Determine payment amounts for HC worker and mother
Rules engine (5.1.1);


DS-3; DS-4
Payments



Postpartum and Infant Care
6. For the mother, a cash payment is given via a paper payment voucher
User interface and flow builder (5.1.2);
Control configurator (5.1.3);
DS-3; DS-4
Payments



Postpartum and Infant Care
9. Record payment status and amounts in registry
User interface and flow builder (5.1.2);
Control configurator (5.1.3);
DS-3; DS-5; DS-8; DS-9; DS-12; DS-13; DS-14; DS-15










Case Management



Postpartum and Infant Care
1. HC worker logs into the MCTS registration system
User interface and flow builder (6.1.2)
DS-1;
Case Management



Postpartum and Infant Care
2. Caretaker presents program membership ID card to the HC worker
Rules engine (5.1.1);
User interface and flow builder (5.1.2)
DS-10
Case Management




Postpartum and Infant Care


3. HC workers have access to minimal required data for the purposes of completing this process.


User interface and flow builder (5.1.2)
DS-5; DS-3; DS-4
Case Management



Postpartum and Infant Care
4. The HC worker may read information from the child’s health records registry.
User interface and flow builder (5.1.2)
DS-3; DS-4
Case Management



Postpartum and Infant Care


5. The HC worker updates prescriptions for medication
API spec.
Rules engine (5.1.1);
User interface and flow builder (5.1.2)
DS-2; DS-3; DS-4; DS-5
Case Management


Postpartum and Infant Care
6. The HC worker updates prescriptions for tests
User interface and flow builder (5.1.2)


DS-2; DS-3; DS-4; DS-5, DS-8
Case Management



Postpartum and Infant Care
7. The HC worker updates prescriptions for nutrition

REQ-#	Requirement	Type & UC
RE-1	Creation of Services An analyst (user) must be able to create, in the rule engine, one or more services, each service encompassing one or more registrations. A “Service” is a name given to a registration, or to a combination of registrations which can be undertaken simultaneously. To create a service, an analyst will: Give a name to the service Link one or more registrations to the service	Must have
RE-2	Publish service to external instance Each service can be published in the same or in a separate instance, together with the rule engine. Instance must be configured and interoperable with Registration BB service definitions.	May have
RE-3	Creation of one or more “Registrations” An analyst can create one or more registrations. For each registration, the analyst defines in clear language, in the rules engine: The name of the registration The entity in charge of the registration	Must have
RE-4	Definition of the subjects of a registration For each registration, an analyst must be able to report/input in the rule engine, in clear language, rules defining who/what are the subjects of the registration. To this end, the analyst can select one or various of the following options: 1. The registration is mandatory to all 2. The registration is mandatory to specific subjects 3. The registration is optional to all 4. The registration is optional to specific subjects 1 and 2 can’t be selected simultaneously; 3 and 4 can’t be selected simultaneously. Specific subjects (in 2 and 4) can be defined through determinants or a combination of determinants. Determinants can be combined by “AND” and “OR” operators. Combinations can be grouped into “groups of determinants”. Group of determinants can be combined through “AND” and “OR” operators. Examples: 1. Registration is mandatory for attribute “resident” (all residents must register) 2. Registration is mandatory for attribute “resident” AND attribute “foreigner” (all residents who are foreigners must register) 3. Registration is mandatory for {attribute “resident”} AND {attribute “foreigner” OR attribute “have children”} (all foreign resident must register; national residents who have children must register)	Must have
RE-5	Definition of the results of a registration An analyst must be able to report/input in the rule engine, in clear language, rules defining what are the results of a registration. The result of a registration has a name (example: registration number, registration certificate, permit, license, etc.). To this name, the analyst must be able to associate a template/document (see RE-11). In some cases, some subjects of the registration will receive a different result. The analyst can define through determinants (or combination of determinants) the different categories of subjects and can link each category of subjects to a specific result. Examples: 1. Future truck drivers that apply to a driving license and pass the exam will receive a driving license for “large vehicles”, while car drivers will receive a driving license for “light vehicles” (attributes: “truck driver” or “car driver”) 2. Enterprises with assets below US$5,000 will receive a “Cottage Industry Certificate”; enterprises with assets above US$5,000 will receive a “Business License”, when applying for an activity license (attributes: “assets below US$5,000” and “assets above US$5,000”)	Must have
RE-6	Requirements of a registration - Documents/Credentials An analyst must be able to report/input in the rule engine, in clear language, rules defining what are the documents (= credentials) that must be provided. A document/credential can be defined by a name One registration can have several required documents/credentials A document/credential can be physical or digital For each required document, the analyst can select one of the following options: has to be brought to the front desk; has to be uploaded has to be signed in front of an Operator. The required documents can differ according to the categories of subjects. The analyst can define, through determinants (or combination of determinants) the different categories of subjects and link them to specific required documents. Examples: 1. Married applicants must provide a copy of their wedding certificate (attribute: “married”) 2. Foreigners must provide a copy of their residence permit (attribute: “foreigner”) 3. Applicants that can’t provide a copy of their birth certificate must provide a certified copy of their ID (attribute: “can’t provide a copy of the birth certificate”)	Must have
RE-7	Requirements of a registration - Fees An analyst must be able to report/input in the rule engine, in clear language, rules defining what are the fees of a registration. The fees of a registration has a name (example: State fee of MCTS programm, license registration fee etc.). To this name, the analyst must be able to associate an amount and a currency. Fee can be calculated or fixed; One registration may have 0..n fees; All fees must have an assigned currency. The system may allow multiple currencies; A fee can have a description. When the fee is calculated, a formula builder will allow the analyst to build the formula, using values from any field in the service and numeric values, combined with the usual operators (+, -, *, /). In some cases, some subjects of the registration will receive a different fee. The analyst can define through determinants (or combination of determinants) the different categories of subjects and can link each category of subjects to a specific fee. Examples: 1. Mothers with one child that apply to a registration to MCTS program will receive a identity card for 10 EUR, while mothers with two children or more will receive the identity card for 15 EUR (attributes: “one child” or “more than one child”) 2. Farmers with farming land area > 10 000 sqm that apply to registration of farm land will receive registration certificate for 10 EUR, while farmers with land area <= 10 000 sqm will receive registration result/credential certificate for 5 EUR.	Must have
RE-8	Requirements of a registration - Data/Claims An analyst must be able to report/input in the rule engine, in clear language, rules defining what is the data (= claims) that must be provided. A piece of data is defined by: A name (e.g. date of birth, nationality, first name, last name, etc.) A type (text, number, date) mandatory/ optional (See Control configurator element for more options) As for the other requirements, some data can be required only for a specific category of subjects. The analyst can define, through determinants (or combination of determinants) the different categories of subjects and link them to specific required documents. Examples: 1. Married applicants must provide the first name, last name and date of birth for their spouse (attribute: “married”) 2. Owners of farm land should provide the number and date of registration of their property; applicants who rent farm land must provide the name and ID number of the owner (attribute: “own land”, “rent land”)	Must have
RE-9	Possibility to combine various registrations in one service In many cases the process for the user/applicant contains multiple pre-and post registration steps in order to achieve the final goal (e.g. apply for a healthcare program). For example, in order to register a mother and a newborn child to the Mother and Child support program, both of the subjects must be previously registered in the Civil/Population registry. Civil registry registration service could be a separate service, but it is much user friendlier and less time consuming for the applicant to merge the two registrations into one service that can be filled at the same time. This service type is called Single Window- or integrated registrations service. To facilitate the combination of various registrations in one service: Registration requirements (documents/credentials, results, fees) must be reusable inside the service. One registration may re-use another registration result credentials as input requirements. Overlapping requirements and/or results must be automatically eliminated. Fees of all registrations must be merged into one sum, so that the applicant could see and pay total fees. Fee information is stored and segregated per registration. In one registration the document/credential may be issued as a result and in another registration the same document/credential may be required as an uploadable requirement. The system must eliminate the overlapping results and/or requirements if the requirements overlap inside the service. Examples: One service has two registrations and both of them require a passport to be uploaded. When an applicant chooses to apply for both registrations then the system must ask for the passport upload only once. One service has two registrations. First registration’s result (credential) is the second registration’s requirement. The system must not ask this requirement from the applicant as the result will be generated during the process. However, if the user chooses to register for only the second registration then the requirement must be asked.	Must have

RE-10	Creation and functioning of determinants The analyst can define through determinants (or combination of determinants) the different categories of subjects and can link each category of subjects to a specific element of a service. An element of a service can be a field, block, button, message, processing role, result, requirement etc. Simplest case being, is this claim data field on the screen relevant for all subjects or only for a specific category of subjects? If all then no determinant is needed as all users will see and use it. If a specific (e.g. “applicant is married”) category and this category must fill in additional information (e.g. “Spouse name”), then a determinant must be added to control the field visibility for this category of subjects. If the user is married, then the determinant is true and the “Spouse name” field is visible; if the determinant evaluates to false, then the spouse name field is not visible for the subject. Analyst must be able to: create and manage determinants (CRUD); search the existing determinant; reuse determinant inside the same service; use formulas - calculate math functions on the form with user input value and use the calculated value in the determinant. E.g. math functions (SUM, MIN, MAX, AVG, COUNT, MEDIAN, CEILING, FLOOR, ROUND, CONCAT, CONCAT_WS, LEN, REPLACE, UPPER_CASE, LOWER_CASE). Apply determinants to: Any element of a service (registration, claims/data fields, screens, roles, templates etc.) Any element of a registration (results/credentials, requirements/documents) Determinants can be combined by “AND” and “OR” operators. Combinations can be grouped into “groups of determinants”. Group of determinants can be combined through “AND” and “OR” operators.	Must have
RE-11	Definition of a template associated to the result of a registration An analyst must be able to create an electronic template (a screen with images, text, fields, QR code) and to link it to the result of a registration. A template can be: Filled with values coming from fields in the service or from external databases; Printed as a pdf file. Generated and uploaded to the system as a PDF file. On each template, an analyst can create data fields that must be filled by the system and place them on the screen of the template. Fields will have the following characteristics: A name (e.g. date of birth, nationality, first name, last name, select option, submit application, etc.) A type (text, number, date, selector, catalogue, button etc.) Source of information/capture data from. Function to capture data from application screens upon creation of PDF. In addition to fields, the analyst can create information texts and add images, QR codes on the template screen. QR code must be generated with the ISO/IEC 18004:2015 standard. Determinants and groups of determinants created in the rule engine can be assigned to each field on a template. A field will be displayed/printed only if the determinants assigned to it are true. Fields can be grouped into containers (blocks, tables etc). A container is defined by a name. Fields can be moved to and on the screen by “drag-and-drop, inside/outside of and between containers.	Must have

REQ-#	Requirement	Type & UC
SF-1	Application file - Creation of screens and of their sequence An analyst must be able to create one or more screens that will allow to show information to the applicant and to display fields that the applicant will have to fill to provide the requirements of the registration. The analyst can define the sequence/order in which the screens will be displayed to the applicant. To this end, the analyst will be able to activate or inactivate, through a toggle, the following screens: Guide screen: this is a screen where the analyst can create text for the information of the applicants (guidelines) or ask questions (through fields) to determine what category of subjects the applicant belongs to (i.e. if the applicant is subject to the registration and what data, documents and fees are required). Applicant form screen: this is where the applicant will provide the required data. Documents upload screen: where the applicant will upload scanned copies of the required documents/credentials. Payment screen: where the applicant will see a list of fees that must be paid and can be redirected to an external online payment service. Send screen: where the applicant can be reminded of any information missing in his/her application (if some fields have not been filled or documents not uploaded) and will be requested to confirm his/her will to apply for registration. The above screens, when activated, will be displayed, in the predefined order (guide, applicant form, document upload, payment, send). The flow of screens can be visualized by the analyst.	Must have
SF-2	Application file - Creation of fields on each screen On each screen, an analyst can create data fields/claims that must be filled by the applicant and place them on the screen. Fields will have the following characteristics: A name (e.g. date of birth, nationality, first name, last name, select option, submit application, etc.) A type (text, number, date, selector, catalogue, button, etc.) The name of the registration(s) the field is associated with (i.e. the corresponding data is a requirement for this registration) Mandatory or optional Determinants and groups of determinants created in the rule engine can be assigned to each field. A field will be displayed only if the determinants assigned to it are true. Every time a field is created it is recorded in the “data” part of the rules engine. Fields can be grouped into containers (blocks). A container is defined by a name. Fields can be moved to and on the screen by “drag-and-drop, inside/outside of and between containers. In addition to fields, the analyst can create information texts, images that, contrary to fields, do not expect any input from the applicant.	Must have
SF-3	Processing part - Creation of screens/roles The processing part relies on the flow builder because roles are part of the process flow. An analyst can create one or more screens allowing human operators to process the application files, i.e. to review the information sent by the applicant, to add data or documents to the application file (e.g. a number, a date, a credential, etc.), to approve an application, to reject it or to send it back to the applicant when more information is required. We call “processing role” (or simply “role”) each successive processing an application file will go through until final approval is given and the registration is completed. Usually, different roles are ensured by different government entities. It happens that successive roles are ensured by different units in the same entity. Example flow: 1. Unit 1 reviews the application file, checks that all data and documents provided seem true and correct 2. Unit 2 approves the application 3. Unit 3 issues and signs the credential and sends it to the applicant For each role, two screens are necessary: A first screen (list screen) where the operator will be able to: see a list of application files, filtered by status (pending, validated, rejected, sent back to the applicant) select a file for processing (if pending) or for consultation A second screen (processing screen) where the operator will be able to: review the selected application file (data and documents provided by the applicant, fees paid or not) add data or documents to the file Make decision- approve the file, reject it or send it back to the applicant Therefore, an analyst must be able to create one or more roles, each role coming automatically with one list UI and one processing screen UI. Each role will be defined with the following elements: Name of the role Name of the registration the role is associated with Entity in charge of the role Position in the process flow. Determinants and groups of determinants created in the rule engine can be assigned to each role. A role will be displayed/activated only if the determinants assigned to it are true. If Role determinants evaluates to false, then the application file passes the processing role without stopping.	Must have
SF-4	Processing part - Ordering of screens/roles in Flow Builder An analyst will be able to define, for each role, a list of possible statuses, by selecting which of the following statuses are possible for the role: Pending (the file is waiting to be processed by the role) Approved (the file successfully passed the role) Rejected (the application is denied, the file is closed) Send back to the applicant for correction (the operator sends the file back to the applicant and requests that some information be corrected or added) For each activated status, the analyst will be able to indicate where the application file will be sent in the processing flow: To another processing role To the applicant role (for consultation or payment) To end- the application file is closed/ end of processing Therefore, the roles/screens in the processing part will come in an order specified by the analyst and this functionality is called Flow Builder. The analyst must be able to visualize the flow of roles/screens.	Must have
SF-5	Processing part - creation of fields on processing screens On each screen, an analyst can create fields that must be filled by the role operator and place them on the screen. Fields will have the following characteristics: A name (e.g. registration number, date of registration, type of registration, validate application, etc.) A type (text, number, date, selector, catalogue, button, etc.) The name of the registration(s) the field is associated with (i.e. the corresponding data is a requirement for this registration) Mandatory or optional Every time a field is created it is recorded in the “data” part of the rules engine. Fields can be grouped into blocks, columns, field sets and other containers (tables). A container is defined by a name. Fields can be moved on the screen by “drag-and-drop, inside/outside of and between blocks. In addition to fields, the analyst can create information texts and images that, contrary to fields, do not expect any input from the applicant. Only human roles have the option to build processing screens. Determinants and groups of determinants created in the rule engine can be assigned to each field. A field will be displayed only if the determinants assigned to it are true.	Must have
SF-6	An analyst must be able to add QR-code/barcode scanning function to the service screen An Analyst can add a form field element (e.g. button) to a screen and configure an action to trigger the capture of data from a QR-code. Expected result- Analyst will build a service that has a button on the screen and a field on the screen to store the captured data. An applicant/user can trigger the “Read QR code” button on the screen of a service that opens the mobile phone’s (or other device) camera, reads the QR-code and captures the data from QR code to a field on the screen. Example data extracted from the QR-code is “MCTS123”. QR code must be generated with the ISO/IEC 18004:2015 standard.	Must have UC2
SF-7	Actions - the analyst must be able to configure triggering of actions when a user or system initiates an event on a screen of a service. A triggering event can be a button click, a form element click, data being entered into a field, or a row being added to a table. The action attribute specifies one or more of the following data mapping (BOT): where to send the form-data when an event is triggered (Data BOT action) and where to store the received data (response). For example, the user will enter first name and last name and after entering the last information the system will initiate a data BOT action to search data from the external data source and store the answer(response) phone number to the correct data field; where to pull data (from an external registry API) and where to show the answer in the user interface fields; where to send user (screen flow action). For example, the button click will take a user to the next screen. The next screen can be internal screen or external URL; validate captured data integrity (required fields must be filled); save entered information; send message (screen message, sms, e-mail, API message etc.) Some actions can be activated only for a specific category of subjects. The analyst can define, through determinants (or combination of determinants) the different categories of subjects and link them to specific actions. Examples: 1. User enters a person's identifier (tax number) and the button pulls first name, last name and date of birth from external API on the screen. 1. Married applicants must provide the first name, last name and date of birth for their spouse (attribute: “married”) and when data is entered, then the application screen will validate the entered persons name from the Population Registry and return validation answers on the screen (Success, Fail). Actions are only triggered if the user has entered the data AND “person is married”- determinant. 2. User clicks the “Validate and send” button on the screen, then the system will activate three actions: Save user data action, validate user data action, send user data action. 3. User clicks the “Print” button and the system triggers “Print to PDF” data action where a template is used as base for creating a new PDF document. System will enable the user to see, print or download the generated PDF. 4. User submits application and system will trigger BOT Role in the flow and it in turn activates data action bot -e.g. POST/GET message to external API.	Must have UC1
SF-8	Formulas - Analysts must be able to add formula calculations to and between the fields. The Formulas can be added to numeric fields, int, decimal, date. Calculated values allow calculating values based on the values in other fields of the form. E.g. If the registration subject has more than 2 children, then multiply the social payment times the number of kids.	Must have UC2
SF-9	Preview- Analyst must be able to preview service User Interfaces before publishing the service to the applicants. Following preview functions must be available.: 1. Preview of user interfaces one by one; 2. Preview of full service; 3. Preview of full service in test instance with the functionality to test the full service before publishing to live instance. .	Must have UC1
SF-10	Import/Export of service descriptions- Analyst must be able to import/export full service description. Service descriptions must contain at least: 1. User interfaces, screens, fields; 2. Process flow; 3. Service settings. As a result, the service can be imported with minimal effort from another instance and published for users/applicants to use. Instance specific configurations must be done in each instance and are not target to import export.	Must have

Use Case	User Journey	Functional Capabilities	Technical requirements of No-code development platform (5.1)	Technical requirements of Online registration services (5.2)
Registration	Postpartum and Infant Care	1. Capture Basic Details	Rules engine (5.1.1); User interface and flow builder (5.1.2); Control configurator (5.1.3);	5.2 Online registration services functional requirements: DS-1; DS-2; DS-3; DS-4; DS-5; DS-6; DS-8;
Registration	Postpartum and Infant Care	2. Optional- registration payment	Rules engine (5.1.1); User interface and flow builder (5.1.2).	DS-7
Registration	Postpartum and Infant Care	3. Optional: Validate with foundational ID system	User interface and flow builder (5.1.2)	DS-2; DS-3; DS-4
Registration	Postpartum and Infant Care	4. Capture Registration Details	Rules engine (5.1.1); User interface and flow builder (5.1.2); Control configurator (5.1.3);	DS-3; DS-6; DS-5
Registration	Postpartum and Infant Care	5. Optional where legally required: Get Citizen Confirmation	User interface and flow builder (5.1.2);	DS-3; DS-6
Registration	Postpartum and Infant Care	6. Update Register. The local register is updated for later use.	Rules engine (5.1.1); User interface and flow builder (5.1.2); Control configurator (5.1.3);	DS-3; DS-5
Registration	Postpartum and Infant Care	7. Capture Card Details	User interface and flow builder (5.1.2); Control configurator (5.1.3);	DS-10
Registration	Postpartum and Infant Care	8. Assign Card to Parent	User interface and flow builder (5.1.2);	DS-3; DS-8; DS-5
Registration	Postpartum and Infant Care	9. Update Registry The card number and mothers details are sent to the Govn. Registry for update, e.g. Department of Health or Home Affairs.	User interface and flow builder (5.1.2);	DS-3; DS-5; DS-8
Registration	Postpartum and Infant Care	10. Capture Basic Details	Rules engine (5.1.1); User interface and flow builder (5.1.2); Control configurator (5.1.3);	DS-3; DS-5
Registration	Postpartum and Infant Care	11. Update Register The local register is updated for later use and submit the information for the remote Govn. Department Registry.	User interface and flow builder (5.1.2);	DS-3; DS-5; DS-8
Registration	Postpartum and Infant Care	12. Request Birth Certificate	Rules engine (5.1.1); User interface and flow builder (5.1.2);	DS-3; DS-5; DS-8; DS-12; DS-13; DS-14; DS-15
Registration	Postpartum and Infant Care	13. Give Reference Number. Once the request is successfully committed the mother is given a reference number.	User interface and flow builder (5.1.2); SF-7	DS-1; DS-14; DS-15
Registration	Postpartum and Infant Care	14. Search Patient Case Generate a new folder for case records and link it to the child ID. If no case exists, create one and link the Card, otherwise identify the correct record and store the case UID.	User interface and flow builder (5.1.2); Control configurator (5.1.3); SF-7	DS-14; DS-15
Registration	Postpartum and Infant Care	15. Update Registry The card number, mothers details, childs details and birth details, are sent to the Govt, e.g. the Department of Home Affairs.	Rules engine (5.1.1); User interface and flow builder (5.1.2); SF-7;	5.2 The online registration services functional requirements; DS-3; DS-5; DS-8; DS-9; DS-12; DS-13; DS-14; DS-15

Payments	Postpartum and Infant Care	1.HC worker logs into the postpartum payment registry system	User interface and flow builder (5.1.2);	DS-1
Payments	Postpartum and Infant Care	2.Mother presents program membership ID card to the HC worker, e.g. barcode	User interface and flow builder (6.1.2);	DS-10
Payments	Postpartum and Infant Care	3. Capture details for the Mother Capture data to verify the mother and prevent fraud per legal requirements, for processing later. API spec.	User interface and flow builder (5.1.2);	DS-3; DS-4
Payments	Postpartum and Infant Care	4.1 Validate the mother has completed all steps	User interface and flow builder (5.1.2); Control configurator (5.1.3);	DS-3; DS-4
Payments	Postpartum and Infant Care	4.2 Verify mother has no pending incentive voucher for this milestone?	User interface and flow builder (5.1.2); Control configurator (5.1.3);	DS-3; DS-4
Payments	Postpartum and Infant Care	4.3 Ask HC worker to certify that all steps have been completed	User interface and flow builder (5.1.2); Control configurator (5.1.3);	DS-3; DS-4
Payments	Postpartum and Infant Care	5. Determine payment amounts for HC worker and mother	Rules engine (5.1.1);	DS-3; DS-4
Payments	Postpartum and Infant Care	6. For the mother, a cash payment is given via a paper payment voucher	User interface and flow builder (5.1.2); Control configurator (5.1.3);	DS-3; DS-4
Payments	Postpartum and Infant Care	9. Record payment status and amounts in registry	User interface and flow builder (5.1.2); Control configurator (5.1.3);	DS-3; DS-5; DS-8; DS-9; DS-12; DS-13; DS-14; DS-15

Case Management	Postpartum and Infant Care	1. HC worker logs into the MCTS registration system	User interface and flow builder (6.1.2)	DS-1;
Case Management	Postpartum and Infant Care	2. Caretaker presents program membership ID card to the HC worker	Rules engine (5.1.1); User interface and flow builder (5.1.2)	DS-10
Case Management	Postpartum and Infant Care	3. HC workers have access to minimal required data for the purposes of completing this process.	User interface and flow builder (5.1.2)	DS-5; DS-3; DS-4
Case Management	Postpartum and Infant Care	4. The HC worker may read information from the child’s health records registry.	User interface and flow builder (5.1.2)	DS-3; DS-4
Case Management	Postpartum and Infant Care	5. The HC worker updates prescriptions for medication API spec.	Rules engine (5.1.1); User interface and flow builder (5.1.2)	DS-2; DS-3; DS-4; DS-5
Case Management	Postpartum and Infant Care	6. The HC worker updates prescriptions for tests	User interface and flow builder (5.1.2)	DS-2; DS-3; DS-4; DS-5, DS-8
Case Management	Postpartum and Infant Care	7. The HC worker updates prescriptions for nutrition