1     General guidelines

The purpose of these guidelines is to establish foundational principles for designing a robust, accessible, and secure system for any kind of registers.

• All user interactions must occur through web browsers supporting HTML5 features, CSS3, JavaScript, progressive web apps, web components and other modern web browser functionality.
• All user interfaces must use responsive design so they can run on screens of different sizes. It is accepted that some screens used by staff may be designed for large screens.
• The system must have a web-based user interface that is compatible with ISO 9241-210:2010 ergonomics and human-centred design principles.
• The system must have a web-based user interface based on HTML5 and support for responsive web design.
• The system must have a web-based user interface that is compliant with Web Content Accessibility Guidelines (WCAG).
• The system’s web-based user interface must implement robust security measures to prevent the OWASP Top 10 vulnerabilities, including input validation, output encoding, authentication, authorization, secure data handling and etc.
• The System must provide comprehensive services, supporting both online and onsite interactions with the institution. This includes facilitating online submission of applications and the provision of electronic services, as well as supporting walk-in scenarios where services are delivered onsite with the assistance of the system for in-office customers.
• The system must be homogeneous: changes of the classifiers in one part should appear in other parts in real time.
• The system must be multi-lingual: any number of languages can be added to the system. The system must have configurations of translations. The user can change language at any time while authenticated. The system must configure 2 languages: English and local language.
• A list of all products used, along with their license type (e.g., open-source free, open-source with support fee, commercial one-time purchase, commercial subscription), should be provided.

2     Guidelines for System Architecture

The purpose of these guidelines is to promote scalability, maintainability, and responsiveness in the system architecture, the following approaches are recommended:

• The system must use the Microservices Architecture pattern to enable independent development and deployment of separate services.
• The solution should be clearly separated into tiers: User Interface, Business Layer and Data Layer
• The system is only accessed by users via the Internet or internal LAN.
• International and open standards must be used.
• The system must support horizontal scalability, allowing to distribute workloads across different servers and data centers
• The systems must support vertical scalability patterns
• The system must be highly available
• The system must be environment agnostic and must be able to operate on cloud (any provider) or on premise (any infrastructure, e.g. bare metal, OpenStack, vSphere, KVM, Hyper-V etc.) without significant modifications
• The system must provide High Availability features with self-healing capabilities out-of-the-box:
  • Restart policies – the system must allow individual restart policies for separate system’s applications/services
  • Health checks – the system must be able to check if an individual system’s applications or services are running as expected. In case application or service is found to be unresponsive or malfunctioning system must be able to take corrective actions to restore normal operations
  • Automatic scaling – the system must be able to scale the number of application or service instances based on CPU utilization or other metrics.
  • Volume snapshots – the system must be able to create snapshots of persistent volumes, which can be used to restore the date in case of failure
• The system must be designed to support the “Build Once, Deploy Anywhere” principle, ensuring that applications can be built once and deployed consistently across various environments (e.g., development, testing, staging, production) without requiring significant modifications.
• The system should maintain separate data models for registry data and application data (e.g. process metadata).
• The system must store registry and application data separately.
• The system must use dynamic data models that separates data structures from application logic to enable support of low code features (e.g. user created application forms).
• The system must be database agnostic.
• Th system must be able to generate database update/migration scripts automatically based on data model changes.
• The system must use object-relational mapper (ORM) framework for alignment of application code to database structures to simplify application extensibility and speed up future development of the system.
• The system must be developed using a domain driven approach and use layered architecture pattern to organize domain logic within application and decouple domain layers from external dependencies (e.g. third-party APIs, frameworks, infrastructure components and etc).
• The system must use event-based communication architectural pattern enabling loose coupling of communicating components that allows independent development and scaling of separate components.
• The system must use asynchronous communication architectural patterns for improved system performance and responsiveness.
• The system must feature component robustness, so that errors in one functional component shall not cause disruption of the operations of the whole system
• The system should leverage asynchronous processing to improve system responsiveness and handle concurrent requests.

3     Guidelines for Register Records Management

The purpose of these guidelines is to ensure data integrity, compliance, and traceability, it is recommended that register records management adhere to the following practices.

