Un bon plan de publication transforme le code prêt en impact client. Avec Trupeer, vous pouvez gagner des heures sur la planification des releases en commençant par un modèle gratuit de cahier des exigences de release, en le personnalisant avec vos directives de marque, puis en transformant les plans de release en mises à jour vidéo qui alignent l’ingénierie, le QA, le support et les clients.

Qu’est-ce qu’un modèle gratuit de cahier des exigences de release ?

Un modèle gratuit de cahier des exigences de release est une structure réutilisable pour énoncer tout ce qui doit être vrai avant qu’une release donnée puisse être déployée.

L’expression tout ce qui doit être vrai fait un travail délibéré ici. La plupart des documents de ce type listent ce que le produit doit faire, puis s’arrêtent. C’est une spécification fonctionnelle. Une exigence de release est plus large : c’est toute condition dont l’absence devrait empêcher la release, et une grande partie de ces conditions n’a rien à voir avec le code.

Le modèle n’est pas les exigences. Il vous donne un tableau, que vous construisez en quelques minutes. Ce qui détermine si une release se passe bien, c’est de savoir si quelqu’un a pensé à écrire que le support doit être formé, que le rapport de facturation doit avoir une nouvelle colonne, ou que le rollback n’a jamais été réellement exécuté.

La forme suit l’usage. Un fichier Excel de modèle gratuit de cahier des exigences de release convient au tableau des exigences, qui constitue l’essentiel du document et est réellement tabulaire. Une version Word d’un modèle gratuit de cahier des exigences de release convient aux sections narratives, à l’énoncé du périmètre et à la validation. Un modèle gratuit de cahier des exigences de release au format PDF est la version jointe au dossier de release.

Les exigences de release ne sont pas des exigences produit

Il faut les distinguer clairement, car les deux finissent par être fusionnées, et c’est cette fusion qui provoque l’omission.

Les exigences produit décrivent ce que fait l’objet. Rédigées avant ou pendant le développement, portées par le produit, et répondant à la question de ce que nous construisons. Un document d’exigences produit ou un document d’exigences métier couvre ce terrain, et les deux sont rédigés une fois par zone produit plutôt qu’une fois par release.

Les exigences de release décrivent ce qui doit être vrai pour que cette release spécifique puisse être livrée. Rédigées avant la release, portées par la personne responsable, et répondant à la question de savoir si nous pouvons y aller. Elles incluent les exigences produit de tout ce qui est dans cette release, et elles incluent aussi beaucoup d’autres éléments.

La distinction compte, car les deux documents ont des modes d’échec différents. Un document d’exigences produit échoue en étant ambigu : la mauvaise chose est construite. Un document d’exigences de release échoue en étant incomplet : la bonne chose est livrée à une organisation qui n’est pas prête.

Si vous cherchez le premier cas, vous voulez un document d’exigences plutôt que celui-ci. Si vous êtes sur le point de livrer quelque chose, poursuivez.

Comment personnaliser ce modèle dans Trupeer

Étape 1 : Ouvrir la section Modèles

Accédez à la section Modèles depuis la navigation principale.

Étape 2 : Sélectionner et ouvrir un modèle

Cliquez sur n’importe quel modèle avec lequel vous souhaitez travailler pour l’ouvrir.

Étape 3 : Développer l’aperçu du modèle

Si nécessaire, développez l’aperçu du modèle pour voir clairement la mise en page complète et les détails.

Étape 4 : Modifier le modèle

Cliquez sur Modifier pour commencer à modifier le modèle sélectionné.

Dans l’éditeur, vous pouvez :

• Ajouter de nouvelles sections

• Définir ou mettre à jour des règles de mise en forme

• Ajouter un logo et ajuster sa position ainsi que les paramètres associés

Étape 5 : Enregistrer votre modèle personnalisé

Après avoir effectué toutes les modifications nécessaires, cliquez sur Enregistrer pour stocker le modèle mis à jour comme le vôtre.

Étape 6 : Prévisualiser et affiner le modèle

Lorsque vous souhaitez voir à quoi ressemble votre modèle personnalisé, ouvrez la Prévisualisation.

Depuis l’écran de prévisualisation, vous pouvez continuer à effectuer des ajustements directement si nécessaire, afin de garantir que le modèle apparaît exactement comme vous le souhaitez.

Avec un modèle de cahier des exigences de release, vous pouvez :

