Be Wise Apps
Read in English · Leer en español · Auf Deutsch lesen
Section 1.5 sur 1.8 · Débutant · 18 min de lecture
Les parties prenantes, leurs préoccupations et comment l’architecture y répond
Leçon vidéo
5 min · narré en anglais, avec sous-titresÉcouter seulement (audio)
Lire la transcription
Tout système sert de nombreuses personnes, et elles ne veulent pas toutes la même chose. Cette leçon explique comment trouver ces personnes, comprendre ce qui les inquiète et traiter ouvertement les conflits.
Pensez à la construction d’une maison. La famille qui va y vivre veut de l’espace et de la lumière. La banque qui prête l’argent veut que la maison vaille le prêt. Le service d’urbanisme veut qu’elle s’intègre à la rue. Le constructeur veut des plans réellement réalisables, et les voisins ne veulent pas de bruit la nuit. Tous sont des parties prenantes, et ce qui inquiète chacun d’eux est une préoccupation. L’architecture est l’art de les écouter toutes, et de trancher ouvertement là où leurs souhaits se heurtent.
La norme internationale de description d’architecture définit largement une partie prenante : tout rôle, toute personne, toute organisation ou toute catégorie de ceux-ci, ayant un intérêt, un droit, une part ou une revendication dans le système. Une partie prenante est donc souvent une catégorie, comme les patients ou les ingénieurs d’astreinte. Et une revendication suffit : une autorité de régulation qui ne se connecte jamais reste une partie prenante, parce qu’elle peut vous empêcher d’exercer. Certaines parties prenantes ne sont jamais en réunion : les développeurs qui maintiendront le système dans cinq ans, les personnes en situation de handicap qui l’utiliseront, et le public touché par ses décisions. Une partie du travail de l’architecte consiste à parler en leur nom.
Ce qui compte pour une partie prenante est une préoccupation : toute question pertinente ou importante à ses yeux. Ce peut être une qualité, un coût, un risque, une contrainte, ou la capacité réelle de l’équipe à le construire. Les préoccupations ne sont pas encore des exigences. La crainte d’une autre panne comme celle de l’hiver dernier est une préoccupation. Une disponibilité de quatre-vingt-dix-neuf virgule neuf pour cent chaque mois est une exigence qui en découle. Consignez d’abord la préoccupation dans les mots mêmes de la partie prenante, puis affinez-la.
Avec vingt groupes ou plus, vous ne pouvez pas accorder à chacun la même attention. La matrice pouvoir/intérêt vous aide à planifier. Celle-ci concerne un système de réservation hospitalier. Le pouvoir est sur l’axe vertical, et l’intérêt sur l’axe horizontal. Pouvoir élevé mais intérêt faible : il faut les satisfaire. Ici, le directeur financier, le conseil d’administration de l’hôpital et les autorités de régulation. Pouvoir élevé et intérêt élevé : il faut les gérer de près. Le commanditaire, le responsable clinique, le délégué à la protection des données et le product owner. Faibles sur les deux axes : il suffit de les observer, comme le fournisseur de la passerelle SMS et les autres équipes informatiques de l’hôpital. Pouvoir faible, intérêt élevé : il faut les tenir informés. Et regardez qui se trouve ici : les patients et leurs aidants. Ils ont peu de pouvoir formel, mais ce sont eux qui ont le plus à perdre. La matrice guide donc l’implication, pas le poids des préoccupations.
Les préoccupations font le lien entre les personnes et l’architecture. Les parties prenantes ont des préoccupations. Ces préoccupations deviennent des exigences et des scénarios, orientent les décisions architecturales et déterminent les vues du système que vous dessinez. Puis vous faites une revue avec les parties prenantes : leurs préoccupations sont-elles traitées ? Un diagramme qui ne répond à la préoccupation d’aucune partie prenante n’est que de la décoration.
Dans l’exemple commenté, un hôpital veut que les patients prennent leurs rendez-vous en ligne. Les patients et leurs aidants veulent réserver facilement sur un téléphone, de façon accessible, donc l’interface doit respecter les normes d’accessibilité et ne nécessiter aucune app. Le personnel d’accueil craint les doubles réservations, donc le système d’administration des patients existant doit rester la source unique de vérité pour les créneaux de rendez-vous. L’exploitation s’inquiète des pics du lundi matin et de la capacité limitée de ce système. Elle veut une file d’attente ou un limiteur de débit devant lui, et mettre en cache les créneaux libres. Voilà le conflit. Le cache protège le système d’administration des patients, mais le personnel d’accueil craint des doubles réservations dues à des données périmées. La solution proposée : mettre les créneaux libres en cache pour l’affichage seulement, pendant trente secondes, mais confirmer chaque réservation auprès du système en temps réel. Remarquez que ce conflit clé opposait deux groupes discrets.
Ce genre de conflit est normal. Une architecture qui plaît à tout le monde signifie généralement qu’un conflit a été caché. Alors, d’abord, formulez précisément les deux préoccupations, pour que le débat porte sur des chiffres, pas sur des adjectifs. Présentez côte à côte les options et leurs conséquences. Ensuite, nommez qui décide, car certains compromis relèvent du commanditaire, pas de l’architecte, et consignez la décision et ses raisons. Souvent, demander à chaque camp ce qu’il craint vraiment révèle une conception qui satisfait les deux.
Voilà pour les parties prenantes et les préoccupations. La section complète contient un tableau des parties prenantes typiques et une méthode pas à pas pour les analyser. Ensuite, dans la section un point six, nous verrons comment peser les décisions et les compromis. À très vite.
Ce qu’il faut savoir
- Une partie prenante est tout rôle, toute personne, toute organisation ou toute catégorie de ceux-ci ayant un intérêt, un droit, une part ou une revendication dans un système, y compris des personnes qui ne l’utilisent jamais directement, comme les autorités de régulation et les exploitants.
- Une préoccupation, au sens de l’ISO/IEC/IEEE 42010, est toute question pertinente ou importante pour une partie prenante : qualités, coûts, risques, contraintes, faisabilité et questions d’organisation, tout compte.
- Les préoccupations ne sont pas encore des exigences : consignez-les dans les mots de la partie prenante, puis affinez-les en scénarios d’attributs de qualité mesurables, en contraintes ou en exigences fonctionnelles.
- La matrice pouvoir/intérêt aide à planifier l’implication de chaque partie prenante, mais elle ne dit rien de l’importance relative de leurs préoccupations ; des groupes qui ont peu de pouvoir peuvent avoir le plus à perdre.
- Les préoccupations contradictoires sont normales ; l’architecte les rend explicites, chiffre les options, désigne qui décide et consigne la justification.
- Les préoccupations structurent la documentation d’architecture : chaque point de vue encadre certaines préoccupations, et chaque vue montre comment le système y répond.
Qui sont les parties prenantes
Une partie prenante est toute personne qui a un intérêt légitime dans un système : celles qui l’utilisent, le paient, le construisent, l’exploitent, le réglementent ou sont touchées par lui. L’ISO/IEC/IEEE 42010 :2022, la norme internationale de description d’architecture, définit largement ce terme comme un rôle, une fonction, un individu, une organisation ou une catégorie de ceux-ci ayant un intérêt, un droit, une part ou une revendication dans la chose décrite. Deux caractéristiques de cette définition comptent en pratique. D’abord, une partie prenante est souvent une catégorie plutôt qu’une personne : « les patients » ou « les ingénieurs d’astreinte » plutôt qu’un individu nommé. Ensuite, une revendication ou un droit suffit : une autorité de régulation qui ne se connecte jamais à votre système reste une partie prenante, parce qu’elle peut vous empêcher d’exercer.
La liste est plus longue que la plupart des équipes ne le pensent. Pour un système commercial typique, elle comprend :
Les utilisateurs (les personnes qui se servent du logiciel au quotidien, souvent plusieurs groupes distincts) ; les clients (ceux qui paient, qui ne sont pas forcément utilisateurs) ; le product owner ou chef de produit, qui décide de ce qui est construit ; le commanditaire, qui finance le travail et répond de son succès ; les développeurs, qui doivent comprendre et modifier le code ; les testeurs, qui doivent pouvoir préparer des données et observer le comportement ; les équipes d’exploitation et les ingénieurs SRE (site reliability engineering), qui le déploient, le supervisent et le rétablissent à trois heures du matin ; l’équipe sécurité ; le délégué à la protection des données (DPD) lorsque des données personnelles sont traitées (en vertu du RGPD britannique et du RGPD de l’UE, certains organismes doivent en désigner un) ; les services juridique et achats, attentifs aux licences, aux contrats et à la responsabilité ; la finance, attentive aux coûts d’exploitation autant qu’aux coûts de construction ; les autorités de régulation et les auditeurs ; et les intégrateurs tiers, les autres équipes et entreprises dont le logiciel appelle le vôtre ou est appelé par lui.
Certaines parties prenantes sont absentes de toutes les réunions : les développeurs qui maintiendront le système dans cinq ans, le service d’assistance qui reçoit les plaintes, les personnes en situation de handicap qui utiliseront l’interface et les membres du public touchés par ses décisions. Une partie du travail de l’architecte consiste à parler au nom de ceux qui ne sont pas dans la salle.
Les préoccupations : ce qui compte pour les parties prenantes
Dans la 42010, une préoccupation est toute question pertinente ou importante pour une partie prenante. Le mot est volontairement large. Une préoccupation peut être une qualité (« la page de réservation restera-t-elle rapide le lundi matin ? »), un coût (« combien cela coûtera-t-il à exploiter par mois ? »), un risque (« que se passe-t-il si le fournisseur de SMS tombe en panne ? »), une contrainte (« les données des patients doivent-elles rester au Royaume-Uni ? »), une question de faisabilité (« notre équipe peut-elle construire cela avec les compétences dont elle dispose ? ») ou une question d’organisation (« quelle équipe est responsable de l’intégration avec le système des médecins généralistes ? »).
Les préoccupations ne sont pas encore des exigences. Elles sont généralement formulées de façon vague, dans le vocabulaire propre de la partie prenante, et ce sont souvent des inquiétudes plutôt que des spécifications. « Je ne veux pas d’une autre panne comme l’hiver dernier » est une préoccupation ; « le service de réservation est disponible 99,9 % de chaque mois civil, mesuré au niveau de l’équilibreur de charge » est une exigence qui en découle. Consigner d’abord la préoccupation dans les mots de la partie prenante, et seulement ensuite l’affiner, vous oblige à rester honnête sur l’origine d’une exigence et sur la raison de son importance.
Une même préoccupation est souvent partagée par plusieurs parties prenantes, et une partie prenante a généralement de nombreuses préoccupations. La sécurité est une préoccupation de l’équipe sécurité, du délégué à la protection des données, du commanditaire (qui craint les gros titres) et des patients (qui craignent une fuite de leur dossier). C’est précisément à cause de cette relation plusieurs-à-plusieurs que la 42010 fait des préoccupations la charnière entre les personnes et l’architecture : les décisions répondent aux préoccupations, et les vues s’organisent autour des préoccupations qu’elles traitent.
Parties prenantes typiques et leurs préoccupations
| Partie prenante | Préoccupations typiques | Ce que l’architecture doit leur apporter |
|---|---|---|
| Usagers | Rapidité, facilité d’utilisation, accessibilité, un système disponible quand on en a besoin | Objectifs de temps de réponse et de disponibilité ; une couche d’interface capable de respecter les normes d’accessibilité |
| Clients et commanditaires | Valeur métier, délai de mise sur le marché, coût total, risque pour la réputation | Un plan de livraison crédible, un modèle de coûts et une liste des principaux risques |
| Product owner | Vitesse d’ajout de nouvelles fonctionnalités, maintien des options ouvertes | Une structure modulaire alignée sur le domaine métier ; peu de décisions difficiles à inverser |
| Développeurs | Compréhensibilité, rapidité du build et des tests, responsabilités claires | Des frontières de modules nettes, un build local rapide, des conventions documentées |
| Testeurs | Testabilité, données de test maîtrisables, comportement observable | Des points de jonction où remplacer les dépendances ; des environnements de test proches de la production |
| Exploitation et SRE | Déployabilité, supervision, rétablissement, capacité, charge d’astreinte | Contrôles de santé, journaux, métriques et traces ; retour arrière sûr ; runbooks |
| Équipe sécurité | Surface d’attaque, identité, secrets, réponse aux vulnérabilités | Frontières de confiance, conception de l’authentification, stratégie de correctifs et de dépendances |
| Délégué à la protection des données | Base légale, minimisation des données, conservation, droits des personnes concernées, transferts | Un inventaire des données et une vue des flux de données ; des mécanismes d’effacement et d’export |
| Juridique et achats | Licences, contrats, responsabilité, dépendance au fournisseur | Une liste des composants et services tiers avec leurs conditions |
| Finance | Coût de construction, coût d’exploitation, prévisibilité des coûts | Un modèle de coûts par environnement et par unité d’utilisation |
| Autorités de régulation et auditeurs | Conformité aux règles du secteur, preuves de contrôle | Pistes d’audit, traçabilité de l’exigence au test, décisions documentées |
| Intégrateurs tiers | Interfaces stables, versionnage, documentation, environnements de test (sandbox) | Des contrats d’API publiés et une politique de versionnage |
Cartographier les parties prenantes : la matrice pouvoir/intérêt
Avec vingt groupes de parties prenantes ou plus, vous ne pouvez pas accorder à chacun la même attention. Un outil très utilisé est la matrice pouvoir/intérêt, généralement attribuée à Aubrey Mendelow, dont l’article sur les parties prenantes et la veille environnementale date de 1981 (il est souvent cité comme datant de 1991). Chaque partie prenante est placée selon le pouvoir qu’elle a sur le système (le financer, l’approuver, le bloquer ou le remodeler) et l’intérêt qu’elle lui porte. Les quadrants suggèrent une stratégie d’implication : gérer de près (pouvoir élevé, intérêt élevé), satisfaire (pouvoir élevé, intérêt faible), tenir informé (pouvoir faible, intérêt élevé) et observer (pouvoir faible, intérêt faible).
La matrice porte sur l’implication, pas sur la question de savoir quelles préoccupations comptent. Les patients d’un hôpital ont peu de pouvoir formel sur la conception d’un système de réservation, mais ce sont eux qui ont le plus à perdre, et certaines obligations légales (accessibilité, protection des données) existent précisément pour protéger les personnes qui ont peu de pouvoir. Voyez la matrice comme un rappel des personnes à consulter et de la fréquence, et formez-vous un jugement distinct sur les préoccupations critiques. Les positions bougent aussi : une autorité de régulation peu intéressée devient la partie prenante la plus intéressée de toutes la semaine qui suit une violation de données.
Une matrice pouvoir/intérêt pour un système de réservation hospitalier
Une analyse légère des parties prenantes
- IdentifierDressez la liste des catégories de parties prenantes avec le commanditaire et l’équipe, puis vérifiez-la par rapport à un ensemble type (utilisateurs, payeurs, bâtisseurs, exploitants, protecteurs, autorités de régulation, intégrateurs). Demandez à chaque groupe identifié : à qui d’autre devrions-nous parler ?
- Recueillir les préoccupationsMenez des entretiens ou des ateliers avec chaque groupe important. Consignez les préoccupations dans leurs propres mots, puis notez la qualité, la contrainte ou le risque qui se cache derrière chacune.
- Cartographier et hiérarchiserPlacez les parties prenantes sur la matrice pouvoir/intérêt pour planifier leur implication. Séparément, classez les préoccupations selon leur impact métier et selon la force avec laquelle elles contraignent l’architecture.
- Rendre les conflits explicitesLorsque deux préoccupations tirent dans des directions opposées, mettez le conflit par écrit, nommez les personnes qui doivent se mettre d’accord et convenez de qui décide.
- Tracer et revisiterReliez chaque décision importante aux préoccupations qu’elle traite, et refaites l’analyse aux grands jalons, car les parties prenantes et leurs préoccupations changent.
Les préoccupations contradictoires et comment les rendre explicites
Les préoccupations entrent sans cesse en conflit, et une architecture qui plaît à tout le monde signifie généralement qu’un conflit a été caché plutôt que résolu. L’équipe sécurité veut que chaque connexion soit protégée par une authentification multifacteur ; la représentante des patients fait remarquer que de nombreux patients âgés n’ont pas de smartphone. La finance veut un seul petit serveur de base de données ; l’exploitation veut une réplique de secours dans un second centre de données. Le product owner veut une nouvelle fonctionnalité chaque semaine ; les testeurs veulent du temps pour faire les tests de non-régression de l’intégration avec le système d’administration des patients de l’hôpital.
La contribution de l’architecte n’est pas de désigner discrètement un gagnant, mais de rendre le conflit visible, chiffré et assumé par quelqu’un. En pratique, cela signifie quatre choses. Formuler précisément les deux préoccupations, idéalement sous forme de scénarios testables, pour que le débat porte sur des chiffres plutôt que sur des adjectifs. Présenter côte à côte les options et leurs conséquences : par exemple, la MFA pour le personnel et pour les patients qui la choisissent, avec en solution de repli un code à usage unique envoyé par SMS ou par appel sur une ligne fixe. Nommer la personne qui décide : certains compromis relèvent du commanditaire ou d’un comité des risques, pas de l’architecte. Consigner la décision et sa justification, pour que, lorsque quelqu’un demandera dans deux ans pourquoi les patients peuvent se connecter sans MFA, la réponse existe. La section suivante, Décisions et compromis, explique comment peser de telles options.
Certains conflits se dissipent quand on les examine de près. L’équipe sécurité n’a peut-être pas besoin de la MFA pour toutes les actions des patients, seulement pour la consultation des résultats d’examens ; le groupe de patients peut très bien l’accepter à cet endroit. Demander à chaque camp pourquoi il a cette préoccupation, et quel résultat il craint vraiment, révèle souvent une conception qui satisfait les deux.
Où vont les préoccupations
Comment les préoccupations alimentent les exigences et la documentation
Les préoccupations sont la matière première de deux activités ultérieures. La première est l’ingénierie des exigences. Une préoccupation de rapidité devient une exigence d’attribut de qualité, que le chapitre 2 vous apprend à rédiger sous forme de scénario mesurable (source, stimulus, artefact, environnement, réponse et mesure de la réponse) : voir Rédiger des scénarios d’attributs de qualité. Une préoccupation comme « les données des patients doivent rester au Royaume-Uni » devient une contrainte, une décision déjà prise à votre place. Les préoccupations qui s’avèrent sans effet sur la structure du système restent de simples exigences fonctionnelles ou exigences de projet.
La seconde est la documentation. La 42010 organise une description d’architecture autour des préoccupations : un point de vue nomme les préoccupations qu’il encadre et les parties prenantes qu’il sert, et une vue applique ce point de vue à votre système. Les préoccupations de l’équipe d’exploitation appellent une vue de déploiement montrant les serveurs, les régions et le basculement ; celles du délégué à la protection des données appellent une vue des flux de données montrant où les données personnelles circulent et où elles sont stockées ; les développeurs ont besoin d’une vue des modules montrant ce qui dépend de quoi. Un diagramme qui ne répond à la préoccupation d’aucune partie prenante n’est que de la décoration. Le chapitre 4 traite ce sujet en détail dans Vues et points de vue.
La traçabilité relie les deux. Si vous pouvez suivre un fil depuis une partie prenante, en passant par une préoccupation, jusqu’à une exigence, une décision et une vue, vous pouvez répondre aux deux questions que tout relecteur finit par poser : pourquoi est-ce construit ainsi, et avons-nous oublié quelqu’un ?
Exemple commenté
Exemple commenté : les parties prenantes d’un système hospitalier de prise de rendez-vous
Un groupement hospitalier régional veut un système en ligne permettant aux patients de prendre, modifier et annuler leurs rendez-vous de consultation externe, en remplacement de la prise de rendez-vous par téléphone. Il doit s’intégrer au système d’administration des patients (PAS) existant et envoyer des rappels par SMS. Voici la première analyse des parties prenantes qu’un architecte pourrait produire au cours des deux premières semaines.
| Patients et aidants | Préoccupations : réserver facilement sur un téléphone, accessibilité (lecteurs d’écran, grands caractères), rappels, confidentialité. Impact sur l’architecture : une interface web adaptative (responsive) conforme au niveau AA des WCAG 2.2 ; aucune app à installer ; un minimum de données affichées à l’écran. |
|---|---|
| Accueil et personnel clinique | Préoccupations : pas de doubles réservations, des listes de consultations conformes à la réalité, moins d’appels téléphoniques. Impact : le PAS reste la source unique de vérité pour les créneaux ; le système de réservation ne doit pas en détenir sa propre copie, qui pourrait diverger. |
| Resp. clinique | Préoccupations : les demandes urgentes ne doivent pas être évincées par les rendez-vous de routine ; sécurité clinique. Impact : des règles de créneaux gérées par les cliniciens et configurables sans nouvelle mise en production ; un dossier de sécurité clinique (en Angleterre, selon la norme DCB0129) couvrant le système. |
| Délégué à la protection des données | Préoccupations : les données de santé relèvent des catégories particulières de données au sens du RGPD britannique (UK GDPR) ; minimisation ; conservation ; audit. Impact : une vue des flux de données, le chiffrement en transit et au repos, des journaux d’audit indiquant qui a consulté quoi, une politique de conservation. |
| Équipe d’exploitation | Préoccupations : les pics du lundi matin, la capacité limitée du PAS, le support en dehors des heures ouvrées. Impact : une file d’attente ou un limiteur de débit devant le PAS ; une mise en cache de la disponibilité des créneaux avec une expiration courte ; une supervision des temps de réponse du PAS. |
| Dir. financier | Préoccupations : budget fixe, coût d’exploitation prévisible, économies sur le personnel du centre d’appels. Impact : des services cloud managés dimensionnés pour le pic ; un modèle de coûts pour mille réservations. |
| Fournisseur du PAS (intégrateur) | Préoccupations : aucune charge non prise en charge sur son système ; utilisation de sa seule interface publiée. Impact : une intégration via l’interface du fournisseur avec des limites de débit convenues ; une suite de tests de contrat. |
| Principal conflit identifié | L’exploitation veut mettre en cache la disponibilité des créneaux pour protéger le PAS ; le personnel d’accueil craint des doubles réservations dues à des données périmées. Solution proposée : un cache pour l’affichage seulement (30 secondes), mais une confirmation de chaque réservation auprès du PAS en temps réel, avec un message clair si le créneau vient d’être pris. |
Sept groupes de parties prenantes ont produit au moins cinq décisions aux conséquences structurelles (source unique de vérité, limitation de débit, journalisation d’audit, règles configurables, interface accessible) avant qu’aucune fonctionnalité n’ait été conçue en détail.
Le conflit le plus lourd de conséquences opposait deux groupes discrets, l’exploitation et le personnel d’accueil, dont aucun n’aurait dominé un comité de pilotage.
Chaque ligne peut être reliée, en aval, à un scénario d’attribut de qualité, à un enregistrement de décision et à une vue, et en amont à une catégorie de personnes nommée.
Questions fréquentes
L’équipe de développement est-elle vraiment une partie prenante ? C’est nous qui le construisons.
Oui. Les développeurs vivent avec l’architecture plus longtemps que presque tout le monde, et leurs préoccupations (temps de build, testabilité, responsabilités claires) se traduisent directement en vitesse de livraison. La définition de la 42010 ne fait aucune distinction entre ceux qui construisent et ceux qui utilisent.
Quelle est la différence entre une préoccupation d’une partie prenante et une exigence ?
Une préoccupation est l’intérêt sous-jacent, souvent vague (« je veux que ce soit fiable »). Une exigence est un énoncé précis et vérifiable, dérivé d’une ou de plusieurs préoccupations (« 99,9 % de disponibilité mensuelle »). Plusieurs exigences peuvent servir une même préoccupation, et certaines préoccupations deviennent plutôt des contraintes.
Qui décide quand deux parties prenantes puissantes ne sont pas d’accord ?
En général, pas l’architecte seul. L’architecte formule les options et leurs conséquences ; la décision revient à la personne responsable du résultat, typiquement le commanditaire ou une instance de gouvernance. Convenir à l’avance de qui tranche quel type de compromis épargne des semaines de discussions.
Vérifiez votre compréhension
Citez trois parties prenantes d’un système commercial typique qui assistent rarement aux réunions de conception.
Par exemple : les développeurs qui le maintiendront dans les années à venir, le service d’assistance, les utilisateurs en situation de handicap, les équipes d’exploitation d’astreinte la nuit, et les membres du public touchés par ses décisions.
Un commanditaire dit : « Il faut que ce soit sécurisé. » Est-ce une préoccupation ou une exigence ?
Une préoccupation. Elle doit être affinée en exigences précises et testables, par exemple sur l’authentification, le chiffrement ou la journalisation d’audit, avant de pouvoir guider les décisions.
Pourquoi une même préoccupation, comme la sécurité, peut-elle appartenir à plusieurs parties prenantes à la fois ?
Parce que des personnes différentes craignent des conséquences différentes d’une même qualité : l’équipe sécurité craint les attaques, le délégué à la protection des données craint les violations de données personnelles, le commanditaire craint l’atteinte à la réputation et les utilisateurs craignent la fuite de leurs données.
Qu’est-ce qui relie une préoccupation d’une partie prenante à une vue d’architecture ?
Un point de vue : il indique quelles préoccupations et quelles parties prenantes il sert et comment les modéliser, et la vue l’applique au système.
Sources et lectures complémentaires
Une question sur cette section ? ArchitectBot, l’assistant d’étude IA du cours, répond d’abord à partir du cours.
Demander : « Comment trouver les parties prenantes qui me manquent, et que faire quand deux d’entre elles veulent des choses opposées ? »