• The system must have a register separated from the applications.
• The register record must be created within the register after approval of registration.
• The register record must be updated within the register after approval of amendment.
• Each register record must have a unique registration number, registration date, last update date, status.
• The Register record must maintain a history of changes, providing the ability to view the data for each event, including the time the change was made, the user who made the change, and the option to view detailed records of the history.
• The register record must keep a list of all files which were uploaded to the register as supporting documents to the application.
• The register must keep a valid e-certificate of registration. e-certificate must be generated after approval of the registration and regenerated after each change of data of the e-certificate.
• E-certificate must include QR code with a possibility to scan it and to verify if all details of the certificate are still valid. The QR must include security features to validate if QR was generated by the particular system.
• The QR code must enable direct access to current data from the register. When the data becomes outdated, the QR code check should indicate that document is no longer valid, and the data associated with it becomes obsolete.
• The system must support automatic changes of register record status.

4     Guidelines for Task and Workflow Management

The purpose of these guidelines is to establish a structured framework for effective task and workflow management within the system, allowing various user roles to efficiently complete assigned tasks and meet organizational goals.

• The system must be designed and implemented to support the specific tasks and workflows required by different user roles within the organization. The system must provide the necessary features, permissions, and interfaces to enable each user role to effectively accomplish their assigned tasks.
• The system must have a business process engine capable of autogenerating user tasks based on user configurable BPMN workflow.
• The system must be able to auto assign user tasks based on configurable assignment rules (e.g. based on user role, on user location/branch and etc.).
• The user must be able to see a list of assigned tasks which were claimed by the user or assigned to the user. Filtering should be available.
• The user must be able to see a pool of tasks waiting for completion. Filtering should be available. The task pool should be shown according to the role and office of user.
• The user must be able to claim a task from the pool, work with it and complete it. After claiming, the task must be locked for the particular user and cannot be claimed by other user.
• The system must audit actions with tasks: when a task was created, when the task was claimed, by whom, when the task was completed. This audit should be shown in UI for internal users.
• Tasks must be created according to the workflow designed for the service.
• Tasks management must support task distribution among the different offices in different districts/provinces/regions or at the central level (depending on the procedures of the institution).
• The system must calculate when the application must be processed the latest according to the regulations of the registry (non-working days must be excluded). According to this date the tasks related to the application must be marked as ‘late’ or ‘almost late’.
• The system must include functionality for managing task assignments: the task manager should have the ability to reassign a task that has been claimed by a specific user or assign a user to a task.
• The task manager must see a list of all tasks in his/her office.
• The administrator should be able to create various task lists based on various parameters. Different tasks list should be shown according to roles.
• The system must have a list of all applications which were submitted by any user in the system. The list must have a possibility to filter values or to view details of any record.
• The system must support multi-layer decision making: different decision makers can make various decisions and enter details of decisions. The workflow execution must depend on decisions made.
• The system should have a feature to manage the decision-making process: add more levels or make decision-making automatic.
• The applications must have details of service execution: creation date, submission date, completion date.
• Not submitted applications must be considered as drafts and should be canceled within 10 days after initiating.
• Public users can create a draft application, save it and continue entering details at any time within 10 days after initiating.
• The public users can delete the drafts.
• The system should calculate when the application should be processed. Calculation rules should be configurable. Such date should be calculated after submission.
• Any application can be returned for supplement without any additional fee. The applicant can edit data or attached documents and resubmit the same application. The system should recalculate the date when the application should be processed.

5     Guidelines for System Configuration

The purpose of these guidelines is to establish a flexible, user-configurable system framework that enables efficient deployment, customization, and management of registry services.

• The system should allow accelerated deployment of new registries of different types using predefined registry template and customize created registry using low-code features of the system.
• The system must be considered as low code: many features such as forms, workflows, printout templates, message templates, classifiers, parameters, roles should be configurable by the users of the system.
• The system must have functionality for classifier configuration: search, view a list, view details, create new, edit, delete values of classifiers (drop down lists).
• The system must have the functionality for configuration of number rules: search, view a list, view details, create new, edit, delete rules for number generation.
• The system must have functionality for configuration of register services: search, view a list, view details, create new, edit, delete a service of the register.
• The system must have the functionality for configuration of printout templates (templates of documents to be generated by the system): search, view a list, view details, create new, edit, delete a printout template.
• The user can include any data of the application or the register record to the template.
• The user can include data from the classifiers to the template. The system will add values of the classifiers according to the template language.
• The user can include QR code to the template.
• The user can include a signature specimen of the user to the template.
• The user can include a seal specimen of the office to the template.
• The system must have the functionality for configuring message/notification templates: search, view a list, view details, create new, edit, delete a template.
• The user can include any data of the application or the register record to the template.
• The user can include data from the classifiers to the template. The system will add values of the classifiers according to the template language.
• The system must have the functionality for configuration of languages and translations (translations of labels, menu, help texts, drop down lists / classifiers, message texts, etc.): search, view a list, view details, create new, edit, delete a language / translation.
• The system must have the functionality for configuration of API keys for integrations with external systems: search, view a list, view details, create new, edit, revoke an API key for an external system. The administrator should be able to configure access for each external system.
• The system must have the functionality for configuring institutions details: search, view a list, view details, create new, edit, delete an institution.

