...
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 needsIl 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.
...
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:
...
Number
...
Requirement
...
Role
...
Requirement Description
...
Process Map
...
Priority
(High,Medium,Low)
...
Complexity (High,Medium,Low)
...
Types d'exigences
● Fonctionnel, c'est-à-dire ce que le système doit faire.
Exemple d'une exigence fonctionnelle de HAUT NIVEAU :
Numéro | Exigence | Rôle | Description du besoin | Plan du processus | Priorité ( Élevée, Moyenne, Faible ) | Complexité ( Elevée, Moyenne, Faible) | ||
Ajouter famille/groupe |
| |||||||
FR1.1 | Create a Family/Group | Enrolment Officer | The User is able to create a family/group by entering a list of relevant details on the formCréer une famille/un groupe | Agent d'inscription | L'utilisateur peut créer une famille/un groupe en saisissant une liste de détails pertinents dans le formulaire.
(See data dictionary section for the details displayed with respective formats.Voir la section sur le dictionnaire des données pour les détails affichés avec les formats respectifs) | I1. | High Élevée | High |
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
...
Élevée |
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:
● 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
...
● 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
Permissions
Enrolment Officer
Manager
Accountant
Clerk
Medical Officer
Scheme Administrator
IMIS Administrator
Claim Administrator
IR03 | Exigences détaillées du rapport | |
Catégorie du Rapport | Management Reports | |
Nom du Rapport | Les ventes de produits | |
Description du Rapport | Brève description du contenu du rapport Ce rapport contient la valeur des ventes de polices d'assurance réalisées par les agents de vente d'assurance/ agents d'inscription. | |
Objectif | Décrire l'objectif du rapport Le rapport donne un aperçu de l'état des activités de vente. Il montre, pour la période choisie, les volumes de ventes (encaissements financiers provenant des ventes), ce qui permet d'analyser les performances financières des différentes régions et districts. Chaque transaction financière liée aux ventes de polices est répertoriée dans ce rapport, ce qui peut être utilisé pour vérifier par recoupement les paiements reçus par le régime pour la période choisie. | |
Audience | Gestionnaire du système, comptable et agent d'inscription | |
Déclencheurs | Le comptable a besoin d'un rapport sur les ventes pour vérifier les paiements reçus par le bureau d'assurance. La direction exige des rapports sur les ventes de produits sur une base mensuelle ou ponctuelle. | |
Paramètres de saisie | L'utilisateur peut choisir de filtrer le rapport en utilisant les paramètres suivants : Options des paramètres Date du Sélecteur de date Date de fin Sélecteur de date Région Liste des régions District Liste des districts de la région sélectionnée Produit Liste des produits ou services
| |
Séquence de triage | Tri par défaut : Autres options de tri, par exemple, permettre à l'utilisateur de trier par n'importe quelle colonne. | |
En-têtes de rapport | Nom du rapport : Paramètres du rapport : | |
Contenu du rapport | Décrire les colonnes et les données attendues par colonne | |
Mise en page du rapport
| Ajoutez un exemple de ce à quoi ressemblera le rapport, avec des en-têtes de colonne et des données d'exemple / ajoutez une structure filaire. | |
Pied de page pour les rapports imprimés | Utilisateur (qui a exécuté le rapport) Nom du rapport - Ventes de produits Date de création - 9/12/2019 Date et heure d'impression (si imprimée) - 9/12/2019 12:15:28 PM Number of Nombre de pages - 1 of de 1 | |
Export | Allow user to export reports to .xls or Exportation | Permettre à l'utilisateur d'exporter les rapports au format .xls ou csv, PDF or ou 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 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.
Permissions | Agent d'inscription | Directeur | Comptable | Commis | Médecin-conseil | Administrateur du régime | Administrateur IMIS | Administrateur des demandes |
Ajouter famille/groupe | X | X |
|
|
|
| X |
|
Edit Family/GroupModifier la famille/groupe | X | X |
|
| X | X | X |
|
Delete FamilySupprimer Famille/GroupGroupe | X | X |
|
|
|
| X |
|
Add InsureesAjouter des assurés | X | X |
| X |
|
| X |
|
Edit InsureesModifier des assurés | X | X |
| X |
|
| X |
|
Delete InsureesSupprimer des assurés | X | X |
| X |
|
| X |
|
Add PoliciesAjouter des politiques | X | X | X | X |
| X | X |
|
Edit PoliciesModifier des politiques | X | X | X | X |
| X | X |
|
Delete PoliciesSupprimer des politiques | X | X | X | X |
| X | X |
|
Renew PoliciesRenouveler les | X | X | X | X |
| X | X | X |
Add ContributionsAjouter les cotisations |
| X | X |
|
| X | X | X |
Edit ContributionsModifier les cotisations |
| X | X |
|
| X | X | X |
Delete ContributionsSupprimer les cotisations |
| X | X |
|
| X | X | X |
Définir les exigences en matière de migration des données
...
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:
...
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 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
...
Field Name
...
Description
...
Entry Options
...
Data Type
(Numeric, text, date, alphanumeric, Y/N, Length of field)
...
Rules
...
Region
...
Region to be selected by user
...
Dropdown
...
Text(50)
...
Display a dropdown list of regions that the user will select
...
District
...
District to be selected by user
...
Dropdown
...
Test(50)
...
Display a dropdown list of districts only associated with the selected region for the user to select
...
Municipality
...
Municipality to be selected by user
...
Dropdown
...
Text(50)
...
Display a dropdown list of municipalities associated with the selected district for the user to select
...
Village
...
Village to be selected by user
...
Dropdown
...
Text(50)
...
Display a dropdown list of villages associated with the selected municipality for the user to select
...
Poverty Status
...
Poverty status of patient
...
Y/N
...
Y/N
...
...
Confirmation Type
...
...
Dropdown
...
Text(50)
...
...
Family/Group Type
...
...
Dropdown
...
Text(50)
...
...
Permanent Address Details
...
Address of patient
...
Free Text
...
Text(Unlimited)
...
...
Confirmation No.
...
...
Auto Generate
...
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
Nom du champ | Description | Options de saisie | Type de données (Numérique, texte, date, alphanumérique, O/N, longueur du champ) | Règles |
Région | Région to be selected by user | Liste déroulante | Texte(50) | Afficher une liste déroulante de régions que l'utilisateur sélectionnera |
District | District à sélectionner par l'utilisateur | Liste déroulante | Texte(50) | Afficher une liste déroulante des districts associés uniquement à la région sélectionnée afin que l'utilisateur puisse les sélectionner. |
Municipalité | Municipalité à sélectionner par l'utilisateur | Liste déroulante | Texte(50) | Afficher une liste déroulante des municipalités associées au district sélectionné pour que l'utilisateur puisse les sélectionner. |
Village | Village à sélectionner par l'utilisateur | Liste déroulante | Texte(50) | Afficher une liste déroulante des villages associés à la municipalité sélectionnée pour que l'utilisateur puisse la sélectionner. |
État de pauvreté | État de pauvreté du patient | O/N | O/N |
|
Type de Confirmation |
| Liste déroulante | Texte(50) |
|
Type de Famille/Groupe |
| Liste déroulante | Texte(50) |
|
Détails de l'adresse permanente | Adresse du patient | Texte gratuit | Texte(illimité) |
|
N° de confirmation | Génération automatique | Numérique(11) |
|
Trouver le système qui vous convient
...