Instructions: Spécification des exigences logicielles
La Spécification des exigences logicielles (SRS) se consacre au recueil et à l'organisation de toutes les exigences concernant votre projet. Ces instructions expliquent comment développer une SRS.
Relations
Description principale

Explication

La Spécification des exigences logicielles se consacre au recueil et à l'organisation de toutes les exigences concernant votre projet. Si vous disposez d'un Plan de gestion des exigences, vous devez le consulter pour déterminer l'emplacement et l'organisation des exigences qui conviennent. Il peut être souhaitable, par exemple, de disposer d'une spécification des exigences logicielles distincte pour chaque fonctionnalité d'une version donnée du produit. Elle peut comprendre plusieurs cas d'utilisation tirés du modèle de cas d'utilisation du système et décrivant les exigences fonctionnelles de cette fonctionnalité, ainsi que les exigences pertinentes détaillées dans les Spécifications supplémentaires.

Comme vous pouvez disposer de plusieurs outils différents pour le recueil de ces exigences, vous devez être conscient que ces exigences peuvent être situées dans des artefacts et outils différents. Par exemple, vous pouvez trouver opportun de recueillir les exigences textuelles (telles que les exigences non fonctionnelles, les contraintes de conception, etc.) à l'aide d'un outil de documentation texte dans les Spécifications supplémentaires. En revanche, il peut vous sembler utile de rassembler certaines exigences fonctionnelles (ou leur totalité) dans les cas d'utilisation et d'utiliser un outil adéquat pour les besoins de la définition du modèle de cas d'utilisation.

Document ou package ?

Aucune raison suffisante ne justifie ici de mettre l'accent sur les différences entre les outils utilisés. Après tout, votre but est de rassembler des exigences et vous devez vous consacrer au recueil et à l'organisation efficaces de ces exigences sans considération des outils employés. Comme nous nous consacrons aux exigences et non pas aux outils, nous supposerons que le recueil des exigences dans la spécification des exigences logicielles constitue un package  d'informations. L'élaboration des diverses exigences du système est concrétisée dans un package dénommé Spécification des exigences logicielles.

Du document Vision à la Spécification des exigences logicielles

Le package de spécification des exigences logicielles est forcément associé au document Vision. En fait, ce document sert de point de départ à la spécification des exigences logicielles. Mais ces deux artefacts répondent à des besoins différents et sont généralement rédigés par des auteurs distincts. A ce stade du projet, l'accent passe de la formulation en termes généraux des besoins de l'utilisateur, des buts et des objectifs, des marchés cibles et des fonctionnalités du système à l'implémentation de ces fonctionnalités dans la solution.

Nous avons besoin à présent d'une collection, ou package, d'artefacts décrivant le comportement externe complet du système, c'est-à-dire un package stipulant spécifiquement "Voici ce que doit faire le système pour assurer ces fonctionnalités". Ce package est celui de la spécification des exigences logicielles.

Un artefact vivant

Le package de spécification des exigences logicielles n'est pas un ouvrage figé, généré pour assurer une conformité ISO 9000, puis enterré dans un coin et ignoré alors que le projet se poursuit. Il s'agit au contraire d'un artefact actif et vivant. En fait, il remplit plusieurs rôles lorsque les développeurs se consacrent aux tâches d'implémentation : il sert de base de communication entre tous les intervenants, à savoir entre les développeurs eux-mêmes, et entre ces derniers et les groupes extérieurs (utilisateurs et autres intervenants) avec lesquels ils doivent communiquer. Il représente un accord contractuel, formel ou non, entre les parties : les développeurs n'ont pas à s'investir dans ce qui ne figure pas dans ce document. Ils sont par contre redevables des fonctionnalités mentionnées dans la spécification des exigences logicielles.

La norme de référence des membres du projet

La spécification des exigences logicielles sert de norme de référence au responsable de projet. Le responsable de projet n'a probablement ni le temps, ni l'énergie ou les compétences pour décortiquer le code généré par les développeurs et le comparer directement au document Vision. Il doit utiliser le package de spécification des exigences logicielles comme norme de référence dans ses discussions avec l'équipe de projet.

Comme mentionné plus haut, ce package sert d'entrée aux groupes de conception et d'implémentation. Selon le mode d'organisation du projet, il se peut que les implémenteurs aient été impliqués dans les tâches préalables de résolution de problèmes et de définition des fonctionnalités qui ont engendré le document Vision. Mais ils doivent à présent se concentrer sur le package de spécification des exigences logicielles pour décider ce que leur code doit accomplir. Ce package sert aussi d'entrée aux groupes de test logiciel et d'assurance qualité. Ces groupes auraient dû aussi participer à certaines des discussions antérieures et il est bien entendu utile qu'ils perçoivent correctement la "vision" déployée dans les documents Vision. Mais leur mission est de créer des scénarios de test et des procédures d'assurance qualité pour s'assurer que le système se conforme bien aux exigences énoncées dans le package de spécification des exigences logicielles. Ce package constitue également la norme de référence dans leurs tâches de planification et de test.

Définition des exigences fonctionnelles

Voir Instructions : Modèle de cas d'utilisation et Instructions : Cas d'utilisation pour une discussion complète de l'approche recommandée pour la définition des exigences fonctionnelles dans un modèle de cas d'utilisation et dans les cas d'utilisation.

Définition des exigences non fonctionnelles