6     Guidelines for Payment Service

The purpose of these guidelines is to establish a secure, flexible, and efficient payment processing system within the Registers:

• The system must provide a mechanism for users to make payments for services offered by the system.
• The system must support several methods of payment for a service: e-payment via payment gateway / cash payments.
• The system must be integrated with at least [2-3] payment gateway bank or financial service provider for e-payments. The system should support e-payments and provide the option to retry the payment if a previous transaction was unsuccessful.
• The application can be submitted for processing only after successful payment transaction. In the case of online payments through the e-payment gateway, the application can only be submitted for processing once a return message is received from the payment gateway.
• The system must audit the details of payment transaction.
• For cash payments the system must support the possibility for the cashier to enter details of payment: payment method (cash, card), payment date.
• The system must have the possibility to see a list of payment transactions, to filter a list, to extract details of payment transactions to csv file.
• The system must be integrated with the financial system for transferring details of payment transactions.
• The system must have the possibility to configure fee types and calculation rules for different services. Each fee type should have such details: fee name, amount, calculation rule, currency. Each fee type shall be related to the specific budget line.
• One register service can have one or several fee types.
• The system must generate different printouts for the payments: a payment order, a payment receipt. Templates must be configurable.

7     Guidelines for Notifications

The purpose of these guidelines is to establish a comprehensive notification system within the Register that enhances communication and user engagement by ensuring timely and relevant updates.

• The system must have a notification module for sending notifications to external users about various actions within the service or user management.
• The system must support such notification channels: SMS, email, system notifications. The system must have the possibility to add other channels.
• The system must have an inbox presented to system users for system notifications generated by the system.
• The user must be able to view system notifications in the list, search for any notification, mark notification(s) as read, delete it.
• The system must log when the user and who read the notification first.
• The administrator must be able to configure each notification type: a template for each channel and language, to what channels the notification must be sent.
• The system should ensure different notification templates for different languages and channels.
• The workflow designer must include an option to integrate notifications within the service workflow. This feature should allow notifications to be configured and sent automatically at designated steps within the workflow process
• The administrator must have an option to configure channels of notification: enable or disable any of them.
• The system must have a log of all sent notifications on different channels.
• The user should be able to configure channels how he/she wants to get notifications: enable / disable emails and / or SMS sending.
• The administrator should be able to see a list of all sent notifications.

8     Guidelines for Form Design and Management

The purpose of these guidelines is to establish a flexible and efficient approach to form management within the system, enabling administrators and designers to create, configure, and manage forms effectively.

• The system must support the configuration of forms used for services: for data views of data entering to the application or the register.
• The administrator / designer must be able to see a list of forms prepared, configure any of them, create a new one and relate the form to the workflow.
• The forms should be configurable by using the drag-and-drop principle.
• The system should ensure that the forms created are responsive and accessible on various devices (mobile, tablet, desktop).
• The form management module must use clear labels and tooltips to guide users.
• Most of the business rules for the fields must be configured without redeploying the system.
• The form management module must support such data entry fields as, but not limited to, text, text area, number, date, date and time, drop down list, multi select, checkbox, multiple checkboxes, and radio button.
• The form management module must use conditional logic to show/hide fields based on user input.
• The form management module must support such data entry components: table with several data fields for each record, tables with many data fields (>10) for each record, groups of data fields, components for file uploads, components for signature on screen, and various buttons.
• The designer should be able to design wizard-type forms.
• The designer should be able to add the following buttons to the form: save, delete, submit, next, back and unclaim.
• The form management module must support such data layout components: panel, group of fields, columns, content elements, and placeholders.
• The form management module must support the ability to add help texts for data fields or data groups.
• The form management module must support at least such field validation: visibility, required / optional / conditional, disabled / enterable, minimum / maximum, default value, hierarchical classifiers / drop downs, filtering for drop downs, calculations, restrictions for dates, and masks for data entering.
• The form management module must support the ability to create / use sub forms: a sub form can be created and used in other forms many times.
• The form management module must support the ability to create a custom-made component / data field.
• It should be indicated what type of form management module is used in the system: custom-made or an external tool/product.
• The form management module must be capable of handling form submissions and collecting data securely.
• The form management module must provide functionality to export a prepared form to a file (e.g., JSON). and import it into another environment.
• The form management module must provide bulk import / export of forms.
• The form management module must provide form versioning. Only published versions should be visible for external users.
• The form management module must have the ability to retrieve and manage submitted data, including search, filter, and export functionalities.
• The system must have the ability to support user roles and permissions for form creation and management.
• The form management module must offer functionality to generate standard search forms with filtering criteria and a list of found records. These search forms should be dynamically generated based on the selected data entry form. The designer can select which fields to include as filtering criteria or display as columns in the results list. Such search forms should be available for both applications and register records, with the ability for the designer to regenerate them as needed.
• The system should generate data structures based on dynamic search forms and extract data from already stored records.

