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.
- 2.Unconditional social cash transfer https://solutions.dial.community/use_cases/unconditional_social_cash_transf
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.
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:
| 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:
| 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 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:
| 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:
| 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.
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:
| 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.
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:
| 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:
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:
| 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:
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:
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:
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:
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:
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 |
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:
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:
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:
For each role, two screens are necessary:
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:
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:
For each activated status, the analyst will be able to indicate where the application file will be sent in the processing flow:
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:
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):
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:
| 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.:
| 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:
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 |
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.:
| 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:
| 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 |
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:
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:
| 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:
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.
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.
| 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” | Must have UC2 |
DS-11 | System audit log functionality
| Must have UC3 |
DS-12 | Back office Operators must have a view to see the list of applications to be processed (task list dashboard).
| 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.
| 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).
| Must have |
DS-15 | Operators must have the option to print, sign and upload a certificate.
| Must have |
DS-16 | Operators must have the option to edit application information if corrections are needed.
| Must have |
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 | |
Registration | Postpartum and Infant Care | 1. Capture Basic Details | 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 | DS-7 | |
Registration | Postpartum and Infant Care | 3. Optional: Validate with foundational ID system | DS-2; DS-3; DS-4 | |
Registration | Postpartum and Infant Care | 4. Capture Registration Details | DS-3; DS-6; DS-5 | |
Registration | Postpartum and Infant Care | 5. Optional where legally required: Get Citizen Confirmation | DS-3; DS-6 | |
Registration | Postpartum and Infant Care | 6. Update Register. The local register is updated for later use. | DS-3; DS-5 | |
Registration | Postpartum and Infant Care | 7. Capture Card Details | DS-10 | |
Registration | Postpartum and Infant Care | 8. Assign Card to Parent | 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. | DS-3; DS-5; DS-8 | |
Registration | Postpartum and Infant Care | 10. Capture Basic Details | 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. | DS-3; DS-5; DS-8 | |
Registration | Postpartum and Infant Care | 12. Request Birth Certificate | 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. | 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. | 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. | 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 | DS-1 | |
Payments | Postpartum and Infant Care | 2.Mother presents program membership ID card to the HC worker, e.g. barcode | 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. | DS-3; DS-4 | |
Payments | Postpartum and Infant Care | 4.1 Validate the mother has completed all steps | DS-3; DS-4 | |
Payments | Postpartum and Infant Care | 4.2 Verify mother has no pending incentive voucher for this milestone? | DS-3; DS-4 | |
Payments | Postpartum and Infant Care | 4.3 Ask HC worker to certify that all steps have been completed | DS-3; DS-4 | |
Payments | Postpartum and Infant Care | 5. Determine payment amounts for HC worker and mother | DS-3; DS-4 | |
Payments | Postpartum and Infant Care | 6. For the mother, a cash payment is given via a paper payment voucher | DS-3; DS-4 | |
Payments | Postpartum and Infant Care | 9. Record payment status and amounts in registry | 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 | DS-1; | |
Case Management | Postpartum and Infant Care | 2. Caretaker presents program membership ID card to the HC worker | DS-10 | |
Case Management | Postpartum and Infant Care | 3. HC workers have access to minimal required data for the purposes of completing this process. | 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. | DS-3; DS-4 | |
Case Management | Postpartum and Infant Care | 5. The HC worker updates prescriptions for medication API spec. | DS-2; DS-3; DS-4; DS-5 | |
Case Management | Postpartum and Infant Care | 6. The HC worker updates prescriptions for tests | DS-2; DS-3; DS-4; DS-5, DS-8 | |
Case Management | Postpartum and Infant Care | 7. The HC worker updates prescriptions for nutrition |