Chapitre 3 Exigences techniques

Dans le cycle de vie de la solution, la phase de spécification technique consiste à effectuer une analyse d'utilisation, identifier les cas d'utilisation et déterminer les exigences de qualité de service pour la solution de déploiement proposée.

Ce chapitre se compose des sections suivantes :

• À propos des exigences techniques

• Analyse d'utilisation

• Cas d'utilisation

• Exigences de qualité de service

• Exigences de niveau de service

À propos des exigences techniques

L'analyse des exigences techniques commence par un examen des exigences de l'entreprise exposées lors de la phase d'analyse d'exploitation. À l'aide de l'analyse d'exploitation, vous devez :

• effectuer une analyse d'utilisation afin de connaître les conditions de charge escomptées ;

• créer des cas d'utilisation constituant un modèle d'interaction utilisateur classique avec le système ;

• créer un ensemble d'exigences de qualité de service définissant le comportement d'une solution déployée en termes de temps de réponse, de disponibilité, de sécurité, etc.

  Les exigences de qualité de service dépendent de l'analyse d'utilisation et des cas d'utilisation, tout en tenant compte des exigences et des contraintes d'entreprise identifiées précédemment.

  Les exigences de qualité de service sont ensuite associées aux architectures logiques au cours de la phase de conception logique afin de créer un scénario de déploiement. Ce scénario joue un rôle capital au cours de la phase de conception du déploiement dans le cycle de vie de la solution.

  À l'instar de l'analyse d'exploitation, il n'existe aucune formule simple pour l'analyse des exigences techniques qui permette de générer l'analyse d'utilisation, les cas d'utilisation ou la configuration système requise. L'analyse des exigences techniques nécessite une connaissance du domaine d'activité, des objectifs d'entreprise et de la technologie sous-jacente du système.

Analyse d'utilisation

L'analyse d'utilisation implique l'identification des divers utilisateurs de la solution en cours de conception ainsi que la définition des types d'utilisation. Ces informations servent de point de départ pour évaluer les conditions de charge sur le système. Les informations relatives à l'analyse d'utilisation sont également utiles lors de l'assignation de pondérations aux cas d'utilisation, comme décrit dans la section Cas d'utilisation.

Au cours de l'analyse d'utilisation, vous devez consulter les utilisateurs chaque fois que vous en avez la possibilité, rechercher les données sur les types d'utilisation existants et interroger les concepteurs et administrateurs des systèmes précédents. Le tableau suivant répertorie les paramètres à prendre en considération lors d'une analyse d'utilisation.

Tableau 3–1 Facteurs à prendre en compte lors de l'analyse d'utilisation

Facteur	Description
Nombre et type d'utilisateurs	Identifiez le nombre d'utilisateurs que la solution doit prendre en charge et classez-les, si nécessaire.  Par exemple :  Une solution B2C (Business to Customer) peut comporter un grand nombre de visiteurs, mais seul un petit nombre d'entre eux s'enregistre et s'engage dans des transactions commerciales. Une solution B2E (Business to Employee) doit prendre en compte chaque employé, sachant que certains employés peuvent avoir besoin d'accéder au réseau interne à partir de l'extérieur.Dans une solution de ce type, il se peut que les dirigeants aient besoin d'une autorisation pour pouvoir accéder à certaines pages inaccessibles au reste des employés.
Utilisateurs actifs et inactifs	Identifiez les types d'utilisation et les rapports entre les utilisateurs actifs et inactifs.  Les utilisateurs actifs sont des utilisateurs connectés au système qui interagissent avec les services du système. Les utilisateurs inactifs peuvent être des utilisateurs qui ne sont pas connectés, des utilisateurs connectés mais qui n'interagissent pas avec les composants du système ou des utilisateurs appartenant à la base de données mais qui ne se connectent jamais.
Utilisateurs administratifs	Identifiez les utilisateurs qui doivent accéder au système pour le contrôler, le mettre à jour et prendre en charge son déploiement.  Déterminez les types d'utilisation administratifs spécifiques ayant un impact sur les exigences techniques (par exemple, l'administration du déploiement en dehors du pare-feu).
Types d'utilisation	Identifiez la façon dont les différents types d'utilisateurs accèdent au système et fixez les objectifs d'utilisation attendus.  Par exemple :  Existe-t-il des périodes de pointe en matière d'utilisation ? Quelles sont les heures de bureau classiques ? Les utilisateurs sont-ils répartis de façon homogène ? Quelle est la durée moyenne d'une connexion utilisateur ?
Augmentation du nombre d'utilisateurs	Déterminez si le nombre d'utilisateurs est fixe ou si le déploiement implique une augmentation du nombre d'utilisateurs.  Essayez d'évaluer de façon raisonnable cet éventuel accroissement.
Transactions utilisateur	Identifiez le type de transactions utilisateur à prendre en charge. Ces transactions peuvent être converties en cas d'utilisation.  Par exemple :  Quelles sont les tâches effectuées par les utilisateurs ? Une fois connectés, les utilisateurs le restent-ils ? En général, effectuent-ils quelques tâches avant de se déconnecter ? La collaboration entre les utilisateurs est-elle importante au point de rendre indispensable l'utilisation de calendriers communs, la tenue de conférences Web et le déploiement de pages Web internes ?
Études d'utilisateurs et données statistiques	Utilisez les études d'utilisateurs ainsi que d'autres éléments existants pour déterminer les types de comportement de l'utilisateur.  Souvent, les entreprises ou les organisations industrielles effectuent des études sur les utilisateurs à partir desquelles il est possible d'extraire des informations intéressantes. Les fichiers journaux des applications existantes peuvent contenir des données statistiques utiles à l'élaboration de projections pour un système.