9     Guidelines for Workflow Management

The purpose of these guidelines is to outline a flexible and efficient form management system within the Register that supports dynamic form creation, configuration, and management.

• The system must use a friendly open-source platform for process automation and workflow management modelling.
• The system must support the BPMN 2.0 standard for process modelling.
• The workflow management module must support drag-and-drop functionality and have a user-friendly interface.
• The workflow management module must be capable of defining and managing process variables within workflows.
• The workflow management module must have the capability to create and manage sub-processes and reusable process fragments.
• All register services must be executed according to visible and configurable workflows.
• The workflow must utilize the modelling tool’s process engine to execute BPMN models.
• The system must support workflow functionality for human task management, including task assignment, delegation, and completion.
• The workflow must be integrated with external services and systems to automate tasks using service tasks, script tasks, and message events.
• The system must support the configuration of decision tables related to the workflow (like DMN or similar).
• The designer must be able to see and change the workflows of any register service. Uploading a changed version should not require redeploying the system.
• The workflows must have versions: a new version should be created after each change of the workflow.
• The system must ensure that any service execution already in progress continues on the same workflow version as it began. New service executions must always start on the latest version of the workflow.
• The system must have the ability to monitor the workflow execution: a workflow of the service must be visual, and the current status of workflow execution must be visible.
• The system must support the management of workflow execution in cases of errors: terminate an instance or repeat an execution of some component.
• The type of workflow management module used in the system—whether custom-made or an external tool/product—must be specified.
• The system must have the ability to handle errors. Administrators can view errors and choose to resume or terminate the process.
• The Workflow Management module must cover functionality to monitor the runtime execution of processes.
• The Workflow Management module must have the ability to handle human tasks and automated tasks.
• The Workflow Management module must have User task management with task assignment and reassignment features.
• The Workflow Management module must support DMN (Decision Model and Notation) for defining business rules. DMN diagrams should have versioning.
• The Workflow Management module must include workflow execution monitoring capabilities: the administrator should be able to select a process, visually track its current execution status, and view process parameters for each instance of the process.
• The administrator should be able to deploy a new version of process, to view it, download  or delete deployed version
• The administrator should be able to terminate execution of any process instance.
• The administrator should be able to view process execution errors for the process instance: errors should be shown visually on the diagram and in the list with clear error explanation.
• The administrator should be able to change process parameters and re-execute the element chosen on the diagram.

10  Guidelines for BI and Reporting

The purpose of these guidelines is to establish a robust reporting and analytics framework that empowers internal users and managers to access, analyze, and act on critical data within the system.

• The system must have the reporting module accessible for internal users.
• The system must have up to 4 reports of register data.
• The system must have up to 5 statistical reports of register data.
• The system must have up to 3 reports of system workload and usage.
• The system must have up to 3 financial reports of payment transactions.
• The system must have up to 4 graphical reports.
• Content of reports will be provided by the institution.
• The user must be able to indicate various filtering and sorting criteria for reports.
• The user must be able to indicate the format of the report: pdf, xls/csv, doc.
• The institution must have the capability to add or modify reports within the system without requiring a system re-deployment later.
• The tools used for reporting services should be clearly indicated.
• The system must have a graphical dashboard for managers to see the workload of the system and measures of the register.
• The system must support ad-hoc querying for live data analysis.

11  Guidelines for User Management

