Présentation

Les exigences du système doivent être clairement décrites afin que ce système soit capable de satisfaire aux besoins et aux demandes des parties prenantes, et elles sont dérivées des besoins de l’entreprise et les besoins des utilisateurs, selon la figure ci-dessous sur la “Hiérarchie des Exigences “.Elles devront être définies en deux catégories distinctes, fonctionnelles et non fonctionnelles. Les exigences fonctionnelles décrivent le comportement et les fonctions du système requis. Les exigences non fonctionnelles décrivent des critères spécifiques qui peuvent être utilisés pour juger l’exploitation d’un système, comme par exemple la performance, la sécurité et la disponibilité. 

Analysis and Design 8_Requirements HIerarchy_French

Hiérarchie des exigences

Étapes:

Les étapes: L’architecture du système cible décrit l’état final du système souhaité, mais la mise en œuvre de toutes les fonctionnalités à la fois dans une version est susceptible d’être ingérable et de ne pas livrer aux attentes des parties prenantes. Selon l’écart entre les capacités actuelles et l’état final souhaité, vous aurez besoin de définir la portée de chaque version en termes de fonctions de l’entreprise et les processus de CRVS qui doivent être soutenue, en considérant ce qui est réaliste et rendra des resultats rapide.

1

Le documenter une feuille de route de mise en œuvre de haut niveau qui définit la portée de tous les rejets et leur calendrier de mise en œuvre pour réaliser les processus cible CRVS et architecture système cible. Cette feuille de route devrait montrer la mis en œuvre au fil du temps en utilisant une approche modulaire et progressive, selon le chiffre indicatif ci-dessous.

Pour chaque version, suivez les étapes ci-dessous:

Implementation-Roadmap

Principes pour définir la portée de lancement

  • Assurer que les processus cibles CRVS et de l’architecture du système sont confirmés avant de définir le champ d’application de la première version
  • Modularité: soutenir une fonction ou un processus d’affaires à la fois (par exemple, l’enregistrement des naissances, puis l’enregistrement des décès)
  • Le gradualisme: fournir des niveaux étagés de soutien pour les fonctions d’affaires, avec les lancements les plus modeste d’abord de façon à acquérir des compétences et de la confiance dans le système
  • Envisager une version initiale pour numériser les processus inchangés pour minimiser les perturbations de l’utilisateur
  • Les lancements initiaux doivent fournir des priorités d’affaires afin que les résultats peuvent être vus au début, pour promouvoir des achats et de l’investissement
  • Les lancements devraient être planifiées en fonction de l’infrastructure technique et la législation existante, sans attendre des améliorations et des changements à long terme
  • Maintenir le processus petit et simple!
  • Définir la portée des lancements est essentielle à la réussite du projet et nécessite une expérience significative – envisager l’utilisation de consultants externes.

Voir Techniques d’écart entre la conception et la realité pour plus de conseils.

2

Définir les cas d’utilisation du système en utilisant le modèle de cas d’utilisation de CRVS, sur la base des interactions utilisateur / système définis dans les processus cibles CRVS.

Comment écrire un bon cas d'utilisation

  • Identifier tous les différents utilisateurs du système et les rôles qu’ils jouent dans le système
  • Pour chaque rôle d’utilisateur, identifier tous les objectifs importants que les utilisateurs ont et que le système prendra en charge.
  • Créer un cas d’utilisation pour chaque objectif, en suivant le modèle de cas d’utilisation. Maintenir le même niveau de détail dans le cas d’utilisation. Let étapes dans les cas d’utilisation de niveau supérieur peuvent être considérées comme des objectifs pour le niveau inférieur (ie, plus détaillées) des cas d’utilisations. 
  • Structurer les cas d’utilisation, mais méfiez-vous de plus-structuration, car cela peut rendre les cas d’utilisation plus difficile à suivre.
  • Examiner et valider avec les utilisateurs
3

Documenter les détails de l’utilisateur pour tous les acteurs impliqués dans les cas d’utilisation du système pour identifier les principales caractéristiques de l’utilisateur en utilisant le modèle des détails de l’utilisateur. L’ utilisation des informations de la recherche de l’utilisateur au niveau du point focal des décisions de conception assure que le système fonctionne de telle manière qui satisfait les besoins de l’utilisateur.

4

Définir la liste complète des exigences fonctionnelles du système cible du CRVS en examinant l’architecture du système cible, les processus, les cas d’utilisation et les détails des d’utilisateurs afin d’identifier les fonctionnalités requises.

