vlaskos/brief-to-architecture

Analyse des ASR (Exigences Architecturalement Significatives)

Un brief n'est pas une spécification. C'est un tas de souhaits, d'hypothèses et de contraintes à moitié formulées, et, enfouies à l'intérieur, se trouvent les quelques exigences qui détermineront réellement la forme et le coût du système. Cette compétence les trouve, les rend précises et les vérifie les unes par rapport aux autres avant que quiconque ne s'engage sur une estimation ou une conception.

Une exigence architecturalement significative (ASR) est une exigence qui a un effet mesurable sur l'architecture : la satisfaire force un choix structurel, contraint une technologie, fixe une barre de qualité difficile à atteindre, ou interagit avec d'autres exigences d'une manière qui limite vos options. La plupart des exigences d'un brief ne sont pas architecturalement significatives. Le travail consiste à séparer les quelques-unes vitales des nombreuses autres, et à expliquer pourquoi chacune est importante.

Le volet attribut de qualité de ce travail s'ancre dans l'ISO/IEC 25010, le modèle international de qualité de produit logiciel. L'utilisation d'un ensemble standard de caractéristiques de qualité garantit que l'analyse est complète (vous vérifiez les mêmes dimensions à chaque fois) et donne à tous un vocabulaire commun. Voir references/quality-model.md.

Le pipeline

Exécutez un brief en six étapes. Chacune produit un artefact utilisé par la suivante.

1. Extrayez, ne transcrivez pas. Lisez l'entrée brute et extrayez les véritables exigences, y compris celles énoncées comme des fonctionnalités, des plaintes ou des remarques anodines. Une phrase comme « notre trafic du Black Friday est 40 fois supérieur à la normale » n'est pas une demande de fonctionnalité ; c'est une exigence de performance et de scalabilité déguisée. Interprétez. Voir references/asr-framework.md pour savoir comment reconnaître ce qui est architecturalement significatif.

2. Classez. Triez chaque exigence extraite dans l'un des trois seaux :

   • Fonctionnelle — ce que le système doit faire.
   • Attribut de qualité — à quel point il doit le faire (performance, fiabilité, sécurité, maintenabilité, …). Utilisez les caractéristiques ISO/IEC 25010 pour couvrir le même terrain à chaque fois — references/quality-model.md.
   • Contrainte — une limite fixe et non négociable (une technologie imposée, une réglementation, une échéance, un système existant). Les contraintes ne sont pas sujettes à conception ; elles façonnent tout le reste.

3. Affinez. Réécrivez chaque exigence significative pour qu'elle soit sans ambiguïté et testable, et énoncez son implication architecturale — la conséquence structurelle de la prendre au sérieux. Supprimez les solutions que l'auteur a introduites (« utiliser Kafka » est un mécanisme proposé, pas une exigence ; l'exigence est le débit ou le découplage derrière). Une exigence que vous ne pouvez pas tester, vous ne pouvez pas l'estimer.

4. Priorisez sur deux axes. Toutes les ASR ne méritent pas la même attention. Classez chacune sur :

   • Valeur métier — à quel point le résultat est important pour le client.
   • Impact architectural — à quel point elle contraint la conception et combien il coûte de revenir en arrière. (Un impact élevé concerne l'irréversibilité et le rayon d'explosion, pas l'effort.) Les exigences qui sont élevées sur les deux sont celles où l'architecture est vraiment décidée. Consacrez-y votre analyse. Voir references/scenarios-and-priorities.md.

5. Vérifiez la faisabilité. Avant de concevoir quoi que ce soit, vérifiez que les exigences hautement prioritaires peuvent coexister. Les briefs les plus dangereux sont intérieurement contradictoires : un objectif de latence, un objectif de cohérence et un plafond de coût qui ne peuvent pas tous être vrais en même temps. Voir references/feasibility-check.md pour une méthode concrète, incluant l'arithmétique pour les exigences numériques.

6. Spécifiez les scénarios et choisissez les stratégies. Pour les attributs de qualité hautement prioritaires, rédigez des scénarios de qualité mesurables (un déclencheur, les conditions et une réponse que vous pouvez mesurer), puis choisissez les stratégies de conception qui satisferaient chacun, avec leur coût. Voir references/scenarios-and-priorities.md et references/design-strategies.md.

Discipline qui rend l'analyse digne de confiance

• Repérez les signes faibles. Les briefs ont des schémas d'échec récurrents : superlatifs vagues, hypothèses cachées, nombres sans unité ni source, exigences qui se contredisent. references/brief-smells.md en est un catalogue avec ce qu'il faut demander lorsque vous en voyez un.
• Marquez chaque hypothèse. Lorsque le brief est silencieux et que vous comblez un vide, étiquetez-le : s'agit-il d'un vide comblé (information manquante, vous avez fourni une valeur par défaut), d'une interprétation (ambiguë, vous avez choisi une lecture), ou d'un rétrécissement de périmètre (vous avez délibérément exclu quelque chose) ? Une estimation construite sur des hypothèses non étiquetées est une hypothèse déguisée en costume.
• Terminez par les questions qui changent la donne. Le résultat d'une bonne analyse inclut les deux ou trois questions dont les réponses changeraient le plus l'architecture. Ce sont elles qui devraient guider la prochaine conversation avec le client.
• Une estimation n'est aussi défendable que l'analyse qui la sous-tend. C'est pourquoi l'analyse vient en premier : c'est ce qui rend le chiffre que vous donnez au client quelque chose que vous pouvez défendre.

Comment utiliser cette compétence

• Analyser un brief de bout en bout → exécutez le pipeline en six étapes ci-dessus.
• Décider ce qui est architecturalement significatif → references/asr-framework.md.
• Choisir et couvrir les attributs de qualité → references/quality-model.md (ISO/IEC 25010).
• Rédiger des scénarios de qualité testables et les prioriser → references/scenarios-and-priorities.md.
• Choisir des approches de conception par attribut de qualité → references/design-strategies.md.
• Détecter les contradictions et les combinaisons impossibles → references/feasibility-check.md.
• Lire un brief de manière critique → references/brief-smells.md.
• Façonner le livrable écrit → references/output-template.md.