Les exigences non fonctionnelles de votre système doivent être documentées dans Produit : Spécifications supplémentaires.Ci-dessous figurent les recommandations à suivre lors de la définition de ces exigences.

1 Généralités

1.1 Hypothèses et questions problématiques

Lors du recueil et de la validation des exigences non fonctionnelles, établissez des listes d'hypothèses et de questions problématiques. 

Certaines tâches ne proposent pas de réponses satisfaisantes. Ceci peut être dû à un manque d'informations ou simplement au fait que la réponse semble remettre en cause la viabilité de la conception. Créez donc deux listes et tenez-les à jour au cours de l'étude de conception :

Hypothèses émises au cours du processus de définition des exigences et de la conception, y compris leur justification ou les réflexions à la base de ces hypothèses. Les hypothèses peuvent être utilisées afin d'identifier des sous-projets associés ou des tâches qui dépassent le cadre du projet ou qui doivent lui succéder.

Questions problématiques primordiales (préoccupations importantes pouvant devenir critiques)

Ces questions devraient être passées en revue avec le client à la fin de chaque phase. Les hypothèses doivent aussi être examinées à la fin de chaque phase mais le client n'est pas forcément l'interlocuteur approprié pour les moins importantes.

Les hypothèses et questions problématiques se retrouvent dans tous les produits mais sont particulièrement fréquentes dans le cas d'exigences non fonctionnelles.

1.2 Organisation géographique

Documentez l'organisation géographique du client.

Documentez les emplacements géographiques des sites de l'entreprise affectés par ce système. Cette définition doit aussi comprendre les sites non affectés mais hébergeant des ressources essentielles en terme de technologies de l'information. Notez particulièrement les éléments mobiles de l'organisation (par exemple une force de vente itinérante et utilisant des stations de travail). Notez tous les emplacements géographiques sur lesquels vous pouvez être amenés à fournir un support spécial en langue nationale (NLS).

2 Contraintes

2.1 Packages d'applications présélectionnés ?

Les exigences spécifient-elles l'utilisation de packages d'applications ? Une "contrainte" très importante pouvant dicter certaines décisions sur la conception du système concerne l'utilisation d'un package d'application spécifique fournissant une logique applicative et une organisation de données prédéfinies. Certains packages logiciels sont flexibles et autorisent un niveau de personnalisation élevé ; d'autres sont extrêmement rigides et ne le permettent pas. Ces packages peuvent imposer des composants et des décisions tels que :

  • Type de station de travail
  • Méthodes de connexion
  • Type de processeur et d'unité de stockage à accès direct
  • Programme de contrôle du système
  • Organisation, placement et gestion des données
  • Langage de programmation
  • Interfaces de traitement par lots
  • Relations entre processus et données
  • Logique métier
  • Conception des écrans et interfaces utilisateur
  • Caractéristiques de performance et de disponibilité
  • Architecture d'impression requise ou existante, comme formats privilégiés d'impression des données (par exemple, PostScript, PCL, IPDT)
  • Support de langues nationales (NLS)

Il est important de comprendre l'impact d'un package donné sur votre conception. Si un package vous est "imposé", assurez-vous de pouvoir disposer des compétences et connaissances requises. Celles-ci pourront provenir des sources suivantes :

  • Fournisseur du package
  • Consultants externes
  • Membres de l'équipe spécialement formés

Ne présumez pas que ces connaissances soient faciles à obtenir. Faites en sorte qu'elles soient disponibles quand vous en aurez besoin.

2.2 Autres contraintes

Documentez dans les exigences toutes les autres contraintes limitant la flexibilité de la conception.

Cette démarche permet de détecter des exigences spécifiques qui n'auraient pas été explicitement couvertes au cours des tâches préalables et qui pourraient limiter la flexibilité de la conception. Penchez-vous notamment sur les questions suivantes :

  • L'utilisation de processeurs ou d'images de systèmes d'exploitation existants
  • L'utilisation de stations de travail existantes
  • L'utilisation d'un réseau existant
  • L'utilisation de pratiques existantes de gestion du système
  • L'utilisation d'un modèle spécifique, comme : 'vous devez utiliser pour la conception un modèle système client/serveur qui décrive clairement la logique Présentation/Activité/Accès aux données et où et comment ils sont en interface'.

Le nouveau système sera-t-il affecté par l'une de ces contraintes ? Si ce système doit fonctionner sur un processeur, ou à partir d'une image de système d'exploitation, ou selon une configuration réseau existants, les caractéristiques de la plate-forme existante et de sa charge de travail auront-elles des conséquences sur le nouveau système ?

Quelles capacités de traitement et de connexion sont-elles déjà monopolisées par les charges de travail existantes ?

Quels sont les contrôles de sécurité utilisés par les charges de travail existantes ? Prenez-en note et comparez-les aux exigences du nouveau système en matière de sécurité quand vous les analyserez.

Quelles sont les caractéristiques de disponibilité de la charge de travail existante ?

Notez tous les éléments susceptibles d'affecter la conception ultérieure de la disponibilité dans le nouveau système. Par exemple, la charge de travail existante enjoint-elle d'arrêter chaque nuit le processeur ?

2.3 Matériel spécial ?

Les exigences spécifient-elles l'utilisation de matériel spécial ?