• Gagner du temps sur la planification : évitez la page blanche grâce à une structure conçue pour les releases.

• Réduire le risque de release : des sections intégrées pour les tests, le rollback et les dépendances.

• Rester conforme à votre marque : appliquez votre logo, vos polices et vos couleurs avec le brand kit de Trupeer.

• Communiquer les releases clairement : transformez les plans en mises à jour vidéo pour les équipes transverses.

• Standardiser d’une release à l’autre : utilisez le même modèle pour chaque release.

• Toucher des équipes internationales : traduisez les plans de release en 65+ langues en un clic.

Les exigences qui bloquent une release ne concernent généralement pas le produit

Prenez la dernière release qui s’est mal passée dans votre organisation et demandez-vous ce qui a réellement mal tourné.

Dans la plupart des cas, le logiciel fonctionnait. Ce qui a échoué, c’était quelque chose de connexe. Le support ne savait pas que la fonctionnalité existait. Le centre d’aide décrivait encore l’ancien comportement. La tarification n’était pas configurée dans le système de facturation. L’équipe commerciale ne pouvait pas la chiffrer. La migration a bien été lancée, mais personne n’avait testé le rollback. Le juridique n’avait pas revu le changement des conditions. L’e-mail annonçant la release est allé au mauvais segment.

Chacune de ces situations est une exigence de release. Aucune n’est une exigence produit, et aucune n’apparaîtra dans un document rédigé par les personnes qui ont construit la fonctionnalité, car chacune relève de quelqu’un d’autre.

C’est la cause structurelle. Les exigences produit sont rédigées par le produit et l’ingénierie, qui sont compétents et rigoureux dans leur domaine, mais n’ont aucune visibilité sur le rapport de rapprochement de facturation. Ainsi, le document est complet concernant ce qui est construit, mais silencieux concernant l’organisation qui le reçoit.

La correction consiste à scinder le document en deux et à donner un poids égal à la seconde moitié. Exigences produit : ce que cela doit faire. Exigences de préparation : ce qui doit être vrai ailleurs avant que cela puisse être déployé. Dans une release mature, la deuxième liste est généralement plus longue que la première, ce qui surprend les gens la première fois qu’ils l’écrivent.

Ce qu’un modèle de cahier des exigences de release doit contenir

Huit éléments. La section de préparation est celle qui distingue ce document d’une simple liste de fonctionnalités.

La colonne bloquante est celle qui change le comportement. Marquer les exigences comme bloquantes ou non bloquantes à l’avance force le débat à avoir lieu une semaine plus tôt, quand il s’agit d’une discussion, plutôt qu’au moment du go/no go, quand c’est une négociation sous pression temporelle avec tout le monde déjà engagé sur la date.

Modèle gratuit de cahier des exigences de release : la structure à copier

Rempli avec un exemple réel plutôt que des placeholders. La release introduit un nouveau niveau de tarification basé sur l’usage dans un produit logiciel métier.

Copiez depuis ici.

Identité de la release. Nom, version, date cible, et exclusions explicites.

Niveau basé sur l’usage. Release 4.9. Date cible : 14 octobre. Non inclus : migration des clients existants vers le nouveau niveau, qui suit en 4.10, et le flux de mise à niveau en libre-service, qui est reporté.

Exigences produit.

Exigences de préparation. La moitié qui est laissée de côté.

Huit exigences de préparation contre quatre exigences produit. Ce ratio est normal et c’est l’objectif du document.

Rollback. Ce qui se passe si cela tourne mal.

Le feature flag désactive le nouveau niveau à l’inscription dans les cinq minutes, sans affecter les inscriptions existantes. La mesure continue d’enregistrer, mais aucun frais n’est appliqué. Rollback exécuté en préproduction le 7 octobre par A Bellamy, pas seulement documenté. La décision de rollback revient au responsable d’astreinte de l’ingénierie sans nécessiter d’approbation.

Validation. Release autorisée conjointement par le responsable produit et le responsable support, sur la base du tableau complété avec chaque exigence bloquante marquée comme vérifiée. Aucune confirmation verbale.

Copiez depuis ici.

Exemple d’exigences de release : trente-quatre exigences respectées et neuf cents tickets

Merrivale Software, une société de logiciels métier comptant environ quatre mille clients, a déployé un nouveau niveau de tarification basé sur l’usage.