Exigences des meilleures pratiques

  • Les exigences doivent être documentées en tant que : “Le système doit …” ou “L’utilisateur doit être capable de … “
  • Veiller à ce que les exigences soient “SMART”:
    1. Spécifiques : Chaque exigence doit être précise pour éviter toute place à l’interprétation.
    2. Mesurables : Chaque exigence doit pouvoir être mesurée par rapport à un indicateur défini.
    3. Réalisables : Chaque exigence doit être réalisable selon des circonstances actuelles données.
    4. Réalistes : Chaque exigence doit être considérée comme réaliste compte tenu des ressources disponibles.
    5. Traçables : Chaque exigence doit être connectée directement à sa source et liée aux spécifications de la conception et aux tests détaillés .
  • Veiller à ce que les exigences sont centrés sur l’utilisateur.
  • Veiller à ce qu’une note (niveau d’importance) est ajoutée à chaque exigence.
  • Attribuer à chaque exigence une identification unique pour aider à la traçabilité
5

Définir la liste complète des exigences non-fonctionnelles du système cible du CRVS en tenant compte des normes opérationnelles requises et les normes non-fonctionnelles fournis.

Type d’exigences non-fonctionnelles Description

Exigences observables liée à la performance

Ces exigences permettent de définir la façon dont vous voulez et avez besoin du système pour effectuer des paramètres définis pour assurer une performance de haute qualité, et pour minimiser les temps d’arrêt ainsi comme pour répondre aux besoins des utilisateurs. Cela comprendra la fiabilité, la disponibilité, la convivialité et la sécurité.

Exigences qui soutiennent l’évolution du système au fil du temps

Ces exigences permettent de definir la façon dont le système peut être adapté et évoluer à mesure que le nombre d’utilisateurs et la quantité de données dans le système augmente et les exigences développer davantage. Celles-ci comprennent l’évolutivité, l’adaptabilité, la maintenabilité et l’extensibilité

Principales exigences non-fonctionnelles: la définition des normes de performance

Catégorie

Sous-catégorie

Exemples de norme

Technique

Réseau informatique

ISO/IEC/IEEE 8802
 

La construction du système de gestion de la qualité des logiciels

ISO 9001:2000
 

biométrie

ISO/IEC 19784/5
 

Numérisation (des dossiers papier historiques)

Département des Nations Unies de la gestion des archives et section de gestion des dossiers, standard, la tenue requise pour la numérisation

Communications électroniques et des transactions Loi de 2002 (loi n ° 25 de 2002) Afrique du Sud
 

Télécommunications

ISO ICS 33.040

Securité

Information et Gestion des Records

ISO 15489 
 

Gestion de la securité de l’information

ISO/IEC 27002
 

Gestion de la continuité d’affaire

ISO 223.1

Confidencialité

Protection des données

ISO/IEC 27001
 

Freedom of Information

PAIA Act No. 2, 2000, South Africa
 

Biométrie

ISO/IEC 19794/5

Audit

Information et Gestion des Records

ISO 15489 

International Standards for Non-Functional Requirements

6

Définir les besoins d’intégration de systèmes basés sur l’architecture système cible, en tenant compte des données utilisées et fournies par chaque application et en conformité avec le diagramme entité-relation. La définition d’une liste exhaustive des exigences non-fonctionnelles atténue le risque d’avoir un système qui ne fonctionne pas comme prévu, vous permettant de définir des normes de performance.

7

Définir les besoins de migration des données:

  • Quelles données devront-elle être migrées vers le nouveau système?
  • Quel est le niveau nécessaire de transformation et de nettoyage pour assurer que les données répondent aux exigences et aux contraintes du système cible?
8

Sélection d'une plate-forme pour le long terme

Lors de l’examen des propositions de fournisseurs potentiels, il est essentiel d’évaluer quel type de plate-forme est adaptée à votre contexte et qui va s’adapter et se développer à mesure que la solution évolue; cela aidera à prevenir les verrouillages de vendeurs et de technologies, un fait que de la Boîte D’Outil d’Identité Numérique de la Banque mondiale, Un guide pour les parties prenantes en Afrique (Juin 2014) identifie clairement comme un défi pour les systèmes nationaux d’identité ainsi. Le verrouillage de vendeur et de technologie est un facteur important car les systèmes d’identité ont tendance à développer un effet de réseau, par exemple ils augmentent en taille et en valeur en tant que plus de gens s’inscrivent et les programmes plus gouvernementales et non gouvernementales en dépendent. Cette dépendance – dont l’effet est souvent vu au moment du renouvellement du contrat, sous la forme d’avantage titulaire ou ancien système – il est plus difficile (ou plus onéreux) pour migrer d’un fournisseur ou d’une technologie à l’autre.

