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.

Open

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

Il existe un certain nombre d'outils et de techniques qui peuvent être utilisés pour recueillir et documenter ces informations. N'oubliez pas que ces artefacts sont un moyen de communiquer avec les différentes parties prenantes, à savoir les utilisateurs finaux, les commanditaires du projet, les architectes du système, les développeurs, les testeurs, les experts en suivi et évaluation, etc.

● Faites en sorte qu'ils soient simples.

● Veillez à ce qu'ils soient cohérents.

● Assurez-vous que la terminologie est définie, simple et utilisée de manière cohérente tout au long du document ; par exemple : Prestataire, Praticien, HCW, Clinicien peuvent tous désigner le même type d'utilisateur - choisissez-en un et tenez-vous-en à celui-ci.

Une notation correcte, telle que la Notation de Modélisation des Processus Commerciaux (NMPC), est importante si vous communiquez avec des personnes qui la comprennent déjà, mais pour le grand public, l'objectif est de parvenir à une compréhension commune claire et sans ambiguïté de ce que vous essayez de construire, et le format est moins important.

Recueil des exigences

Le facteur le plus important est d'avoir accès aux bonnes personnes. Veillez à inclure les personnes qui travailleront avec le système au quotidien, et pas seulement l'équipe de direction ou les décideurs.  Il doit s'agir de personnes chargées de la saisie des données, de commis au traitement des demandes de remboursement, d'administrateurs du système, etc.

Il existe plusieurs façons d'obtenir et de définir les exigences, notamment :

● Remue-méninges

