Définir les exigences des utilisateurs de votre système numérique

Définir les besoins de votre entreprise en consultant les principales parties prenantes est une étape importante pour garantir que la solution technologique répondra à ces besoins. Il est essentiel de documenter et d'obtenir un consensus sur les besoins prioritaires. Ces exigences seront utilisées pour guider le processus d'évaluation des solutions possibles et éclairer la décision d'"adopter, adapter ou développer".

Les exigences opérationnelles sont des descriptions de haut niveau de ce dont le secteur du financement de la santé a besoin en termes de solution numérique et d'informations afin de répondre aux besoins des bénéficiaires et de réaliser son mandat.

Les exigences des utilisateurs sont des déclarations clairement formulées sur ce qu'un système numérique doit être capable de faire afin de satisfaire les besoins des utilisateurs et des bénéficiaires. Ils doivent être dérivés des exigences opérationnelles. Elles doivent être définies en deux catégories claires, fonctionnelles et non fonctionnelles. Les exigences fonctionnelles décrivent le comportement et les fonctions requises du système. Les exigences non fonctionnelles décrivent les critères spécifiques qui peuvent être utilisés pour juger le fonctionnement d'un système, par exemple la performance, la sécurité, la disponibilité, ainsi que des considérations supplémentaires telles que les exigences de migration des données et les exigences d'intégration ou d'interopérabilité avec d'autres systèmes.

Modélisation des processus commerciaux

Pour chaque processus commercial principal, il est utile de documenter le processus en utilisant une technique standard de modélisation des processus commerciaux. Cela peut aider à identifier les problèmes et les lacunes du processus actuel afin de déterminer où une solution numérisée peut apporter le plus de valeur ajoutée.

●    Utilisez un outil de modélisation des processus commerciaux et le guide de modélisation des processus commerciaux pour développer un modèle visuel du flux de vos processus.