The purpose of these guidelines is to establish a secure, organized, and flexible user management framework within the system.

User management

• The system must support several types of users: public users, business representatives, register officers, users for other governmental officers with different roles.
• The system must allow the administrator to access a comprehensive list of all users, perform searches for specific users, and view detailed information for each individual user.
• The administrator must be able to create a user, edit data, deactivate / activate it.
• The administrator must be able to assign or remove different roles for the users.
• The user should be able to change some limited details of his/her profile.
• The system must have ability for public users to create users for themselves. The system must send a link for email confirmation. The system must ask to enter captcha code within the user details form.
• The system must have SSO capabilities.
• The users must be authenticated with username and password.
• The system must support two-factor authentication via Google Authenticator for users who have chosen to use such an additional method.
• The system must ask to change password every six months.
• The system must temporarily lock a user after 3 unsuccessful tries to login.
• The system must have strong password creation rules.
• The system must audit all logins, attempts to login and user data changes.
• The system must be role-based: users with different roles should see and should be able to perform different functionality in the system. One user can have one or several roles.

Identity verification

• The external user must have a security group assigned: simple, medium.
• The user should be considered of simple security group if he/she is not verified by the identity verifiers.
• The user should be considered of the medium security group if he/she is verified by the identity verifiers.
• The system must provide functionality for individual identity verification, allowing users to initiate an online verification request. This process should enable users to upload a document file and capture a live photo of themselves for verification purposes.
• The identity verifier must be able to view all applications received for identity verification, search for the application, view details of the particular application.
• The identity verifier must be able to get tasks for identity verification, approve it, reject it or ask for supplement.
• The users with simple security groups must have limited functionality in the system.

Representation management

• The system must support the representative management mechanism. The external user should be able to work on behalf of the chosen represented entity.
• The representative’s management must be performed by dedicated users of the entity or by the administrator.
• The system must support the ability to create a new representative for an entity and to revoke an existing representation when needed.
• The system must have a list of all representatives with a ability to search for them and to view details of the chosen one. The entity should be able to see only its own representatives.
• Only representatives of the entity can perform actions on behalf of the entity.
• Only representatives with special rights must be able to manage representatives of the entity.

Account management

• The system must support the account management mechanism. Accounts can be created for an individual, an entity or an institution.
• The user must be able to work on behalf of the chosen account.

12  Guidelines for Integrations

The purpose of these integration guidelines is to establish a clear framework for connecting the system with external services.

• The system must support various integration points for different purposes.
• The system must provide capabilities for integration monitoring, including the ability to view and track integration statuses and performance metrics.
• The system must have access management for each integration point: external systems can access APIs of the system via configured access keys.
• The system must be integrated [required integrations]:

1.       with a payment gateway for e-payments.

2.       with the Population register for individual data verification.

3.       with digital signature and digital seal provider for e-signing of the certificate / application.

4.       with the SMS gateway for SMS sending.

5.       with the email gateway for email sending.

6.       with a financial system for transferring data of performed payment transactions.

• The system must provide standardized API Endpoint that adheres to OpenAPI 3.1.0 specification:

1.       The system must provide a standardized RESTful API endpoint for accessing register record data.

2.       The API endpoint must support HTTP methods such as GET, POST, PUT, and DELETE.

3.       The API must use standard HTTP status codes to indicate the success or failure of requests.

• Standardized API endpoint must enable data retrieval by registration number:

1. The system must allow external systems to retrieve specific register records based on their unique registration numbers.

2. The API endpoint must accept the registration number as a query parameter.

3. The system must return the requested record data in a structured format, such as JSON.

• Standardized API endpoint must enable data retrieval by time period:

1.         The system must allow external systems to retrieve a list of register records that have been added or modified within a specified time period.

2.         The API endpoint must accept start and end date parameters.

3.         The system must return a list of records that meet the specified criteria.

• Standardized API endpoint must enable classifier data retrieval:

1.       The system must allow external systems to retrieve information about the classifiers used within register data.

2.       The API endpoint must accept a classifier name or identifier as a query parameter.

3.       The system must return detailed information about the classifier, including its attributes, values, and relationships to other classifiers.

Standardized API endpoint must enable documents of the register record data retrieval:

4.       The system must allow external systems to retrieve information about the documents used within register data.

5.       The API endpoint must accept a registration number as a query parameter.

6.         The system must return a list of files.

• Data Format

1. The system must return data in a standardized format, such as JSON, to ensure interoperability with external systems.