Déterminez si vous voulez définir quelle type de plate-forme devrait être développé. Si le développement du système est interne, vous aurez besoin d’examiner attentivement les options ci-dessous. Si vous procurez le système à partir d’un fournisseur externe, vous pouvez également demander une justification spécifique de l’utilisation d’un type de plate-forme et de décider sur la base de différentes propositions.

The below table outlines the pros and cons of different platform types.

Type de Plate-Forme

Avantages

Inconvénients

Logicielles “Out-of-the-box”
  • Baisse des coûts initiaux
  • Sachez ce que vous obtenez
  • Livraison plus courte
  • Soutien souvent inclus
  • Mises à jour souvent gratuit / à un coût réduit
  • Déjà testé / affiné par d’autres implémentations
  • Soutien disponible de la Communauté (à travers les forums et les utilisateurs experts)
  • Ajuster les processus pour répondre aux limitations du logiciel
  • Les demandes de fonctionnalités peuvent être ignorées si le logiciel n’a pas une grande base de clients
  • Frais élevés de personnalisation
  • Si les coûts sont facturés par utilisateur, les coûts peuvent être très élevés

Logiciel Personalisé pour le client
  • Obtenez ce que vous avez besoin et ce que vous voulez
  • La liberté de changer le logiciel pour l’aligner sur les besoins opérationnels
  • Construit avec votre entreprise et les employés à l’esprit
  • Potentiel d’engager l’industrie informatique locale
  • Pas de frais de licence
  • Aptitude à la marque de logiciel
  • Un soutien spécifique de l’application des personnes qui connaissent la plate-forme
  • Coûts iniciaux élevés
  • Toutes les modifications apportées au logiciel vienne avec un coût associé
  • Le logiciel peut toujours pas répondre à tous les besoins opérationnels
  • Dépendent des capacités techniques de l’équipe embauché pour développer le logiciel
  • Le soutien dépend de la disponibilité des développeurs et des gens qui connaissent le logiciel personnalisé

Logiciel “Open Source”
  • Peu, sinon aucun, frais de licence.
  • Facile à gérer en raison de l’absence des exigences de licences
  • En constante évolution en tant que développeur: flexibilité d’ajouter et de modifier ces fonctionnalités
  • Possibilité de mettre à jour le logiciel pour répondre aux besoins de votre entreprise Pas liée à la plate-forme d’un fournisseur particulier qui ne fonctionne qu’avec leurs autres systèmes
  • Pas de support garanti, Dépendant de la communauté d’utilisateurs pour répondre aux problèmes du logiciel
  • Le logiciel peut être orphelin lorsque les développeurs arrêtent sa mise à jour
  • Évolue avec les souhaits des développeurs plutôt que les besoins de l’entreprise de l’utilisateur
  • Les utilisateurs malveillants pourraient négativement faire la mise à jour du logiciel

Solution Hebergée sur le “Cloud”
  • Rentable – bas coûts initiaux,
  • Supprime le besoin d’acheter des logiciels coûteux et payer pour les licences et les coûts de serveurs traditionnels inférieurs;
  • Accessibilité – Permet d’accéder à partir de plusieurs plates-formes;
  • Adaptable – permet aux nouveaux utilisateurs d’utiliser le logiciel presque immédiatement, sans la necessité d’installation de l’application;
  • Réduit le besoin de compétences spécialisées pour maintenir le service;
  • Centralisation des données – toutes vos données en un seul endroit qui peut être consulté à distance;
  • Securité du Cloud;
  • Fournit un environnement de test flexible.
  • Faible bande passante affectera négativement la fonctionnalité;
  • Manque de perspicacité dans votre réseau – difficile à résoudre les bogues;
  • Les politiques de protection des données et/ou d’autre politique du gouvernement peuvent interdire l’utilisation de stockage de données sur le “cloud”
9

La révision des besoins du système avec les parties prenantes conformément à la matrice RACI défini dans votre document de projet de mise en œuvre.

10

Définir un processus de contrôle des changements qui vont assurer que les changements sont approuvés par les voies correctes et communiqués à toutes les parties. Voir le Guide de contrôle des changements pour des conseils sur la façon de procéder.