● Des ateliers JAD (conception d'applications conjointes).

● Des petits groupes de discussion

● Des entretiens individuels

● Des questionnaires

● Des observations

● Analyse de documents

Soyez conscient de la dynamique de pouvoir dans la salle pendant les discussions en grand groupe.

Idéalement, vous devez être en mesure de parler aux utilisateurs finaux de la solution proposée, de préférence en tête-à-tête ou en petits groupes sans la présence de superviseurs ou de gestionnaires.

Ne faites pas de promesses exagérées : indiquez clairement que vous êtes là pour comprendre ce qui est nécessaire et que de nombreux autres facteurs influencent la portée finale.

Veillez à obtenir le consentement des participants pour enregistrer les sessions ou prendre des photos.

Essayez d'avoir un ou plusieurs scribes pour vous aider à prendre des notes.

Le modèle d'exigences peut être utilisé comme un outil simple pour définir des exigences fonctionnelles de haut niveau et des exigences non fonctionnelles.

Personas d'utilisateurs

Un persona utilisateur est un représentant de chaque type d'utilisateur susceptible d'interagir avec le système, tel qu'un bénéficiaire, un responsable du traitement des demandes de remboursement ou un gestionnaire.

Le modèle de personnalité de l'utilisateur peut être utilisé pour identifier les caractéristiques clés de l'utilisateur et les décrire de manière à mieux comprendre ses désirs, ses besoins et ses frustrations communes afin de pouvoir y répondre efficacement.  L'utilisation des résultats de la recherche sur l'utilisateur comme point central des décisions de conception garantit que le système fonctionne de manière à répondre aux besoins des utilisateurs.

Open

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

Types d'exigences

●       Fonctionnel, c'est-à-dire ce que le système doit faire.

Exemple d'une exigence fonctionnelle de HAUT NIVEAU :

Une bonne pratique serait de documenter les exigences fonctionnelles dans une histoire d'utilisateur.

Histoires d'utilisateurs

Pour les histoires d'utilisateurs, il est utile de suivre une approche de conception axée sur le comportement, par exemple :

EN TANT QUE                    <utilisateur spécifique/persona/rôle>

JE VEUX                          <fonctionnalité souhaitée/problème qui doit être résolu>

POUR QUE                          <bénéfice de la mise en œuvre de la fonctionnalité>

L'histoire doit inclure, le cas échéant :

○ Critères d'acceptation - ils constituent la base des cas de test.

○ Maquettes UX / conceptions UI

○ Logging et audit

○ Critères de performance

○ Comment faire une démonstration

EN TANT QUE                          Agent d'inscription

JE VEUX                                   pouvoir créer une famille/groupe pour un patient/membre

POUR QUE                             Toutes les informations pertinentes relatives à la famille peuvent être saisies, comme par exemple ;

● Région

● District

● Municipalité

● Village

● État de pauvreté

● Type de confirmation

● Type de famille/groupe

● Type d'adresse permanente

● Numéro d'assurance

● Autres noms

● Nom de famille

● Date de naissance

● Sexe etc...

Une fois ces données saisies, les assurés, les polices et les cotisations peuvent être affectés à la famille ou au groupe créé.

Définir les exigences d'information

Avant de pouvoir définir les systèmes numériques requis pour répondre aux besoins de l'assurance maladie, il est nécessaire de comprendre les besoins d'information existants, c'est-à-dire les données collectées, stockées et utilisées dans le système existant.

The type of questions to consider are:

● Quel type d'informations est requis, aux niveaux opérationnel , de la gestion et du reporting ?

● À qui appartiennent les données ?

● Où les données de base seront-elles stockées ?

● Comment et où chaque type de données sera-t-il créé, stocké, transporté et rapporté ?

● Quelle transformation des données est nécessaire pour prendre en charge l'échange d'informations entre les composants de la solution ?

Les exigences informationnelles concernent les rapports, la visualisation des données, les tableaux de bord. Ces exigences sont souvent recueillies auprès des parties prenantes plutôt que des utilisateurs.  Il est également plus exigeant et difficile pour l'analyste d'obtenir ces exigences avec précision, car elles nécessitent invariablement une connaissance beaucoup plus approfondie du business.  

Les rapports peuvent inclure, sans s'y limiter, les éléments suivants :

            1.1.        Rapports opérationnels, par exemple les indicateurs opérationnels primaires et les revendications.

1.2.        Rapports ou tableaux de bord de gestion, par exemple, les ventes de produits.

1.3.        Rapports d'exception (ex. : photos rejetées)

1.4.        Rapports de contrôle, par exemple sur les fonds de contrepartie

1.5.        Surveillance du système, par exemple, rapports d'activité des utilisateurs, état des registres.

EXEMPLE UTILISANT LE MODÈLE

Définir les exigences non fonctionnelles

Définissez la liste complète des exigences non fonctionnelles en tenant compte des normes opérationnelles requises et des normes non fonctionnelles fournies ci-dessous. La définition d'une liste complète d'exigences non fonctionnelles atténue le risque que le système ne fonctionne pas comme prévu, ce qui vous permet de définir des normes de performance.Celles-ci peuvent inclure:-

Exigences observables liées à la performance - Ces exigences vous permettent de définir comment vous voulez et avez besoin que le système fonctionne dans des paramètres définis pour garantir une performance de haute qualité, minimiser les temps d'arrêt et répondre aux besoins des utilisateurs.

● La fiabilité

● la disponibilité

● La facilité d'utilisation

● la sécurité

Des exigences qui soutiennent l'évolution du système dans le temps : Ces exigences vous permettent de définir les moyens par lesquels le système peut être adapté et évoluer au fur et à mesure que le nombre d'utilisateurs et la quantité de données dans le système augmentent et que les exigences évoluent.

● L'évolutivité

● L'adaptabilité

● La maintenabilité

● L'extensibilité

Exemple d'une exigence non fonctionnelle de performance :
NFR01  Permettre aux utilisateurs de trouver des fonctionnalités en 3 clics ou moins.

Exemple d'une matrice de sécurité pour une exigence non fonctionnelle qui définit quels utilisateurs seront en mesure d'exécuter certaines fonctions dans le système.

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.

Définir les exigences d'intégration et d'interopérabilité

● Avec quels systèmes existants le nouveau système doit-il s'intégrer ?

● Quelles sont les données qui doivent être échangées ?

Exemple d'exigences d'intégration/interopérabilité :

NFR05           Le système doit pouvoir s'interconnecter de manière sécurisée avec le registre central de l'état civil, le NIA, master person index etc. via une interface web sécurisée ou une application mobile. Le système doit garantir que les données entrantes sont validées, évaluées en fonction de leur taille, de leur format et de leur type avant d'être acceptées.
NFR06           Le système doit utiliser des normes ouvertes pour promouvoir l'interopérabilité.
NFR07           Le système doit supporter des protocoles de messagerie standard.    
NFR08           Le système doit fournir une réponse en temps réel aux transactions mobiles soumises à la base de données centrale.
NFR09           Le système doit être capable de s'interfacer avec des outils de reporting open source ou tiers existants. 
NFR10          Le système doit permettre l'intégration avec d'autres systèmes par le biais d'une API.   

Développer un dictionnaire de données

Le dictionnaire de données est un dépôt centralisé d'informations sur les données telles que leur signification, leurs relations avec d'autres données, leur origine, leur utilisation et leur format. Un dictionnaire de données est un ensemble d'informations décrivant le contenu, le format et la structure d'une base de données et les relations entre ses éléments, utilisé pour contrôler l'accès à la base de données et sa manipulation.

Exemple d'un dictionnaire de données utilisant le modèle

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 :