2. The data format must include clear documentation and examples to facilitate integration.

• A standardized API specification must be delivered.

13  Guidelines for Identity and Access Management

The purpose of these Identity and Access Management (IAM) guidelines is to establish a secure, efficient, and user-friendly framework for managing user identities, permissions, and access within the system.

• The Identity and Access Management (IAM) solution must be an integral part of the system, providing comprehensive management of user authentication, authorization, and access control
• The system must support multi-factor authentication to enhance security.
• The system must support multiple authentication methods (password, OTP, etc.)
• The system must have role-based access control to manage user permissions based on roles.
• The system must have support of attribute-based access control for more granular access management.
• The system must have the ability to define, assign, and manage permissions for users and roles.
• The system should enable self-service account registration.
• Users must have the ability for self-service password reset functionality to reduce administrative burden.
• Users must have the ability to manage their own profile information within defined limits.
• The system should have the ability to create processing users and assign roles to them.
• The system must support audit logging to track user activities and administrative actions. Additionally, it must have the capability to integrate with monitoring tools (e.g., Prometheus, Grafana) to provide real-time insights into system performance and activity.
• The system should have the ability to implement session timeout and idle timeout policies to enhance security
• The system must provide real-time session monitoring and control to manage active user sessions.
• Allow administrators to terminate sessions or force logout users as needed.
• The system should support standard authentication/authorization frameworks and protocols: such as OAuth, OpenID and SAML.

14  Guidelines for Non-functional Requirements and Quality Attributes

14.1   Availability

System software must be available not less than:

14.2   Maintainability

• System must be based on a multi-tier architecture (often referred to as n-tier architecture) that provides a model for developers to create a flexible and reusable application. Breaking up an application into tiers, ensures easier modifying or replacing any tier without affecting the other tiers.

14.3   Scalability

• The system must be designed to allow for the vertical scaling of individual components (e.g., servers, virtual machines) without causing any interruption to users or the system’s functionality. The system must implement mechanisms to ensure seamless transition during scaling operations
• The system must be designed to accommodate increasing workload by allowing for the horizontal scaling of system modules without causing any interruption to users or the system’s functionality. The system must utilize load balancers to distribute incoming requests evenly among the available modules, ensuring optimal performance and preventing bottlenecks.

14.4   Usability

• User interface common characteristics:

1.         Access to the system screen forms and reports shall be from the main menu with a hierarchical structure.

2.         Data input available using the keyboard and/or mouse.

3.         Data field values, which can be determined automatically (e.g., system date and time), shall be presented to the user by default.

4.         UTF-8 encoding.

5.         Navigation elements shall be highlighted and easily accessible.

6.         Information design shall be optimized not to overload the screen.

7.         Screen forms shall be self-explanatory (user friendly).

8.         The system shall provide context-sensitive, dynamic user help to assist users in navigating and using system user interface

9.         All columns of the lists must be sortable.

10.       Navigation shall correspond to user actions sequence.

11.       Responsive behavior – web application is designed to use fluid grids that switch to different layout, when screen size changes, i.e., for a smart phone data could be displayed as a list, but on desktop a list would be changed into a more convenient table representation, which might show more information and add additional features, such as sorting.

• The system should be compatible with few latest versions of web browsers: Microsoft Edge, Firefox, Google Chrome, Safari.

14.5   Guidelines for Data Entry

• Validation checks and cross checks should be used which will prevent spurious data to be entered.
• Data entry fields should be populated with data where applicable.

14.6   Guidelines for Audit Trail

• All actions performed in the system should be audited in DB: the system should save the user / system who performed the action and the timestamp (date and time) of it.
• The system should show attributes of the authenticated user at the top of the screen: first name and last name of the user.

14.7   Guidelines for Error Handling

• The user should get notifications if some data is entered incorrectly.
• The user should not be able to proceed with application submission/ data saving if data fields contain errors.
• The administrator should have means to monitor errors of the system.

14.8   Guidelines for Search

• The system should not discriminate between the upper- and lower-case characters entered in the search criteria fields.
• If the user enters a text fragment in the text format search criterion field, system should search for data according to the fragment of the corresponding data field in the database.
• The list of results of the search should be organized in pages. The user can choose to navigate to any page. The user can choose the quantity of records to be shown on the page.
• If a search criterion is a number or code, the user can enter a fragment.
• A total number of search results found should be shown at the end of the search results.
• If system doesn’t find any record, it should display a notification that no record was found.