Cas d'utilisation

Les cas d'utilisation simulent une interaction utilisateur classique avec le système en cours de conception et décrivent le déroulement complet d'une opération du point de vue d'un utilisateur final. En matière de conception, un classement par ordre de priorité autour d'un ensemble complet de cas d'utilisation assure la livraison des fonctionnalités prévues. Les cas d'utilisation jouent un rôle capital dans la conception logique.

Assignez des pondérations relatives aux cas d'utilisation, sachant que les pondérations les plus élevées correspondent aux tâches utilisateur les plus fréquentes. Lors de la conception, le système de pondération des cas d'utilisation permet de déterminer les services système les plus utilisés.

Les cas d'utilisation peuvent être classés selon deux niveaux :

• Rapports sur les cas d'utilisation : descriptions de chaque cas d'utilisation comprenant les flux d'événements principaux et secondaires.

• Diagrammes des cas d'utilisation : diagrammes illustrant les relations entre les acteurs et les cas d'utilisation, présentant ainsi une organisation plus formelle du flux des événements. Les diagrammes des cas d'utilisation permettent de créer des cas d'utilisation étendus ou complexes. Pour dessiner les diagrammes relatifs aux cas d'utilisation, la norme généralement utilisée est la norme UML (Unified Modeling Language).

Exigences de qualité de service

Les exigences de qualité de service (QoS) sont des spécifications techniques indiquant les qualités système de fonctions telles les performances, la disponibilité, l'évolutivité et l'entretien. Ces éléments sont fonction des besoins de l'entreprise spécifiés dans les exigences de l'entreprise. Par exemple, si des services doivent être disponibles 24 heures sur 24 toute l'année, l'exigence de disponibilité doit être établie en fonction.

Le tableau ci-dessous répertorie les qualités système constituant la base des exigences de qualité de service.

Tableau 3–2 Qualités système ayant un impact sur les exigences de qualité de service

Qualité du système	Description
Performances	Mesure du temps de réponse et de la capacité de traitement par rapport aux conditions de charge utilisateur.
Disponibilité	Mesure de la fréquence à laquelle les ressources et services d'un système sont accessibles aux utilisateurs finals, également appelée temps de disponibilité du système.
Évolutivité	Possibilité d'ajouter de la capacité (et des utilisateurs) à un système déployé au fil du temps. En principe, l'évolutivité implique l'ajout de ressources au système, mais ne doit pas entraîner de changements au niveau de l'architecture du déploiement.
Sécurité	Combinaison complexe de facteurs décrivant l'intégrité d'un système et de ses utilisateurs. La sécurité comprend l'authentification et l'autorisation des utilisateurs, la sécurité des données ainsi que l'accès sécurisé à un système.
Capacité latente	Aptitude d'un système à traiter des charges de pointe inhabituelles sans ressources supplémentaires. La capacité latente est un paramètre important des qualités d'évolutivité, de performances et de disponibilité.
Entretien	Facilité avec laquelle un système déployé peut être entretenu. Cela inclut le contrôle du système, la résolution des problèmes et la mise à niveau des composants matériels et logiciels.