Le document d’exigences de release listait trente-quatre exigences. Chacune était fonctionnelle, chacune a été respectée, chacune a été testée, et la release a été livrée à la date cible. Selon la norme à laquelle l’équipe se mesurait, tout s’est parfaitement déroulé.

Le volume de tickets support la première semaine était de neuf cents, contre une base normale d’environ deux cent dix.

Trois éléments avaient été omis du document, et les trois appartenaient à quelqu’un en dehors de l’équipe qui l’a rédigé.

Le centre d’aide décrivait encore les anciens plans : le support a donc répondu à des questions en utilisant des éléments erronés, avec assurance, pendant quatre jours.

Le rapport de rapprochement de facturation ne comportait aucune catégorie pour le nouveau niveau : quarante et un clients ont été facturés au tarif historique pendant deux mois avant que quelqu’un ne s’en rende compte. Soixante-deux mille livres sous-facturées, et le recouvrement auprès de clients à qui l’on avait déjà expliqué ce qu’ils devaient était une conversation désagréable qui a endommagé plusieurs comptes.

L’outil de chiffrage commercial ne pouvait pas produire un devis pour le nouveau niveau : onze deals ont donc été vendus avec des devis construits manuellement contenant trois structures différentes, dont deux ne correspondaient pas à ce que le produit faisait réellement.

L’examen a révélé que personne n’avait commis d’erreur au sens habituel. Le document avait été rédigé par le produit et l’ingénierie, de manière approfondie, sur ce qu’ils construisaient. Personne dans cette salle ne savait que le rapport de rapprochement existait.

Ce que Merrivale a changé, ce n’est pas la rigueur du document, mais sa forme. Deux sections au lieu d’une. Exigences produit et exigences de préparation. Et une règle : une exigence de préparation n’est pas complète tant qu’elle n’a pas un responsable nommé en dehors de l’ingénierie, qui y a consenti.

La release suivante comptait dix-neuf exigences produit et vingt-trois exigences de préparation. Le volume de tickets pendant la semaine de release était de deux cent quarante, contre une base de deux cent dix.

La deuxième liste a pris environ quatre-vingt-dix minutes à rédiger, lors d’une réunion incluant le support, la finance et les ventes. C’est toute l’intervention.

Comment rédiger des exigences de release en six étapes

1. Indiquez ce qui est inclus dans la release et ce qui ne l’est pas. Les exclusions évitent l’argument le plus courant au moment de la validation : quelque chose que tout le monde supposait inclus.

2. Rédigez les exigences produit pour qu’elles puissent être vérifiées. Voir la section suivante.

3. Obtenez les exigences de préparation auprès des personnes qui en sont responsables. Ne pas les imaginer. Mettez le support, la finance, les ventes, le juridique et les opérations dans une salle pendant quatre-vingt-dix minutes et demandez ce qui se casse pour eux si cela est déployé.

4. Donnez à chaque exigence un responsable nommé et une méthode de vérification. Une exigence non vérifiée est une intention.

5. Marquez dès maintenant les exigences bloquantes ou non bloquantes. Le faire à l’avance transforme une négociation en décision.

6. Testez le rollback plutôt que de le documenter. Un plan de rollback qui n’a jamais été exécuté est une hypothèse, et la nuit de la release est un mauvais moment pour le tester.

L’étape trois est l’exercice complet, et quatre-vingt-dix minutes suffisent réellement pour la plupart des releases. Les personnes responsables des exigences de préparation savent ce qu’elles sont, sans préparation, car ce sont elles qui souffrent quand elles manquent.

Comment rédiger une exigence qui peut être vérifiée

La plupart des défauts d’exigences ne sont pas des omissions, mais des ambiguïtés, et ils prennent un petit nombre de formes.

Adjectifs de degré. Rapide, intuitif, fiable, scalable. Ce sont des évaluations sans échelle. Remplacez-les par un nombre et une condition : répond dans les deux secondes à cinquante utilisateurs simultanés.

Obligations passives sans acteur. Le rapport doit être mis à jour. Par qui, et comment quelqu’un saura que cela a été fait. Chaque exigence nomme un responsable.

Exigences composées. Tout ce qui contient « and » correspond généralement à deux exigences qui seront à moitié remplies. Séparez-les, car une seule ligne ne peut pas être vérifiée à moitié.