Cette contrainte peut être formulée en termes génériques ('le système doit prendre en charge une table traçante à haute vitesse') ou être plus spécifique ('les guichets automatiques Panda Corp ATM existants seront pris en charge'). Documentez du mieux que vous pourrez :

  • Les prérequis éventuels au niveau des logiciels et des matériels
  • Les fournisseurs et leurs services d'assistance
  • Les considérations concernant le support de langues nationales
  • Les équipements cryptographiques
2.4 Données existantes ?

Les exigences spécifient-elles l'utilisation de données existantes ? Une réponse positive aura une incidence sur la conception de votre système. Documentez :

  • Sur quel(s) système(s) existent actuellement les données
  • Leur structure (fichier relationnel ou plat)
  • Leur taille
  • Les utilisateurs et les systèmes qui exploitent ces données actuellement
  • Les considérations de disponibilité (comme les périodes où les données sont indisponibles pour des raisons de maintenance de la base de données ou de traitement par lots)
  • La capacité de déplacement ou de copie de ces données

3 Normes

3.1 Architecture technique / Plan stratégique

Le client dispose-t-il d'une architecture technique et/ou d'un plan stratégique informatique (ou d'un ensemble de normes équivalent) ?

Une architecture technique est à peu près équivalente aux concepts suivants :

  • Plateforme technique d'entreprise
  • Infrastructure technique d'entreprise
  • Architecture technologique

Dans une architecture technique, certains des éléments suivants peuvent avoir déjà été définis pour vous :

  • Le nombre et l'usage des centres de calcul
  • La connectivité réseau de l'entreprise (WAN)
  • La connectivité locale de certains établissements (LAN)
  • Les services d'infrastructure client/serveur (middleware) couvrant les services suivants :

· Services d'annuaire et d'affectation de noms qui effectuent le suivi des attributs et des ressources réseau
· Services de sécurité qui protègent les ressources réseau contre les utilisations non autorisées en enregistrant les utilisateurs et leurs niveaux d'autorisation
· Services de synchronisation d'horloges qui ajustent la date et l'heure à travers le réseau
· Services de gestion des transactions qui coordonnent la récupération des ressources à travers divers systèmes d'un réseau

  • Les méthodes de développement qui seront utilisées pour les nouvelles applications 
  • L'ensemble de produits pris en charge, comme :

· Matériel
· Logiciels de contrôle du système
· Logiciels génériques de type "Office"
· Utilisation du service d'assistance
· Règles de sécurité

  • Architecture du sous-système d'impression

La liste peut être très complète et ses éléments strictement contrôlés ou ne pas être sujette à contrôle.

Documentez toute exigence réclamant, ou excluant, explicitement l'utilisation de sous-architectures telles que :

  • OSI ou SNA
  • UNIX**
  • SAA
  • PS/2* avec OS/2* EE.

Architectures spéciales pouvant être induites par l'utilisation d'un package de solution d'application. Rappelez-vous que certains packages d'application constituent des définitions d'architecture en soi.

Documentez le degré d'ouverture (c'est-à-dire, d'indépendance par rapport au fournisseur et d'interopérabilité) requis par le client. Si une architecture technique est présente, votre conception devra presque certainement s'y conformer. Vous devrez alors la compulser et assimiler les règles ayant une incidence sur la conception de votre système.

3.2 Architecture réseau

Le client dispose-t-il d'une architecture réseau auquel ce système devra se conformer ? Une architecture représente un ensemble de règles communes pour la connectivité de haut niveau et une infrastructure de transport commune. Cette architecture peut comprendre la définition d'un réseau pivot, incluant concentrateurs et lignes. En présence d'une telle architecture, vous devez en comprendre les règles essentielles et la topologie, et documenter :

Les aspects de topologie physique (à savoir, si le réseau est essentiellement en zone rurale ou métropolitaine, à forte concentration ou bien diffus).

Les fonctions de connexion de haut niveau prises en charge par l'infrastructure réseau actuelle.

Les normes de communication utilisées (par exemple, SNA, OSI ou TCP/IP) pour gérer ces fonctions de connexion.

Les interfaces de programmation prises en charge.

Les définitions d'architecture réseau relatives à la connectivité entre couches client/serveur ou couches du modèle système de base, comme :

  • Accès aux données relationnelles entre postes clients et serveurs relationnels du réseau local devant s'effectuer via les protocoles d'un produit de base de données relationnelle spécifique.
  • Logique de présentation devant toujours être du ressort du poste de travail et logique d'accès aux données, du ressort d'un système hôte centralisé.
3.3 Règles de connexion

Le client a-t-il établi des règles de connexion explicites ?

Des règles de connexion peuvent exister même en l'absence d'architecture technique ou réseau.