14.9   Guidelines for Date and Time Presentation

• Date presentation on the screen: dd/mm/yyyy, e.g. 01/09/2015. Date presentation on printouts: dd-mm-yyyy, 01-01-2015
• For time 24 hours’ time presentation is used: Time presentation on the screen: HH:MM. Time presentation on printouts: HH:MM

14.10               Guidelines for Language

The system user interface must be available in two languages: English and [local language].

Language scope

14.11               Performance

Function Performance Guidelines

1.         Home Page : 1.5 seconds

2.         Static Content : 2 seconds

3.         Dynamic Content: 5 seconds

4.         Document Repository: 5 seconds

5.         Search Facilities: 3 seconds

Report: Up to 1 min

14.12               Licensing and Source Code Ownership

• Details of any system, software, client, or user licensing must be provided. The expectation is that the institution will receive a full site license covering everything needed to run the system in the country, with no user-based costing for either internal or external users.
• If the system is licensed, a perpetual usage license must be granted to the institution.
• The product licensing must not grant any rights to access or control the data within the system.
• The license must not limit the number of internal and external users, nor can it be limited in any other way which will prevent scaling the system to support more external users and larger data volumes.
• If any open-source software is required to ensure operation of the system, such software must have commercial support available.
• The Business registration solution can rely on 3rd party standard software and frameworks, given that the following requirements are met:

•   If any licensed standard software is required to ensure operation of the system in compliance with the architecture and performance requirements, the cost of licenses, including not less than 3 years of support and maintenance shall be included in the financial proposal, and such licenses shall be clearly indicated in the technical proposal.

•   The licenses for standard software must be sized to support 3 institutions’ environments: Testing, Pre-production, Production.

• The complete source code of the product must be provided to the institution.
• The source code must be delivered in a usable and well-documented format.
• There must be full freedom and rights to modify, customize, and extend the product without any imposed restrictions.
• There should be no dependencies on a specific vendor or product version.
• Full ownership of all data generated or processed by the product must be retained.
• The product licensing must not impose any restrictions on the ability to use, modify, or distribute the product or data.
• There must be the flexibility to choose the deployment environment and infrastructure for the product.

15  Guidelines for Security

• The system must use Privacy by Design principles, ensuring that no person or system is trusted
• The system must comply fully with the institution’s ICT Policy and Application Security Standards, incorporating standard security features to ensure data confidentiality and integrity. It should be ensured that the solution is secure and will not compromise the security of other integrated systems.
• The solution must implement secure coding practices, vulnerability scanning and regular security audits
• Functions accessible to non-authenticated users must have DDOS protection features, e.g. CAPTCHA.
• The password must ensure strong password characteristics.
• The system must not store any passwords in plain text nor in an encrypted form which allows to decrypt the password value.
• The system should be fully compliant with OWASP guidelines and requirements
• The system must implement role-based, resource-based and scope based access control mechanisms,  to manage security and data access, ensuring that only authorized users can access protected data according to their assigned security levels.
• The system must provide a standard REST-based API to allow information extraction from the register, accessible only to registered external systems via a VPN connection and secured over TLS.
• Dedicated Credentials should be used for accessing standard APIs.
• The system must support connections using TLS1.3 and should reject any attempts to connect using TLS protocols deemed as End of Life (EOL): TLS1.1 and earlier
• TLS Encryption and digital signature algorithms should be constantly reviewed and updated according to current best practices.
• The system must support Encryption at Rest to safely store the system data
• Authentication activities, privilege changes, administrative actions and access to sensitive data must be logged
• The system should store logs securely, follow retention policies and be encrypted so that they won’t disclose any sensitive information
• The system must be fortified with Firewalls (both network and Web Application Firewall (WAF))

16  Guidelines for Implementing Register Projects

Project duration:

• Project implementation should not exceed 12 months.
• Post-implementation support should start from the day the software is commissioned to the institution’s Production environment and will last for 12 [or specify otherwise] months. Post-implementation support should cover:
  • Warranty for bug fixing.
• Technical support of up to 100 hours per month, covering the implementation of change requests for new functionalities not included in the original solution and the execution of ad-hoc tasks as needed.

Project Life Cycle:

A plan-driven project life cycle shall be used to deliver project results. The following phases shall be completed:

1.         Project mobilization: Minimum two weeks (home base) for desk analysis, informing stakeholders, establishing project teams and procedures.