●    (Des outils gratuits de modélisation des processus commerciaux peuvent être téléchargés, par exemple Bizagi. https://www.bizagi.com/ ).

●   Pour chacun des processus commerciaux modélisés, documentez les informations supplémentaires pour chaque étape, comme indiqué dans le Guide de modélisation des processus commerciaux. [document supplémentaire à télécharger]

Directives et modèles pour le recueil des exigences

There are a number of tools and techniques that can be used to gather and document this information. Remember that these artifacts are a means of communicating to different stakeholders i.e. end users, project sponsors, system architects, developers, testers, monitoring and evaluation experts, etc. 

●        Keep them simple

●        Keep them consistent

●        Make sure terminology is defined, simple and consistently used throughout; for example: Provider, Practitioner, HCW, Clinician may all refer to the same type of user - choose one and stick to it

Correct notation, such as Business Process Modelling Notation (BPMN) is important if you are communicating with peers who already understand it but for general audiences the aim is a clear and unambiguous shared understanding of what you are trying to build and the format is less important.

Gathering Requirements

The most important factor is to have access to the right people. Be sure to include the people who will be working with the system on a day to day basis, not just the senior management team or decision-makers.  They should include data capturers, claims processing clerks, system administrators, etc. 

There are various ways to elicit and define the requirements, including:

●        Brainstorming

●        JAD (Joint Application Design) workshops

●        Small focus groups

●        One on one interviews

●        Questionnaires

●        Observations

●        Document analysis

Be aware of the power dynamics in the room during large group discussions

Ideally you need to  be able to speak to the actual end users of the proposed solution, preferably one on one or in small groups without supervisors/manager present

Don’t over-promise : make it clear you are there to understand what is needed and that many other factors influence the final scope

Ensure you have participants’ consent to record sessions or to take photographs

Try to have one or more scribes to assist with taking notes

The Requirements Template can be used as a simple tool to define high-level functional requirements and non-functional requirements.

User Personas

A user persona is a representative for each type of user that may interact with the system, such as a beneficiary, a claims processor or a manager. 

The User Personas Template­ can be used to identify key characteristics of the user and describing them in such a way allows a better understanding of their wants, needs and common frustrations so that these can be addressed effectively.  Using input from user research at the focal point of design decisions ensures that the system works in such a way that fulfils user needs.

Template link: https://docs.google.com/document/d/1QDmdUpl1-WmBLxuuphXI7y8hz1-GDFB2SkVFuAqxvZw/edit

 Types of Requirements

●        Functional i.e. what must the system do

Example of a HIGH-LEVEL functional requirement:

A good practice would be to document the functional requirements in a user story.

User Stories

For User Stories, it is useful to follow a Behaviour Driven Design approach eg:

AS A                                     <specific user/persona/role>

I WANT                                <desired feature/issue that needs to be solved>

SO THAT                                       <benefit from implementing feature>

The story should include, where appropriate:

○        Acceptance criteria - these form the basis for the test cases

○        UX mock-ups / UI designs

○        Logging and auditing

○        Performance criteria

○        How to demo

AS AN                                  Enrolment Officer

I WANT                               to be able to create a family/group for a patient/member

SO THAT                                       All relevant information pertaining to the family can be                                               captured, such as;

●     Region

●     District

●     Municipality

●     Village

●     Poverty Status

●     Confirmation Type

●     Family/Group Type

●     Permanent Address Type

●     Insurance Number

●     Other Names

●     Last Name

●     Birth Date

●     Gender etc…

And once this has been captured, Insurees, Policies & Contributions can be assigned to the family/group created.

Define the Information Requirements

Before being able to define what digital  systems are required to support the health insurance business need, it is necessary to understand what information requirements exist i.e. what data is collected, stored and put to use within the existing system. 

The type of questions to consider are:

●     What type of information is required, at the operational , management and reporting levels?

●     Who owns the data?

●     Where will master data be stored?

●     How and where will each type of data be created, stored, transported and reported?

●     What data transformation is required to support the information exchange between solution components?

Informational requirements refers to reports, data visualisation, dashboards. These requirements are often gathered from stakeholders rather than users.  It is also more demanding and difficult for the analyst to obtain these requirements accurately, because it invariably requires much more in depth business knowledge.   Reports may include, but not limited to:

               1.1.        Operational reports e.g. Primary Operational Indicators-claims

               1.2.        Management reports or dashboards e.g. Product Sales

               1.3.        Exception reports e.g. Rejected Photos

               1.4.        Control reports e.g. Matching Funds

               1.5.        System Monitoring e.g. User activity Reports, Status of Registers

EXAMPLE USING TEMPLATE

IR03	Detailed Report Requirements
Report Category	Management Reports
Report Name	Product Sales
Report Description	Brief descriptions of the contents of the report This report contains the value of sales of insurance policies by insurance sales agents/ enrollment officers.
Purpose	Describe the purpose of the report The report  gives an overview of the state of the sales activities. It shows within the chosen time frame the sales volumes (financial collections from sales) which helps analyze the financial performance of different regions and districts. Each financial transaction related to policy sales are listed in this report which can be used to cross verify payments received by the scheme for the chosen time period.
Audience	Scheme Manager, Accountant and Enrolment Officer
Triggers	Accountant requires sales report to cross verify payments received in the insurance office Management required Product Sales reports on a monthly or ad hoc basis.
Input parameters	The user can select to filter the report using the following Parameters: Parameter Options Date From Date picker Date To Date picker Region List of regions District List of districts in the selected region Product List of products or services
Sort Sequence	Default sort: Other sort options e.g. allow the user to sort by any of the columns
Report Headers	Report Name: Report Parameters:
Report Content	Describe the columns and expected data per column
Report layout	Add an example of what the report will look like with column headers and example data / add a wireframe
Report Footer for printed reports	User (that ran the report) Report Name - Product Sales Date Created - 9/12/2019 Date and Time Printed (if printed) - 9/12/2019 12:15:28 PM Number of pages - 1 of 1
Export	Allow user to export reports to .xls or csv, PDF or Word

Define the Non-Functional Requirements

Define the full list of non-functional requirements considering required operational standards and non-functional standards provided below. Defining a comprehensive list of non-functional requirements mitigates the risk of the system not performing as expected, allowing you to define performance standards.These may include:-

Performance related observable requirements -These requirements allow you to define how you want and need the system to perform within defined parameters to ensure high quality performance, minimise down-time and fulfil user needs.

●     Reliability

●     Availability

●     Usability

●     Security

Requirements that support system evolution over time: These requirements allow you to define ways in which the system can be adapted and evolve as the number of users and amount of data in the system increases and requirements further develop.

●     Scalability

●     Adaptability

●     Maintainability

●     Extensibility 

Example of a Non-Functional Requirement for Performance:
NFR01  Allow users to find features within 3 clicks or less.

Example of a Security Matrix for a Non-functional Requirement that defines which users will be able to perform certain functions within the system.

Définir les exigences en matière de migration des données

● Quelles sont les données qui devront être migrées vers le nouveau système ?

● Quel niveau de nettoyage et de transformation des données est nécessaire pour garantir que les données répondent aux exigences et aux contraintes du nouveau système ?

Exemple d'exigences transitoires pour la migration des données :
NFR03          Le système doit offrir une fonctionnalité de migration des données par le biais de la numérisation des dossiers papier existants.
NFR04           en offrant la possibilité de rétablir les enregistrements papier existants par la saisie manuelle des données et de les marquer comme des enregistrements historiques.  Le système doit pouvoir saisir les numéros d'assurance existants dans les dossiers historiques de naissance, de décès, de mariage et de divorce qui sont transférés des dossiers papier et électroniques existants.

Define Integration and Interoperability requirements

●     What existing systems does the new system need to integrate with?

●     What data needs to be exchanged?

Example Integration / Interoperability requirements:

NFR05           The system must have the ability to securely interconnect with the central vital events registry, NIA, master person index etc. via a secure web-based interface or mobile application. The system must ensure that incoming data input is validated, evaluated for expected size, format and type before acceptance.    
NFR06           The system must use open standards to promote interoperability.
NFR07           The system must support standard messaging protocols.     
NFR08           The system must provide real-time response to mobile transactions submitted to the central database.      
NFR09           The system must be able to interface with open source or existing third party reporting tools.  
NFR10           The system must provide the capability for integration with other systems through an API.   

Develop a Data Dictionary

The Data Dictionary is a centralised repository of information about data such as meaning, relationships to other data, origin, usage, and format. A Data Dictionary is a set of information describing the contents, format and structure of a database and the relationship between its elements used to control access to and manipulation of the database.

Example of a data dictionary using the template

Trouver le système qui vous convient

Évaluer les solutions potentielles

1. Décidez d'abord le type de critères que vous allez utiliser pour évaluer les solutions possibles.  Par exemple, certains critères courants sont :

   1. Viabilité financière - tenir compte des coûts initiaux et à long terme

   2. Facilité de mise en œuvre

   3. Facilité de maintenance et de soutien

   4. Exactitude des données

   5. Actualité et pertinence des données

   6. Fiabilité du système

   7. Performance du système

   8. Sécurité du système

   9. Récupérabilité du système

Veillez à ce que les parties prenantes principales qui utiliseront et géreront le système sur une base opérationnelle soient incluses dans ce processus d'évaluation.

1. Hiérarchisez ou pesez ces critères car il est très peu probable qu'une solution réponde entièrement à tous les critères et des choix devront être faits en fonction de ceux qui sont les plus importants.

2. Examinez les solutions possibles et évaluez-les en fonction de leur degré de conformité à vos critères.

3. Demandez-vous si vous voulez développer et entretenir le système en interne ou si vous devez vous procurer le système auprès d'un fournisseur externe. Voici le type d'options que vous pouvez envisager :