Exigences formulées comme des solutions. Ajoutez une liste déroulante sur la page des paramètres. Cela spécifie une implémentation et masque l’exigence réelle, qui est que l’utilisateur doit pouvoir modifier quelque chose. Les solutions appartiennent au design, pas aux exigences, sauf si la solution est réellement l’exigence pour une raison qui mérite d’être énoncée.

Le test pratique consiste à lire chaque ligne et à se demander quelle preuve trancherait un désaccord sur le fait que l’exigence est remplie. Si vous ne pouvez pas nommer cette preuve dans une phrase, l’exigence n’est pas terminée.

Variantes du modèle d’exigences de release

La structure reste la même, et la liste de préparation change considérablement.

Release logicielle. L’exemple ci-dessus. La préparation est dominée par le support, la documentation, la facturation et la communication, et l’élément le plus souvent manqué est tout ce qui touche à l’argent.

Release d’application mobile. Ajoute des délais de validation de l’App Store, qui sont externes et imprévisibles, ainsi que le fait que les utilisateurs sur les anciennes versions restent pendant des mois. La compatibilité descendante devient une exigence plutôt qu’une simple courtoisie.

Release de matériel ou de produit physique. Ajoute la préparation à la fabrication, l’emballage, les pièces de rechange, la distribution et la gestion des retours. Les délais de production signifient que les exigences de préparation doivent être satisfaites bien plus tôt que pour un logiciel.

Release réglementée. Dispositifs médicaux, produits financiers, produits pharmaceutiques, systèmes critiques pour la sécurité. Le contenu et les preuves sont fréquemment imposés, l’autorité de validation est définie en externe, et les enregistrements doivent survivre à un audit. Rien sur cette page ne remplace la norme applicable, et toute release dans un secteur réglementé doit être menée sous votre système qualité avec une revue qualifiée.

Lancement marketing ou de campagne. La partie produit se réduit et la préparation s’étend. Les assets, la revue juridique, la planification des canaux, le tracking, et la capacité de la personne qui répond au téléphone à en parler.

Release de système interne. La préparation est presque entièrement de la formation, des accès et des parcours de support, et la tentation de la sauter est la plus forte parce que le public est constitué de collègues plutôt que de clients. Les releases internes produisent une part disproportionnée de perturbations évitables pour exactement cette raison.

Exigences de release, PRD, BRD ou document d’exigences ?

Ces termes sont recherchés de façon interchangeable et couvrent des terrains différents ; il vaut donc la peine de nommer celui dont vous avez besoin avant d’adopter un modèle.

Un document d’exigences métier indique ce dont l’entreprise a besoin et pourquoi, en termes métier. Rédigé tôt, porté par le côté business, et largement exempt de détails d’implémentation.

Un document d’exigences produit indique ce que le produit doit faire pour répondre à ces besoins. Porté par le produit, rédigé par zone produit ou par initiative.

Une spécification d’exigences fonctionnelles ou logicielles décrit le comportement en détail, de façon suffisante pour construire et tester. Portée par l’ingénierie ou l’analyse métier.

La collecte des exigences est l’activité qui produit les trois premiers éléments. Un modèle Excel de collecte des exigences en téléchargement gratuit est un outil de capture : source, partie prenante, besoin, priorité, statut, et il ne s’agit pas d’un document de release.

Les exigences de release sont le verrou de livraison. Elles s’appuient sur tout ce qui précède pour ce qui est inclus dans cette release, et elles ajoutent la moitié de préparation que les autres ne couvrent pas.

Les résultats de recherche pour les exigences de release renverront le plus souvent les quatre autres, car le terme est moins établi. Si ce dont vous avez réellement besoin est une spécification de comportement, utilisez un modèle de document d’exigences au format Word et travaillez dans cette tradition. Si vous devez décider si vous pouvez livrer, cette page est la bonne. Les limites du périmètre pour le travail plus large se trouvent dans le périmètre du projet.

Qui valide une release et que signifie « terminé »

Deux signatures, pas une, et elles doivent représenter des intérêts différents.

La première correspond à la personne responsable du bon fonctionnement du produit. La seconde correspond à la personne responsable de la capacité de l’organisation à s’en sortir, ce qui est généralement le support ou les opérations. Une release autorisée uniquement par les personnes qui l’ont construite n’a pas de contrôle indépendant sur la préparation : c’est précisément le manque que la section de préparation vise à combler.