Les qualités d'un système sont étroitement liées. Les exigences liées à un critère de qualité système peuvent avoir un impact sur les exigences et la conception d'autres critères de qualité système. Par exemple, des niveaux de sécurité relativement élevés peuvent affecter les performances qui, à leur tour, sont susceptibles d'influer sur la disponibilité. L'ajout de serveurs en vue de pallier les problèmes de disponibilité peut avoir des conséquences sur l'entretien (coûts de maintenance).

Il est essentiel de comprendre la manière dont les qualités système sont liées et de savoir quels sont les compromis nécessaires à la conception d'un système répondant à la fois aux exigences et aux contraintes de l'entreprise.

Les sections suivantes décrivent en détail les qualités système ayant un impact sur la conception du déploiement et fournissent des informations sur les facteurs à prendre en considération lorsque vous répertoriez les exigences de qualité de service. Vous trouverez également une section consacrée aux exigences de niveau de service sur lesquels sont fondés les contrats de niveau de service.

Performances

Dans les exigences de l'entreprise, les performances (temps de réponse) sont généralement exprimées en termes non techniques. Voici un exemple d'exigence d'entreprise relative à l'accès Web :

Lors de la connexion, les utilisateurs s'attendent à un temps de réponse raisonnable, à savoir, pas plus de quatre secondes.

En partant de cette exigence, examinez la totalité des cas d'utilisation afin de savoir comment exprimer cette exigence au niveau du système. Dans certains cas, il se peut que vous souhaitiez inclure les conditions de charge utilisateur définies au cours de l'analyse d'utilisation. Indiquez ensuite l'exigence de performances pour chaque cas d'utilisation en termes de temps de réponse par rapport aux conditions de charge indiquées ou de temps de réponse ajouté à la capacité de traitement. Il vous est également possible d'indiquer le nombre d'erreurs autorisées.

Voici deux exemples de formulation des exigences système en termes de performances :

• Le temps de réponse correspondant à l'actualisation des pages Web, échantillonné toutes les 15 minutes, ne doit dépasser à aucun moment de la journée les quatre secondes et ne doit pas comporter plus de 3,4 erreurs par million de transactions.

• En période de pointe, tout utilisateur doit pouvoir établir 25 connexions sécurisées par seconde avec un temps de réponse ne dépassant pas 12 secondes, le nombre d'erreurs par million de transactions ne devant pas dépasser 3,4.

Les exigences de performances sont étroitement liées aux exigences de disponibilité (influence du basculement sur les performances) et à la capacité latente (aptitude à traiter des charges de pointe inhabituelles).

Disponibilité