Documentez toutes les règles concernant les points suivants :

  • L'utilisation de protocoles ou d'installations de communication spécifiques (pour connexions à l'intérieur d'un même bâtiment ou avec l'extérieur du bâtiment ou de l'organisation).
  • L'imposition implicite de protocoles spécifiques pour la prise en charge d'équipements ou de logiciels existants.
  • L'utilisation requise d'équipements existants de connectivité physique (câblage, contrôleurs de périphériques ou réseau et équipements de l'opérateur Télécom). Si tel n'est pas le cas, des contraintes peuvent néanmoins restreindre le type d'installations physiques utilisables (pratiques, réglementations, espace physique, appartenance des locaux, implication de tiers). Documentez ces contraintes.
  • Si une demande d'installation ou de modification des équipements physiques est prévisible, l'intervention de tiers peut être requise (comme des sous-traitants ou des opérateurs Télécom). Clarifiez comment la sous-traitance et les responsabilités seraient alors gérées. Ceci est particulièrement important si les interactions commerciales entraînent des connexions internationales.
  • Prise en charge des utilisateurs nomades.
3.4 Autres règles ?

Le client utilise-t-il d'autres pratiques, normes ou règles non mentionnées explicitement dans ses exigences ? Par exemple :

  • Toutes les interfaces destinées à l'utilisateur dans le nouveau système doivent être élaborées d'après une conception orientée objet permettant le Glisser-déplacer.
  • Tous les nouveaux systèmes doivent se baser sur le modèle d'application client/serveur.
  • Tous les nouveaux systèmes doivent être définis d'après des normes ouvertes.
  • Normes et règles pour le support des langues nationales, spécialement quand le sens d'opération du texte est de droite à gauche.
  • Règles de sécurité définissant la responsabilité de la gestion et les normes d'authentification des utilisateurs, du contrôle d'accès et de la protection des données.
  • Normes d'échanges de données entre applications (comme UNEDIFACT ou VISA) qui pourraient entraîner l'utilisation d'équipement spécial pour la connexion ou la sécurité.

En cas d'autres règles, prenez soin de bien les interpréter et d'y avoir accès pour garantir que votre conception se conforme aux normes dans les phases ultérieures de ce processus. L'utilisation d'un package de solution d'application peut souvent s'accompagner de normes implicites.

Les utilisateurs et les divers services sont-ils autorisés à ajouter ou à développer leurs propres programmes locaux sur :

  • Les postes de travail
  • Les serveurs (spécialement du point de vue de l'utilisation de l'espace disque)

Il est fréquent de constater que, sans contrôles adéquats, l'utilisation locale peut rapidement épuiser des ressources requises par les systèmes de production pour lesquels les composants locaux ont été initialement acquis. Il se peut même que vous ne puissiez pas installer le système de production lorsqu'il sera fin prêt pour son déploiement.

4 Chiffres

4.1 "Unités de mesure"

Collaborez avec le personnel de développement des applications pour décomposer les processus métier en unités plus granulaires, telles que des processus métier réduits ou de petites transactions.

La raison en est que la question suivante vous amène à utiliser des nombres et que vous devrez décider sur quoi portera le calcul.

Prenez en compte qu'un processus métier peut déclencher plusieurs instances de transactions commerciales plus réduites (par exemple, plusieurs articles par commande client) et que ces multiplicateurs doivent être inclus lorsque vous documenterez ces unités. Cependant, n'abondez pas dans le détail, en particulier dans le cas d'un système complexe.

Un "processus" métier (par exemple, "traitement de commande client") sera généralement implémenté par une "application"(dans le sens informatique du terme), ou concernera plusieurs applications. Chaque application traite habituellement un grand nombre de "transactions" informatiques (par exemple, interrogation du niveau de stock ou génération d'une lettre au client).

Les unités dont nous essayons de convenir sont identifiées par des noms différents d'une communauté à l'autre. Par exemple, "transaction" peut signifier une chose pour les personnes ayant des connaissances en développement d'applications, et une toute autre chose pour l'équipe d'infrastructure. Il est donc important d'oeuvrer ensemble pour mettre ces noms en correspondance, puis de recueillir l'information.

4.2 "Volumes et dimensions utilisés dans l'entreprise"

Identifiez et documentez les informations relatives aux volumes et aux dimensions pour chaque unité détectée à la section 4.1: "Unités de mesure". Par exemple :

  • Combien peut-on prévoir d'utilisateurs de chaque processus métier ou de chaque application, en moyenne et aux périodes de pointe ?
  • Quelles sont les périodes de pointe (sur la base appropriée : quotidienne, hebdomadaire, mensuelle, etc.) ?
  • Quel sera le débit de traitement des transactions, en période de pointe et en moyenne ?
  • Quel est le nombre et la taille des éléments et des instances de données dans chaque groupe de données ?
4.3 "Critères de performance des processus métier"

Le client peut avoir spécifié des critères de performance pour une partie ou pour l'ensemble des processus métier. Rappelez-vous cependant de documenter parallèlement les performances cible concernant les processus de support du système (sauvegarde système, par exemple) et des processus de développement d'applications, si elles ont été identifiées. Pour chaque catégorie, documentez les points suivants :

  • Exigences quant au délai de réponse et d'exécution ?
  • Où ces paramètres doivent-ils être mesurés ?
  • Des critères distincts sont-ils acceptables pour des périodes différentes (par exemple, hors pointe/de nuit) ?
  • Les critères doivent-ils aussi être remplis en situation de reprise sur incident ou de repli ?
  • Une garantie de performance est-elle requise ?
  • L'impact sur les parties prenantes au cas où les exigences de performance ne seraient pas remplies ?
  • Les conditions de performance minimales afin que le processus métier soit considéré comme disponible (c'est-à-dire, le point au-dessous duquel il sera considéré étant "indisponible" et non plus "lent") ?
  • Si un package de solution d'application a déjà été choisi, prenez soin d'avoir accès à ses caractéristiques de performance. Il se peut que vous n'ayez pas besoin de toutes les connaître dès à présent mais déterminez comment les obtenir car elles vous seront probablement nécessaires ultérieurement. La communication de ces informations par des tierces parties peut prendre du temps, aussi réclamez-les dès maintenant.

5 Disponibilité

5.1 Suggestions quant à la disponibilité

L'approche recommandée pour établir les exigences de disponibilité est la suivante :

  1. Identifiez les véritables utilisateurs du système, les processus métier qu'ils effectuent et les heures auxquelles ils les effectuent
  2. Analysez l'impact de la disponibilité du service (ou de son indisponibilité) sur la capacité de l'utilisateur à accomplir ses objectifs professionnels
  3. Spécifiez les exigences de disponibilité qui reflètent directement les besoins de l'utilisateur pour accomplir ses objectifs professionnels
  4. Si un package de solution d'application a déjà été choisi, tenez compte du fait que sa structure et sa conception peuvent avoir des conséquences significatives sur les caractéristiques de disponibilité de l'application, du point de vue de l'utilisateur. Un module non conçu pour un fonctionnement ininterrompu peut être difficile à opérer en continu, spécialement en termes de créneaux de maintenance et de traitements par lots.

Tenez compte des recommandations suivantes lors de la formulation des exigences de disponibilité :

  • Au lieu de spécifier des exigences "globales" concernant l'intégralité du système, stipulez des exigences à un plus faible niveau de granularité (par exemple, par processus individuel, par groupe d'utilisateurs, par groupe de données, etc.). Cette méthode accorde au développeur plus de flexibilité pour répondre aux besoins de l'utilisateur. Ceci est particulièrement important pour les systèmes avec des exigences de disponibilité continuelle élevées.

Quelques exemples :

  • La déclaration "Le système doit être en ligne 24 heures sur 24 pour répondre aux besoins des utilisateurs de New York et Hong Kong" accorde au concepteur beaucoup moins de souplesse de conception que la déclaration "Les utilisateurs à New York doivent être capables d'effectuer des transactions sur LEURS données de 7h à 19h (heure locale) et ceux à Hong Kong doivent être capables d'effectuer des transactions sur LEURS données de 7h à 19h (heure locale)". Dans ce dernier cas, le concepteur a toute latitude pour effectuer les tâches de maintenance des données ou des composants du système sur le fuseau horaire inactif tandis que l'autre est en pleine période de production.
  • Dans une application de guichet automatique, il peut être crucial d'accepter des dépôts et de délivrer des espèces à 3h du matin le lundi, alors que la capacité de pouvoir consulter son solde à jour n'est pas primordiale à cette heure.
  • Distinguez entre les caractéristiques de disponibilité SOUHAITABLES et celles qui sont IMPÉRATIVES. Par exemple, "Le guichet automatique DOIT être capable d'accepter des dépôts et de délivrer des espèces 24h/24. Il est SOUHAITABLE que le guichet automatique puisse communiquer au client son solde exact 24h/24 ; des interruptions occasionnelles de ce service peuvent être tolérées mais ces interruptions DOIVENT toutefois durer moins de 10 minutes et intervenir entre 03h00 et 04h00".
  • Si la capacité de l'utilisateur final à réaliser ses objectifs professionnels n'est pas directement affectée par l'impossibilité d'atteindre une disponibilité cible, cette exigence de disponibilité cible au niveau du système est sans doute superflue.
  • Les exigences de disponibilité qui ne reflètent qu'indirectement la disponibilité telle que perçue par l'utilisateur (par exemple, "La région de contrôle IMS doit être en ligne") ont tendance à être moins utiles que celles où la corrélation est directe (par exemple, "Les caissiers de la banque doivent être capables d'exécuter les processus X et Y").
5.2 "Heures de service planifiées"

Pour chaque processus métier et groupe d'utilisateurs chargé de les exécuter, identifiez l'horaire où ils doivent être capables d'effectuer cette tâche. Procédez de même pour les processus qui ne sont pas directement associés à un groupe d'utilisateurs.

Si des groupes d'utilisateurs sont répartis sur des fuseaux horaires différents (comme dans l'exemple précédent sur New York et Hong Kong), traitez-les comme des groupes d'utilisateurs distincts.

Indiquez également si l'application peut ne pas être requise à certaines périodes (jours fériés, par exemple). Le concepteur a ainsi la possibilité d'utiliser ces périodes pour une maintenance de fond. Quelles modifications des horaires de service sont attendues au cours du cycle de vie prévu de l'application ?

Les heures de service du système peuvent aussi être affectées par celles d'autres systèmes avec lesquels il est en interface.

Quelles sont les prévisions de modification des heures de service de ce système au cours de son cycle de vie projeté ?

5.3 "Coûts des interruptions de service"

Déterminez l'IMPACT COMMERCIAL, les COUTS FINANCIERS et les RISQUES liés à des interruptions de service au cours des heures de service planifiées.

Pour clarifier les exigences de disponibilité réellement importantes pour ce système, examinez les processus métier et les groupes d'utilisateur afin d'identifier l'impact sur l'activité découlant des situations suivantes :

  • Une brève interruption ou une période de délai de réponse inacceptable au cours des heures de service planifiées. Définissez les termes "brève" et "inacceptable" dans le contexte de cette application spécifique (voir "Critères de performance des processus métier")
  • Interruptions diverses de plus longue durée au cours des heures de service (une minute, quelques minutes, 15 minutes, 30 minutes, une heure, deux heures, quatre heures, etc.)
  • Interruptions prolongées du service (une période de travail entière, une journée, plusieurs journées, etc.).
  • Prenez également en compte les processus non associés directement avec un groupe d'utilisateurs (par exemple, compensation de nuit des chèques).

Lors de l'évaluation des conséquences de chaque interruption, identifiez les procédures de repli et déterminez comment elles peuvent réduire l'impact commercial effectif de l'interruption.

Essayez de quantifier cet impact en termes monétaires (coût de perte de productivité du personnel ou d'équipements, valeur des affaires en cours perdues et estimation des pertes futures en raison du mécontentement des clients, frais d'intérêts, amendes légales, etc.).

Fournissez autant de réponses que nécessaire afin de refléter les différences de coûts et de risques associés à des interruptions de diverses durées et à différents moments (planifiées ou non), les processus métier ou les utilisateurs affectés, etc.

Quel est l'impact commercial/financier d'une interruption de service sujette à changement au cours du cycle de vie du système ?

Passez en revue tous les processus métier reconnus comme prioritaires pour identifier des alternatives permettant à leurs éléments cruciaux de poursuivre leur opération au cas où des pans du système deviendraient momentanément indisponibles. La capacité à fonctionner temporairement avec des fonctions métier réduites peut être une manière d'aider à réduire l'impact sur la disponibilité des interdépendances entre les processus et les données essentiels.

Quelques exemples :

  • FONCTION COMPLETE 1 Lecture et mise à jour d'enregistrement de stock.
  • FONCTION REDUITE 1 Saisie de la mise à jour de l'enregistrement de stock et mise en file d'attente pour actualisation ultérieure.
  • FONCTION COMPLETE 2 Lecture du solde client le plus récent.
  • FONCTION REDUITE 2 Lecture du solde client depuis une source alternative, pas nécessairement à jour.
  • FONCTION COMPLETE 3 Mise à jour de l'agenda informatisé.
  • FONCTION REDUITE 3 Mise à jour de la copie papier imprimée de l'agenda.

En cas de dégradation des fonctionnalités, rappelez-vous qu'il y a des limites à ce qui peut être considéré comme acceptable pour les processus métier. Par exemple, un solde client périmé ne doit pas dater de plus de 24 heures.

Si le service est interrompu pendant les heures d'opération planifiées (voir "Heures de service planifiées"), l'incidence de cette interruption sera généralement fonction de sa durée et d'autres conditions. Certaines interruptions peuvent n'avoir qu'un impact mineur sur la capacité des utilisateurs à utiliser leurs processus métier (interruptions brèves, ou survenant à des heures de faible utilisation, ou affectant seulement un segment du groupe d'utilisateurs, ou encore interruptions pour lesquels une procédure manuelle de repli acceptable existe). D'autres, comme celles de plus longue durée ou se produisant à une période "critique" de la journée, peuvent avoir des conséquences plus sérieuses. 

