Qu’est-ce que le modèle d’exigences pour l’API ?
Un modèle collaboratif de planification d’API qui aide les équipes produit, d’ingénierie et d’architecture à définir les besoins en matière d’API avant le début du développement. L’atelier se déroule en cinq étapes : collecte des informations sur l’API, analyse de l’impact architectural, création d’histoires utilisateur, documentation des exigences techniques et des dépendances, et élaboration d’une feuille de route de livraison.
Quel problème le modèle d’exigences pour l’API résout-il ?
Exigences d’API incomplètes
Besoins d’intégration peu clairs
Contexte architectural manquant
Décalage entre les besoins des utilisateurs et les besoins techniques
Dépendances cachées
Alignement insuffisant entre les équipes produit et ingénierie
Séquençage de la mise en œuvre peu clair
Comment utiliser le modèle d’exigences d’API
Commencez par rassembler les informations sur l’API, les parties prenantes, les systèmes et les besoins métier.
Examinez l’impact architectural et cartographiez les connexions entre les systèmes, les services et les intégrations.
Rédigez des user stories décrivant ce dont les utilisateurs, les systèmes ou les équipes internes ont besoin de l’API.
Documentez les exigences techniques, les dépendances, les besoins en matière de sécurité, les considérations sur les données et les contraintes d’intégration.
Terminez en organisant les exigences dans une feuille de route avec priorités, jalons et séquençage de la mise en œuvre.
Pièges courants
Commencer le développement avant que l’objectif de l’API soit clair
Documenter les points de terminaison sans comprendre les besoins des utilisateurs
Ignorer l’analyse d’impact architectural
Ignorer les dépendances entre systèmes
Exigences de sécurité ou de données manquantes
Rédiger des histoires utilisateur trop techniques
Construire une feuille de route sans priorités claires
Façons d’éviter les erreurs
Définissez l’objectif de l’API avant de discuter de la mise en œuvre.
Incluez les perspectives produit, ingénierie, architecture et sécurité.
Reliez les histoires utilisateur aux exigences techniques.
Cartographiez les dépendances avant de prioriser le travail.
Documentez les hypothèses et les questions non résolues.
Examinez tôt les besoins en matière de sécurité, d’authentification, de données et de performance.
Ordonnez les éléments de la feuille de route en tenant compte des dépendances et de la valeur métier.
Fonctionnalités Miro à utiliser
Cadres pour chaque étape de l’atelier
Notes pour les exigences et les questions ouvertes
Diagrammes d’architecture pour les relations entre systèmes
Tableaux pour les histoires utilisateur et les exigences techniques
Étiquettes pour indiquer la priorité, les dépendances et le propriétaire
Commentaires pour les discussions d’ingénierie
Code couleur pour les catégories d’exigences
Connecteurs pour les flux architecturaux
Formes de la feuille de route pour les jalons et les versions
FAQ
Q. : Qui peut bénéficier de ce modèle ?R. : Chefs de produit, ingénieurs logiciels, architectes, développeurs d’API, équipes de sécurité, équipes d’intégration, responsables techniques et équipes produit interfonctionnelles.
Q. : Quand utiliser ce modèle ?R. : Utilisez-le avant de créer une nouvelle API, d’étendre une API existante, de planifier une intégration ou de revoir l’architecture d’une API.
Q. : Le modèle inclut-il des user stories ?R. : Oui. Une étape est dédiée à la traduction des besoins API en user stories avant la finalisation des exigences techniques.
Q. : Quels types d’exigences techniques peuvent être consignés ?R. : Authentification, autorisation, points de terminaison, formats de données, intégrations, dépendances, performance, gestion des erreurs, surveillance et besoins techniques associés.
Q : Le modèle peut-il prendre en charge les API internes et externes ?A : Oui. Il peut être utilisé pour les services internes, les intégrations partenaires, les API publiques et les API de plateforme.
Q : Avec quoi repartiront les participants ?A : Un objectif d’API documenté, une vue de l’impact architectural, des récits utilisateur, des exigences techniques, des dépendances et une feuille de route de mise en œuvre priorisée.