Il s'agit du temps de disponibilité du système. La disponibilité s'exprime en pourcentage de temps pendant lequel le système est accessible aux utilisateurs. Une indisponibilité, c'est-à-dire, le temps pendant lequel le système n'est pas accessible, peut provenir d'une défaillance matérielle ou logicielle, d'une défaillance réseau ou de toute autre anomalie (par exemple, une coupure d'alimentation) engendrant une panne système. Une interruption planifiée de l'activité en vue d'effectuer des opérations d'entretien (maintenance et mises à niveau) n'est pas considérée comme une indisponibilité en tant que telle. Voici une équation élémentaire permettant de calculer la disponibilité en termes de pourcentage de temps d'accessibilité du système :

Disponibilité = temps de disponibilité / (temps de disponibilité + temps 
d'indisponibilité) * 100 %

En règle générale, la disponibilité est fonction du nombre de « neuf » obtenu. Par exemple, une disponibilité de 99 % correspond à deux neuf. Lorsque vous indiquez davantage de neuf, la conception du déploiement s'en trouve fortement modifiée. Le tableau suivant indique le temps d'indisponibilité non planifié, correspondant à chaque neuf ajouté, dans le cadre d'un système fonctionnant 24 heures sur 24, 7 jours sur 7 et ce, toute l'année (soit un total de 8 760 heures).

Tableau 3–3 Interruption d'activité non planifiée d'un système fonctionnant toute l'année (8 760 heures)

Nombre de neuf	Pourcentage disponible	Indisponibilité non planifiée
2	99 %	88 heures
3	99,9 %	9 heures
4	99,99 %	45 minutes
5	99,999 %	5 minutes

Systèmes à tolérance de pannes

Dans le cadre d'une disponibilité de quatre à cinq neuf, le système doit être doté d'une tolérance de pannes. Un système à tolérance de pannes doit continuer de fonctionner même en cas de défaillance matérielle ou logicielle. La tolérance de pannes est généralement obtenue par une redondance matérielle (CPU, mémoire et périphériques réseau) ou logicielle permettant d'assurer les services essentiels.

Un point de panne unique correspond à un composant logiciel ou matériel qui fait partie d'un chemin critique mais qui n'est pas sauvegardé par des composants redondants. La panne de ce composant entraîne la perte de service pour le système. Lors de la conception d'un système à tolérance de pannes, vous devez identifier et supprimer les points de pannes uniques potentiels.

Ces systèmes peuvent s'avérer coûteux à implémenter et à entretenir. Il est nécessaire de comprendre la nature des exigences de l'entreprise concernant la disponibilité et de tenir compte des stratégies et des coûts des solutions de disponibilité qui répondent à ces exigences.

Classement par ordre de priorité en termes de disponibilité de service

D'un point de vue utilisateur, la disponibilité concerne certains services en particulier plutôt que la totalité du système. Par exemple, la non-disponibilité d'un service de messagerie instantanée a généralement peu ou pas d'effet sur la disponibilité d'autres services. En revanche, la non-disponibilité d'un service dont dépendent plusieurs autres services (notamment Directory Server) a un impact plus important. Les spécifications relatives à une disponibilité élevée doivent clairement faire référence aux cas d'utilisation spécifiques et aux analyses d'utilisation nécessitant une disponibilité accrue.

Il peut s'avérer utile de répertorier les besoins de disponibilité selon un ensemble ordonné de priorités. Le tableau suivant classe par ordre priorité la disponibilité de divers types de services.

Tableau 3–4 Disponibilité des services par ordre de priorité

Priorité	Type de service	Description
1	Services essentiels	Il s'agit des services qui doivent être disponibles en permanence. Par exemple, les services de bases de données (tels les annuaires LDAP) pour les applications.
2	Disponibilité indispensable	Il s'agit des services qui doivent rester disponibles, mais dont les performances peuvent être réduites. Par exemple, il se peut que la disponibilité du service de messagerie ne soit pas fondamentale dans certains environnements de travail.
3	Possibilité de différer	Il s'agit de services dont la nécessité de disponibilité est limitée dans le temps. Par exemple, il se peut que la disponibilité des services de calendrier ne soit pas essentielle dans certains environnements de travail.
4	Facultatif	Il s'agit des services qui peuvent être différés sans limite de temps. Par exemple, dans certains environnements, les services de messagerie instantanée peuvent être considérés comme utiles mais pas obligatoires.

Panne de services

La conception de disponibilité prend également en considération ce qui se passe lorsque la disponibilité est compromise ou lorsqu'un composant est défectueux. Autrement dit, si un utilisateur connecté doit ou non redémarrer sa session et si une panne risque d'affecter d'autres zones du système. Les exigences de qualité de service doivent tenir compte de ces scénarios et indiquer comment le déploiement doit réagir face à ces situations.

Évolutivité

L'évolutivité correspond à la possibilité d'ajouter de la capacité à un système de sorte qu'il puisse accepter une charge supplémentaire provenant d'utilisateurs existants ou d'un accroissement de leur nombre. L'évolutivité requiert généralement davantage de ressources mais ne doit pas entraîner de modifications au niveau de la conception de l'architecture du déploiement ni de perte de service due au temps utilisé pour l'ajout de ressources.

Comme la disponibilité, l'évolutivité concerne certains services en particulier plutôt que la totalité du système. En revanche, pour les services dont dépendent d'autres services, tels Directory Server, l'évolutivité peut avoir un impact sur l'ensemble du système.

Il n'est pas nécessaire de mentionner les exigences d'évolutivité dans les exigences de qualité de service, sauf si l'extension du déploiement est clairement définie dans les exigences de l'entreprise. Cependant, lors de la phase de conception du déploiement de la solution, l'architecture de déploiement doit toujours prévoir une certaine tolérance pour la mise à l'échelle du système et ce, même dans le cas où aucune exigence en matière d'évolutivité n'a été indiquée.

Estimation du développement

L'estimation du développement d'un système en vue de déterminer les exigences d'évolutivité implique l'utilisation de projections et d'estimations aléatoires. Vous devez tenir compte des trois éléments ci-dessous pour dresser la liste des exigences liées à un système évolutif.

• Stratégie de conception hautes performances : au cours de la spécification des exigences de performances, indiquez une capacité latente afin de gérer les charges pouvant augmenter au fil du temps. Optimisez également la disponibilité en tenant compte des contraintes budgétaires. Cette stratégie vous permet de gérer le développement et de mieux planifier les jalons de la mise à l'échelle du système.

• Déploiement incrémentiel : le déploiement incrémentiel facilite la planification de l'ajout de ressources. Indiquez précisément chaque jalon de la mise à l'échelle du système. On appelle jalons les exigences de charge fixées à l'avance pour évaluer l'évolutivité.

• Contrôle complet de performance : le contrôle des performances permet de déterminer le moment où des ressources doivent être ajoutées au système. Les exigences en termes de contrôle des performances sont autant d'indications pour les opérateurs et administrateurs responsables de la maintenance et des mises à niveau.

Le tableau suivant répertorie les facteurs à prendre en considération pour la détermination des exigences d'évolutivité.

Tableau 3–5 Facteurs d'évolutivité

Facteur	Description
Analyse des types d'utilisation	En examinant les données existantes, vous pouvez comprendre les types d'utilisation des utilisateurs actuels ou prévus. En l'absence de telles données, analysez les données du secteur économique concerné ou les estimations du marché.
Conception pour une échelle maximale acceptable	Conception ayant pour objectif l'échelle maximale requise pour satisfaire les demandes connues et les demandes possibles.  Il s'agit généralement d'une estimation s'étalant sur 24 mois basée sur l'évaluation des performances de la charge utilisateur existante et des estimations acceptables en matière de charge à venir. La durée de l'estimation dépend fortement de la fiabilité des projections.
Définition de jalons appropriés	Implémentez la conception du déploiement par incrément afin de répondre aux exigences à court terme et utilisez pour cela une mémoire tampon qui puisse faire face à une éventuelle croissance. En outre, vous devez définir des jalons pour l'ajout de ressources système.   Par exemple :  Achat important (trimestriel ou annuel) Délai d'obtention de matériel et de logiciel (1 à 6 semaines) Mémoire tampon (10 à 100 %, selon les prévisions de croissance)
Intégration de nouvelles technologies	Il est nécessaire de s'imprégner des nouvelles technologies, telles que les processeurs et les serveurs Web plus rapides. Il faut également connaître la façon dont elles affectent les performances de l'architecture sous-jacente.

Exigences liées à la sécurité

La sécurité est un élément complexe qui intervient à tous les niveaux d'un système déployé. L'objectif principal du développement des exigences liées à la sécurité consiste à identifier les menaces de sécurité et à développer une stratégie pour les combattre. Cette analyse de sécurité se compose des étapes suivantes :

1. Identification des éléments critiques

2. Identification des menaces pesant sur ces éléments

3. Identification des failles de sécurité présentant un risque pour l'organisation

4. Développement d'un plan de sécurité afin de limiter les risques spécifiques à votre organisation

L'analyse des exigences de sécurité nécessite une collaboration de la part des parties prenantes de votre organisation, notamment les directeurs, les analystes d'exploitation et le personnel du service des technologies de l'information. Il arrive très souvent qu'une organisation désigne une personne responsable de la sécurité et chargée de la conception et de l'implémentation des mesures de sécurité.

La section suivante décrit quelques-uns des domaines abordés en matière de planification de la sécurité.

Éléments d'un plan de sécurité

La planification de la sécurité d'un système fait partie de la conception du déploiement et est essentielle à la réussite de l'implémentation. Vous devez tenir compte des points suivants lors de la planification de la sécurité :

• Sécurité physique : la sécurité physique concerne l'accès physique aux routeurs, aux serveurs, aux salles de serveurs, aux centres de données et à d'autres parties de votre infrastructure. Toutes les mesures de sécurité peuvent se révéler inutiles si une personne non autorisée pénètre dans la salle des serveurs et déconnecte les routeurs.

• Sécurité réseau : la sécurité réseau concerne l'accès à votre réseau par l'intermédiaire de pare-feux, les zones d'accès sécurisées, les listes de contrôle d'accès, ainsi que l'accès au port. Dans le cadre de la sécurité réseau, vous développez des stratégies contre les accès non autorisés, les falsifications et les attaques de refus de service.

• Sécurité des applications et des données d'application : la sécurité des applications et des données d'application traite de l'accès aux comptes utilisateur, aux données d'entreprise et aux applications d'entreprise par le biais de procédures et de stratégies d'authentification et d'autorisation. Les stratégies suivantes doivent être définies :

  • stratégies de mot de passe ;

  • droits d'accès, tels que l'administration déléguée aux utilisateurs par opposition à l'accès administrateur ;

  • inactivation du compte ;

  • contrôle d'accès ;

  • stratégies de chiffrement, y compris le transport sécurisé de données et l'utilisation de certificats pour la signature de données.

• Sécurité des personnes : la stratégie de sécurité d'une organisation définit l'environnement de travail et les exercices pratiques auxquels les utilisateurs doivent se conformer pour garantir l'exécution des autres mesures de sécurité. Il est généralement préférable de concevoir un manuel de sécurité et d'offrir une formation aux utilisateurs sur les exercices de sécurité. Des exercices de sécurité fiables doivent faire partie de la culture de votre organisation pour assurer une stratégie de sécurité globale efficace.

Capacité latente

La capacité latente correspond à l'aptitude d'un déploiement à faire face aux pics de charge inhabituels sans utiliser de ressources supplémentaires. Généralement, il n'est pas nécessaire de spécifier les exigences de qualité de service directement liées à la capacité latente. Cependant, cette dernière représente un facteur important en termes de disponibilité, de performances et d'évolutivité du système.

Exigences d'entretien

L'entretien est la facilité avec laquelle un système déployé peut être entretenu, englobant des tâches telles la surveillance du système, la résolution des problèmes, l'ajout et la suppression d'utilisateurs et la mise à niveau des composants matériels et logiciels.

Lors de la planification des exigences d'entretien, tenez compte des facteurs répertoriés dans le tableau suivant :

Tableau 3–6 Facteurs concernant les exigences d'entretien

Facteur	Description
Planification de l'interruption d'activité	Identification des tâches de maintenance entraînant l'indisponibilité totale ou partielle de services spécifiques.  Certaines opérations de maintenance et de mise à niveau peuvent être invisibles pour l'utilisateur, tandis que d'autres nécessitent une interruption de service. Lorsque cela est possible, planifiez avec les utilisateurs les activités de maintenance nécessitant une indisponibilité de service afin qu'ils puissent s'organiser en fonction.
Types d'utilisation	Identification des types d'utilisation en vue déterminer le moment le plus approprié pour la planification des opérations de maintenance.   Par exemple, programmez les opérations de maintenance en soirée ou en week-end pour les systèmes sur lesquels les pics d'utilisation se produisent pendant les heures de bureau classiques. Pour les systèmes distribués géographiquement, cette programmation peut s'avérer plus compliquée à mettre en place.
Disponibilité	L'entretien reflète généralement votre conception de disponibilité. Les stratégies visant à limiter les interruptions d'activité pour la maintenance et les mises à niveau sont liées à votre stratégie de disponibilité. Les systèmes ayant besoin d'un degré élevé de disponibilité ne disposent que de peu de temps pour la maintenance, les mises à niveau et les réparations.  Les stratégies de gestion des exigences de disponibilité se répercutent sur la manière dont vous gérez la maintenance et les mises à niveau. Par exemple, sur des systèmes distribués géographiquement, l'entretien peut dépendre de la possibilité d'acheminer des charges de travail vers des serveurs distants pendant les opérations de maintenance.  De plus, les systèmes nécessitant un degré de disponibilité élevé peuvent exiger la mise en place de solutions plus complexes automatisant au maximum le redémarrage des systèmes.
Diagnostics et contrôle	Vous pouvez améliorer la stabilité du système en exécutant régulièrement des outils de diagnostic et de contrôle pour identifier les zones problématiques.  Le contrôle régulier d'un système permet d'éviter les problèmes, de gérer des charges de travail selon les stratégies de disponibilité et d'améliorer la planification de la maintenance et des indisponibilités.

Exigences de niveau de service

Un contrat de niveau de service (SLA, Service Level Agreement) indique les performances minimales requises et, au cas où ces exigences ne seraient pas satisfaites, le niveau et l'étendue du support client devant être fourni. Les exigences de niveau de service correspondent aux exigences système indiquant les conditions du contrat.

Comme pour les exigences de qualité de service, les exigences de niveau de service reposent sur les exigences d'entreprise et constituent une garantie de qualité globale que le système déployé doit respecter. Les spécifications concernant les exigences de niveau de service doivent être claires, car il s'agit d'un contrat. Les exigences de niveau de service définissent avec exactitude les conditions sous lesquelles les exigences sont testées et définissent également les raisons pour lesquelles ces exigences ne sont pas satisfaites.