J'ai écrit une base de données d'exigences il y a 6 ou 7 ans pour gérer cela. Chaque enregistrement d'exigence a une courte description, un mémo "définition" et un mémo "notes" (tous deux en texte riche, avec possibilité d'incorporer des captures d'écran, etc.). Il existe également d'autres champs, pour le projet, le livrable, le numéro de séquence (afin qu'ils puissent être commandés logiquement), le cas d'utilisation / la fonctionnalité auquel il est lié, l'estimation du temps, un champ pour la personne qui le gère, si quelqu'un l'a sélectionné pour la mise en œuvre, etc.
Il y a aussi un "Statut" - "Entré", car pendant que nous concevons les fonctionnalités; «Approuvé», défini une fois qu'un groupe d'exigences est examiné et déterminé comme prêt à être mis en œuvre; "Implémenté", défini par le programmeur une fois qu'il pense que l'exigence est remplie, et "Validé" une fois que la technologie QA est d'accord avec le programmeur. (Si la technologie QA n'est pas d'accord, il peut la remettre à "Approuvé" pour que le programmeur le récupère.) Les exigences peuvent également être "différées", "rejetées" ou "remises en question" (ce qui signifie que la carte de contrôle des changements doit la regarder). .)
L'astuce pour bien faire cela est une granularité raisonnable. Il peut parfois être judicieux d'avoir des exigences d'une seule phrase (par exemple, «le problème décrit dans le problème 12345 est résolu»), mais en général, les exigences doivent décrire tous les aspects importants d'une fonctionnalité entière (ou une grande partie de celle-ci). Par exemple, une fonctionnalité typique de "nouveau rapport" aura une exigence pour un format de rapport (à quoi ressemble la sortie), et une exigence pour la boîte de dialogue des options (expliquant les champs, la validation, etc.) Il pourrait même y en avoir une troisième si il y a un générateur complexe qui croque les données, plutôt qu'une simple requête ou quelque chose. De plus, nous allons créer une exigence "Aide" pour la rubrique d'aide correspondante.
Il y a d'énormes avantages à conserver ces éléments dans des enregistrements de base de données plutôt que dans un gros document. Plusieurs programmeurs peuvent travailler sur les exigences en même temps. Les enregistrements individuels sont verrouillés de sorte qu'une seule personne peut les modifier à la fois, mais ils peuvent être ouverts et lus pendant que quelqu'un d'autre les modifie. Le plus grand avantage est cependant qu'il permet de rechercher facilement dans la documentation à la fois les exigences et les notes sur la façon dont elles ont été mises en œuvre. Nous avons maintenant plus de 25 000 exigences, et nous pouvons facilement trouver toutes les exigences avec des mots spécifiques dans tous les domaines, ou la définition, ou des notes, ou autre, en moins de 10 secondes. (Essayez cela avec plus de 6 ans de documents Word.)
Je peux voir pourquoi les gens pourraient dire que c'est une mauvaise idée de faire des exigences dans un "bug tracker", mais je suppose que c'est parce que les outils sont nuls, pas parce que garder les exigences dans une base de données consultable est une mauvaise idée.