Quelques exemples :

  • Une brève interruption des processus de contrôle d'une chaîne de fabrication peut n'avoir qu'un impact minime sur la productivité étant donné que le travail peut se poursuivre d'après les ordres de fabrication imprimés auparavant et que les modifications peuvent être notées manuellement pour leur saisie ultérieure. Par contre, une interruption de plus de 60 minutes peut entraîner l'arrêt de la chaîne pendant toute la rotation.
  • Une interruption, au cours de la dernière heure des cotations, des services d'un système financier de liquidation des transactions en bourse peut entraîner des frais d'intérêts élevés ou des amendes légales.
  • La réaction des services de police et des pompiers aux situations d'urgence peut se poursuivre à l'aide de procédures manuelles de repli même si le système de coordination des ressources est indisponible. Toutefois, le délai d'intervention peut augmenter et potentiellement, mettre des vies en danger, en raison de la charge de travail supplémentaire du répartiteur.
  • Une interruption en période de pointe du système de réservations d'une compagnie aérienne ou d'un hôtel peut non seulement provoquer un manque à gagner immédiat lorsque les clients contactent la concurrence pour effectuer leurs réservations mais aussi affecter le chiffre d'affaires futur si les clients sont suffisamment mécontents pour faire appel à une autre compagnie ou un autre hôte la prochaine fois qu'ils auront besoin de ces services.