La validation se fait sur la base de preuves, plutôt que sur la confiance. Chaque exigence bloquante marquée comme vérifiée, avec la méthode de vérification enregistrée. Une exigence marquée « terminé » par la personne responsable, sans pièce jointe, est une auto-déclaration.

Animez la réunion à partir du tableau des exigences lui-même, ou à partir d’une vue PowerPoint d’un modèle gratuit de cahier des exigences de release générée à partir de celui-ci, jamais à partir d’un deck maintenu séparément. Tenez-la suffisamment tôt pour qu’un « non » soit actionnable. Une réunion tenue l’après-midi avant la release ne peut qu’approuver, car à ce moment-là, le coût d’un arrêt est plus élevé que celui de la plupart des problèmes. Deux jours ouvrés suffisent généralement pour rendre une décision réelle possible.

Les verrous qualité et les preuves de tests se trouvent à côté dans le plan QA, qui couvre comment la vérification elle-même est assurée.

Ce qu’un modèle gratuit de cahier des exigences de release ne peut pas corriger

Une équipe qui n’a jamais demandé aux autres fonctions ce dont elles ont besoin. Le modèle fournit une section. La remplir nécessite une discussion, et aucun téléchargement gratuit de modèle de cahier des exigences de release ne fera cette discussion à votre place.

Une date qui ne peut pas bouger. Si la release sort quoi qu’il arrive, le document d’exigences devient un enregistrement plutôt qu’un verrou. C’est un choix légitime, parfois, et il faut le dire plutôt que le prétendre autrement.

Un modèle qui ne couvre que la moitié produit. Chaque téléchargement gratuit de modèle de cahier des exigences de release Word que j’ai vu fait exactement cela : prévoyez donc d’ajouter vous-même la section de préparation.

Une validation sans autorité pour dire non. Un verrou qui n’a jamais arrêté quoi que ce soit n’est pas un verrou.

Une documentation qui n’existe pas. Les briefings support et les mises à jour du centre d’aide sont les exigences de préparation les plus souvent marquées non bloquantes, non pas parce qu’elles n’ont pas d’importance, mais parce que les produire coûte cher. C’est un problème de coût plutôt qu’un problème de priorité, et il est traité ci-dessous.

Montrer le changement plutôt que le décrire

Deux exigences de préparation apparaissent sur presque toutes les listes de release et sont presque toujours celles qui glissent : documentation mise à jour, et support briefé.

Elles glissent pour une raison pratique plutôt que culturelle. Rédiger un article du centre d’aide pour un parcours modifié, capturer les captures d’écran, les mettre à jour à nouveau quand le design change avant le lancement, puis brief l’équipe support : ce sont plusieurs jours de travail, qui tombent dans la semaine où tout le monde est le plus occupé. Du coup, cela est marqué non bloquant, et la release sort avec un support qui répond à partir de supports décrivant l’ancien comportement.

Trupeer AI change le coût de tout cela. Quelqu’un parcourt une fois le nouveau parcours en enregistrant, et le résultat est un article écrit avec des captures d’écran déjà capturées et placées, ainsi qu’une vidéo, dans votre branding. L’article va dans le centre d’aide. La vidéo est le briefing support. Les deux sont produits en un temps qui, auparavant, servait uniquement à rassembler les captures d’écran.

Enregistrez-le. Marquez-le. Traduisez-le. Trupeerisez-le.

Deux conséquences comptent spécifiquement pour les releases. Quand le parcours change tard, ce qui arrive, refaire l’enregistrement est plus rapide que modifier, donc la documentation peut être régénérée plutôt qu’abandonnée. Et lorsque vous accompagnez des clients dans plusieurs langues, le même enregistrement produit le même article dans chacune, de sorte qu’une release ne sort pas documentée dans une seule langue et non prise en charge dans les autres.

Le contenu se trouve dans votre base de connaissances et sert aussi de formation pour le support et les ventes. Une fois que la documentation est suffisamment peu coûteuse pour être produite au sein d’un cycle de release, elle peut être marquée bloquante, c’est-à-dire là où elle doit être. La cohérence avec vos autres documents se fait en définissant le brand kit une seule fois, et la configuration est couverte dans le guide de configuration du modèle de document.

Questions fréquentes

Existe-t-il une version Excel gratuite du modèle d’exigences de release ?