2.         Inception: Phase dedicated for requirements refinement, covering:

•          As-is and to-be workshops

•          Legacy system(s) review

•          Analysis of data to be migrated

•          Current infrastructure review

•          Decision regarding software hosting option

•          Software hosting options

•          Meeting 3rd parties that the solution will have to integrate with

•          Meeting key stakeholders

3.         Elaboration: Phase dedicated for establishment of solid requirements that shape software solution, covering:

•          Definition of user roles and access rights

•          Definition of workflows

•          Definition of data inputs and outputs

•          Decision regarding migration approach

•          Analysis of 3rd party APIs

4.         Construction: Phase dedicated to transform the requirements into a fully functional software system. Interim results should be planned to include user testing and feedback from key stakeholders. The phase will be covering:

•          Development of software solution

•          Testing software solution

•          Presenting interim results to key stakeholders

•          Development of User manuals

•          Preparation for Acceptance testing

•          Preparation for Training

•          Testing data migration solution

•          Installing infrastructure

•          Deploying software for Acceptance testing and Training

5.         Transition: Phase dedicated to seamlessly transition the developed solution to end users, covering:

•          Training

•          Acceptance testing

•          Resolving issues reported during Training and Acceptance testing

•          Production environment clean-up

•          Production migration

•          Production configuration

•          Final versions of all deliverables

•          Final Report

            Deliverables and milestones:

The project shall be signed off upon pre-defined milestones. Each milestone will correspond to an adequate group of deliverables. Interim payments shall be linked to each milestone.

Milestone 1: Requirements refinement

•          Inception Report

•          Project Implementation Plan

Milestone 2: Preparation for development

•          Software Specification

Milestone 3: Construction of Interim results 1

•          Software Interim Results 1

Milestone 4: Construction of Interim results 2

•          Software Interim Results 2

Milestone 5: Construction of Interim results 3

•          Software Interim Results 3

•          Acceptance Test Cases

•          Training Material

•          Training and Acceptance Test Program

•          Infrastructure Installation and Software Deployment Report

Milestone 6: Transition to user community

•          Training

•          Acceptance Test

•          User Manual

•          Administrator Manual

•          Software Final Version

•          Technical Support and Maintenance Manual

•          Final Report

17  Guidelines for Advisory Services in Register Project Implementation

These guidelines are intended to facilitate a smooth transition to electronic registration services, enhancing the legal, operational, and change management capacities necessary for successful project implementation.

Legal Advisory

• Focus on regulatory considerations specific to the introduction of electronic business registration services. This includes understanding local legislative requirements and ensuring alignment with regulatory standards.
• Review existing primary and secondary legislation and recommend any necessary legislative changes to facilitate the adoption of electronic registration. Recommendations should incorporate relevant international best practices to promote compliance and efficiency.
• Identify potential legal risks associated with the development and implementation of the business registration system, ensuring that all identified risks are addressed in the project’s risk management plan.

Operational Capacity Building

• Conduct a comprehensive review of business processes and operating procedures to identify necessary changes that will support the implementation of electronic business registration. This review should cover the roles and responsibilities of all internal and external stakeholders involved in these processes.
• Develop tailored training programs to address specific needs and objectives, equipping the registration agency with the knowledge and skills required for effective system use and maintenance.
• Facilitate regular consultation sessions with internal and external stakeholders to gather insights, recognize potential challenges, and develop strategies for overcoming these challenges.
• Perform a detailed needs assessment to pinpoint specific areas for capacity building, consulting with leadership and key stakeholders to ensure all identified needs are effectively addressed.

Change Management and Stakeholder Engagement

• Define the scope and impact of required changes, developing a structured change management plan. This plan should outline a clear methodology for managing stakeholder relationships, aligning leadership, and addressing potential resistance.
• Ensure ongoing support for ownership and leadership of the new digital solution within the organization, engaging internal stakeholders early and continuously to build support and facilitate successful implementation.
• Prepare a stakeholder engagement plan to guide activities for timely system launch and market readiness. This includes engaging with external stakeholders to guarantee the digital solution is fully prepared for use in line with the project timeline.

Download full document here

Download

Download full document here

Download

Download General Guidelines for Registries on the Unified Registers Platform Establishment

Download Full Document

Full Name *

Email Address *

Phone *

Company Name *

Your position *

Your Message *

By clicking Send Message, you agree to NRD Companies Privacy Policy.

Download

Thank you!

We have sent an email with a download link.