5.4 "Critères de disponibilité et de reprise sur incident"

Identifiez les CRITERES DE DISPONIBILITE ET DE REPRISE SUR INCIDENT qui s'appliqueraient dans les situations "normales".

Excluez les situations de "sinistre", telles que des pertes de données massives ou l'arrêt complet des installations informatiques.

Sur la base des coûts commerciaux et financiers et des risques identifiés à la section "Coûts des interruptions de service", rédigez une spécification des critères de disponibilité à observer afin que l'exécution des processus métier assignés aux groupes d'utilisateurs ne soit pas significativement perturbée. Ces critères peuvent, par exemple, s'exprimer sous les formes suivantes :

  • Pourcentage d'interruptions corrigées au bout d'un nombre de minutes/secondes donné
  • Durée maximale sur une semaine/un mois/une année donnés pendant laquelle l'utilisateur ne pourrait pas utiliser une fonction spécifique

Soyez aussi précis que nécessaire pour illustrer les facteurs pertinents, comme les différences entre interruptions planifiées et imprévues, l'heure où elles surviennent (par exemple, périodes "critiques" par rapport à des périodes de faible utilisation), le nombre d'utilisateurs affectés, etc.

Ne spécifiez pas de critères de disponibilité plus rigoureux que nécessaire afin de ne pas amplifier outre mesure les coûts d'implémentation. En règle générale, si des coûts commerciaux et financiers ou des risques ne peuvent pas être identifiés en association avec une situation d'interruption donnée, il est vraisemblable que cette situation n'a pas à être englobée dans les critères de disponibilité mis en place.