Excel convient mieux à ce document que la plupart des autres, car son cœur est un tableau avec un responsable, une méthode de vérification et un indicateur bloquant par ligne, et vous voudrez pouvoir le filtrer.

Créez le fichier Excel du modèle gratuit d’exigences de release avec les exigences produit et de préparation comme un seul tableau, avec une colonne de type plutôt que deux feuilles. Les garder au même endroit rend le ratio visible, et le ratio est la chose la plus informative de la page.

Existe-t-il une version Word gratuite du modèle d’exigences de release ?

Word convient mieux à la narration environnante : ce qui est inclus dans la release, ce qui est exclu, le plan de rollback et la validation. Créez le fichier Word du modèle gratuit d’exigences de release avec les tableaux d’exigences intégrés et gardez les exclusions sur la première page.

Si la liste d’exigences est longue, conservez-la dans un tableur et faites-y référence depuis le document plutôt que de maintenir deux copies. Le document est ce que les gens lisent, et le tableur est ce avec quoi ils travaillent.

Existe-t-il un téléchargement gratuit du modèle d’exigences de release au format Word ?

Ce que fournit un téléchargement gratuit du modèle d’exigences de release au format Word, c’est une liste de sections, et il contiendra presque certainement uniquement la moitié produit. Presque tous les modèles publiés traitent les exigences comme une spécification fonctionnelle.

Ajoutez la section de préparation manuellement. Support, documentation, facturation, ventes, juridique, opérations et communication, chacun avec un responsable nommé en dehors de l’équipe de livraison. Cette addition prend dix minutes et fait la différence entre une liste de fonctionnalités et un verrou de release.

Existe-t-il une version Word d’un modèle de document d’exigences ?

Oui, et c’est un document différent de celui-ci. Un fichier Word de modèle de document d’exigences précise ce qu’un produit ou un système doit faire, avec suffisamment de détails pour construire et tester, et il est rédigé par initiative plutôt que par release.

Utilisez-en un si vous définissez un comportement. Utilisez un document d’exigences de release si vous devez décider si vous pouvez livrer. Le second s’appuie sur le premier et ajoute tout ce que le premier ne couvre pas.

Où puis-je trouver un modèle Excel de collecte des exigences en téléchargement gratuit ?

La collecte des exigences consiste à recueillir les besoins auprès des parties prenantes, et un téléchargement gratuit de modèle Excel de collecte des exigences est un outil de capture : source, partie prenante, besoin, priorité, statut.

C’est vraiment utile au début d’un travail et ce n’est pas un document de release. Si vous collectez, utilisez-en un. Si vous êtes sur le point de livrer, vous avez besoin à la place des colonnes de vérification et de préparation, que les modèles de collecte ne possèdent pas.

Existe-t-il un modèle d’exigences de release PDF gratuit ?

Le PDF est la version signée et archivée. Une fois que chaque exigence bloquante est vérifiée et que la release est autorisée, exportez un modèle gratuit d’exigences de release au format PDF avec les noms de validation et la date, puis joignez-le au dossier de release.

Cela compte plus que pour la plupart des documents, car la question de ce qui a été convenu avant une release est posée bien plus souvent après qu’une release a mal tourné qu’avant.

Existe-t-il une version PowerPoint gratuite du modèle d’exigences de release ?

Les slides conviennent à la réunion go/no go plutôt qu’au document. Un deck PowerPoint d’un modèle gratuit d’exigences de release montrant les exigences bloquantes, leur statut et les éléments restants est une bonne façon de mener une décision en quinze minutes.

Générez-le à partir du tableau plutôt que de le maintenir séparément. Un deck qui s’est écarté de la liste d’exigences est pire qu’un deck inexistant, car c’est la version que les gens retiennent.

Existe-t-il un téléchargement gratuit du modèle d’exigences de release qui vaut la peine d’être utilisé ?

La structure du tableau vaut environ dix minutes à construire vous-même, ce qui est moins de temps que d’évaluer un téléchargement gratuit de modèle d’exigences de release.

Si vous en adoptez un, vérifiez deux points. S’il prévoit une place pour des exigences portées en dehors de l’équipe de livraison, et s’il distingue les exigences bloquantes des non bloquantes. Presque aucun modèle publié ne contient l’un ou l’autre, et ces deux colonnes portent la majeure partie de la valeur.