Si l'étude des "Heures de service planifiées" a suggéré qu'elles connaîtraient probablement des modifications au cours du cycle de vie du système, et/ou que l'étude des "Coûts des interruptions de service" a suggéré qu'il en serait de même des coûts commerciaux et financiers ou des risques liés à une interruption, évaluez les conséquences de ces changements sur les critères de disponibilité.

Si la cryptographie est utilisée, des considérations supplémentaires entrent en jeu pour la disponibilité et la reprise sur incident. Par exemple :

  • La capacité de récupération d'informations confidentielles conservées éventuellement en dehors du système.
  • La nécessité de coordonner la récupération des données chiffrées avec celle des clés de chiffrement correspondantes
5.5 "Reprise sur incident majeur ?"

Une reprise sur incident majeur est-elle requise dans le cadre de ce projet de conception (disponibilité lors d'"incidents majeurs", comme une perte massive de données ou un arrêt total des installations informatiques) ? Dans ce cas, quels sont les critères de reprise ?

Il est probable que les processus métier ne nécessitent pas tous des mécanismes de reprise sur incident. Sélectionnez uniquement les processus critiques qui les imposent. Même pour ces processus, certaines fonctions peuvent être exemptées.

  • Sous quel délai le service doit-il être restauré ? Ce compte à rebours commence-t-il dès que l'incident majeur survient ou à partir de la décision de basculement sur un site distant ?
  • Sous quelles circonstances l'organisation opterait-elle pour une reprise sur site distant et non pas locale ?
  • A quel niveau de mise à jour doivent être les données sur le site distant pour que l'entreprise puisse continuer à opérer (à la seconde près, datant de quelques minutes avant l'interruption, du jour précédent) ?
  • A partir de quand le service devra-t-il être restauré depuis le site distant ?
  • A une date future ?
  • Quelle est la priorité relative de la reprise de ce groupe d'applications sur le site distant par rapport à d'autres applications métier tributaires des mêmes ressources informatiques ?

Notez que des critères distincts peuvent s'appliquer à des parties différentes du système ou en fonction de la catégorie de l'incident majeur.

Quelles modifications des exigences de reprise sur incident majeur sont attendues au cours du cycle de vie prévu de l'application ?

5.6 "Autres considérations de conception concernant la disponibilité"

Pour concevoir un système autorisant une reprise aussi rapide que possible, son concepteur doit savoir de quelle marge de flexibilité il dispose dans l'implémentation de l'application tout en répondant à ses exigences fonctionnelles. Les questions suivantes peuvent l'orienter dans sa démarche :

1. Pour permettre les tâches de maintenance indispensables, le système peut-il opérer pendant de brèves périodes avec les restrictions suivantes :

a. Exécution d'interrogations du système mais sans mises à jour des données ?

b. Acceptation des demandes de mises à jour de l'utilisateur mais sans actualisation de la base de données jusqu'à l'échéance des tâches de maintenance ?

2. Dans le cas d'une interruption nécessitant une restauration des données, quelle est la priorité entre :

c. Restauration aussi rapide que possible du service, même en utilisant des données non totalement à jour

d. Actualisation des données avant la restauration du service, même au prix d'un délai supplémentaire

3. Si une demande utilisateur était "en traitement" au moment de la panne, peut-on laisser le soin à l'utilisateur de soumettre à nouveau sa requête après la reprise du service ?

4. Des considérations d'ordre non technique affectent-elles la disponibilité du système (par exemple, une règle interne stipulant que le processus A ne peut être disponible aux utilisateurs que si le processus B l'est aussi)?

Certaines de ces considérations de conception sont-elles susceptibles d'être modifiées au fil du temps ?

Dans le cas de processus cruciaux pour l'entreprise, il est utile d'identifier des alternatives permettant un semblant de fonctionnalité à leurs éléments les plus critiques, même lorsque des pans entiers du système sont temporairement indisponibles. La capacité à fonctionner temporairement avec des fonctions métier réduites peut être une manière d'aider à réduire l'impact sur la disponibilité des interdépendances entre les processus et les données essentiels.

6 Sécurité

6.1 "Exigences de sécurité"

1. Identifiez les données à protéger

2. Identifiez le type de menaces auquel chaque type de données est exposé :

  • Altération ou destruction accidentelle
  • Altération ou destruction délibérée
  • Espionnage industriel
  • Fraudes
  • Piratage informatique
  • Virus

1. Identifiez les menaces physiques :

  • Vol de composants
  • Accès physique non autorisé
  • Sécurité physique des utilisateurs

2. Identifiez les personnes pouvant être à l'origine de ces menaces :

  • Personnel du centre de données
  • Personnel des autres services informatiques (par exemple, développement)
  • Personnel des autres services dans l'organisation
  • Individus en dehors de l'organisation

3. Identifiez les exigences de sécurité spéciales ou inhabituelles, notamment en ce qui concerne :

  • L'accès au système
  • Le chiffrement des données
  • La vérifiabilité

4. Existe-t-il des dispositions générales (telles que des lois sur la liberté de l'information) pouvant influencer la conception de la sécurité du système ?

5. Certains packages de solution d'application intègrent leur propre sous-système de sécurité. Si vous devez utiliser un package "imposé", informez-vous de ses dispositifs de sécurité.

L'approche suivante peut vous aider à déterminer et à classifier les exigences de sécurité :

1. Répertoriez les objets devant bénéficier d'une protection physique ou logique.

2. Identifiez le degré d'exposition pertinent à chaque objet. Les catégories usuelles sont les suivantes :

  • Accès avec consultation (violation de la confidentialité des données). Par exemple : informations sur les comptes, liste de clients, brevets.
  • Accès avec mise à jour. Par exemple : modification de données pour fraude, falsification de faits, malversation.
  • Perte d'actifs, par exemple si quelqu'un détourne des actifs et qu'ils ne sont plus disponibles pour leur propriétaire (à la différence d'une perte due à un incident majeur). Exemples : liste de clients et de clients potentiels, contrats, etc.

Notez que les objets ne sont pas tous vulnérables à l'ensemble de ces risques d'exposition.

3. Identifiez toutes les menaces pertinentes à votre environnement. Nous citerons les exemples suivants :

  • Employés mécontents
  • Employés sans autorisation d'accès
  • Sessions de terminal laissées ouvertes dans des endroits publics
  • Pirates informatiques
  • Lignes sous écoute
  • Perte d'équipements (par exemple, ordinateur portable)

4. Etablissez quelles menaces s'appliquent à chaque objet et le niveau de risque associé.

Notez que vous devrez peut être examiner les exigences de sécurité de l'objet tant en position statique (par exemple, sur un disque dur) qu'en transit (par exemple, en cours de transmission).

Etant donné que la conception peut entraîner un repositionnement de l'objet dans des zones non sécurisées, vous devrez éventuellement revoir ce sujet.

Les orientations de sécurité peuvent être très exigeantes dans certaines conceptions de systèmes. Elles peuvent même être dominantes dans vos décisions. Depuis leur perspective, certaines options de structure et de sélection de composants à priori judicieuses peuvent devenir inacceptables. Déterminez donc une fois pour toutes si le système en conception impose des exigences de sécurité particulièrement astreignantes. Par exemple :

  • Système militaire sensible
  • Système de transfert de fonds destiné à des mouvements de capitaux massifs
  • Système traitant des données personnelles confidentielles

Si vous avez des raisons de croire que vous êtes confronté à des exigences de sécurité spéciales, contactez un consultant spécialisé ou un homme du métier pour vous seconder dans ces aspects de la conception du système.

7 Ergonomie

Les exigences ergonomiques définissent le niveau d'ergonomie requis de l'interface utilisateur.

Ces exigences devraient refléter le niveau d'ergonomie minimal requis du système pour permettre son utilisation. Elles n'ont pas à dépasser ces attentes, même si le système en est capable. En d'autres termes, les exigences ergonomiques ne doivent pas être considérées comme l'objectif ou la limite supérieure du système. Les exigences ergonomiques doivent définir le niveau strictement minimal acceptable. Par conséquent, vous pouvez continuer à améliorer l'ergonomie du système après avoir satisfait à ces exigences.

Les exigences du système, en vue de son utilisation, dépendent essentiellement de ce que les alternatives ont à offrir. Il est raisonnable d'attendre que son niveau d'ergonomie soit supérieur à celui de ses alternatives. Ces alternatives peuvent impliquer l'utilisation de :

  • Procédures manuelles existantes.
  • Système(s) hérité(s).
  • Produits concurrents.
  • Version(s) antérieure(s) du même système.

Les exigences ergonomiques peuvent aussi découler d'un besoin de justification économique du nouveau système : si le client doit investir 3 millions d'euros dans le nouveau système, il peut vraisemblablement imposer des exigences ergonomiques se traduisant par des économies annuelles de 1 million d'euros grâce à une réduction de la charge de travail de ses ressources humaines.

Ci-dessous figurent quelques exemples d'exigences ergonomiques générales :

  • Durée d'exécution maximale - Délai requis d'un utilisateur expérimenté pour l'exécution d'un scénario habituel.
  • Taux d'erreurs maximal - Moyenne des erreurs d'un utilisateur expérimenté lors de l'exécution d'un scénario habituel.
    Les seules erreurs qu'il convient de relever ici sont celles qui sont irrécupérables et entraînent des conséquences négatives pour l'organisation, comme la perte de commandes clients ou des dommages aux équipements sous suivi. Si l'unique conséquence d'une erreur est le temps passé à la corriger, ceci est comptabilisé dans le délai d'exécution mesuré.
  • Délai d'apprentissage - Laps de temps écoulé avant que l'utilisateur ne parvienne à exécuter un scénario plus rapidement que le délai d'exécution maximal.

Un exemple de quelques exigences ergonomiques spécifiques au cas d'utilisation "Gestion des e-mails entrants" est livré ci-après :

  • L'utilisateur de la messagerie doit être capable de trier les e-mails d'un seul clic de souris.
  • L'utilisateur de la messagerie doit être capable de faire dérouler le texte des e-mails par simple pression d'une touche sur le clavier.
  • L'utilisateur de la messagerie ne doit pas être dérangé par des messages entrants lors de la lecture d'un e-mail.