Quelle est la bonne façon de créer des documents d'exigences?

En ce moment, mon superviseur crée pour moi des documents / spécifications sur les exigences à l'aide d'un logiciel de suivi des bogues. Cela me semble une idée terrible, toutes les exigences sont sur ces petits billets et je dois cliquer sur ce formulaire Web stupide pour obtenir les exigences. Qu'est-ce qu'une solution logicielle saine pour les exigences / spécifications logicielles?

Pour être clair, je construis ce grand composant logiciel avec pas mal de fonctionnalités et ces fonctionnalités sont présentées dans ce logiciel de suivi des bogues.

Je suis plutôt surpris que personne n'ait jusqu'à présent recommandé l'utilisation d'un wiki pour suivre les exigences.

J'ai trouvé que c'était un système presque parfait, car:

• Il permet aux gens de collaborer sur les exigences et rend cet aspect très visible;
• Il vous permet de maintenir facilement les exigences à jour au fur et à mesure de l'avancement du projet;
• Vous pouvez entrer et voir l'historique à tout moment, en cas de différend "ce n'est pas ce que nous avons convenu";
• La plupart des wikis modernes ont des capacités de mise en forme décentes, donc ils semblent presque aussi bons qu'un document Word;
• Vous pouvez créer un lien hypertexte directement à partir de vos besoins dans la documentation réelle;
• Vous n'avez jamais à vous soucier des personnes travaillant sur des copies différentes / obsolètes;
• Les exigences peuvent commencer à être traitées comme un processus itératif, tout comme la conception / mise en œuvre;
• Si les exigences commencent à devenir très importantes / compliquées, il est facile de les répartir entre les pages / sujets.
• La plupart des wikis acceptent le HTML, donc si vous avez vraiment besoin d'un formatage avancé, vous pouvez probablement utiliser un outil comme Windows Live Writer .

Étant donné le choix, je choisis presque toujours la méthode wiki de nos jours, c'est vraiment assez indolore par rapport aux documents Word à l'ancienne ou en essayant de tout entasser dans un traqueur de bogues.

J'utilise toujours IEEE Std 830-1998 (IEEE Recommended Practice for Software Requirements Specifcations) comme modèle pour mon document SRS. Voir http://standards.ieee.org/reading/ieee/std_public/description/se/830-1998_desc.html

Le document SRS final lui-même est généralement un seul document OpenOffice.org, mais il y a généralement de nombreuses parties constitutives qui y entrent, y compris des feuilles de calcul et des diagrammes.

Je rassemble généralement tous ces documents dans un référentiel que je mets dans un système de contrôle de révision , comme SVN ou CVS. Tous les autres analystes commerciaux, concepteurs, développeurs, testeurs, chefs de projet et clients ont accès à ce référentiel, afin qu'ils puissent le lire et y apporter des modifications.

N'oubliez pas que le SRS est un document vivant et évolutif. Il continuera de changer et de croître pendant un certain temps. Non seulement il est important que toutes les parties prenantes aient accès au SRS, mais il est également important d'avoir un historique complet des changements et la possibilité de les annuler également, si nécessaire. Un système de contrôle des révisions fonctionne donc très bien à cette fin. Bonne chance!

L'utilisation du bug-tracker pour la gestion des exigences a tendance à masquer le manque de collaboration et de communication au sein de l'entreprise.

Sans porter de jugement sur une méthode particulière:

• si vous allez utiliser une cascade, vous avez besoin de documents multipages bien structurés et précis (pas un paragraphe que beaucoup de gens tapent généralement comme description de bogue). Ces documents sont également impossibles à écrire et à maintenir à un niveau de qualité décent si le marketing / les vendeurs (qui sont à l'origine des exigences) ne travaillent pas bien avec le personnel d'ingénierie.
• si vous allez utiliser l'une des méthodes agiles, alors une unité d'exigences est une histoire d'utilisateur, représentée par une carte d'histoire. La carte elle-même n'est pas une exigence, seulement un point de départ de la conversation.

Une expérience (brève) d'un de mes anciens employeurs avec l'utilisation d'un bug-tracker pour les exigences a été qu'il a donné à beaucoup de gens un moyen très facile d'arrêter de communiquer complètement. Les gens écrivaient simplement un souhait, le vidaient dans le bug-tracker et supposaient qu'il se réaliserait finalement.

Bien sûr, ils l'ont fait sans tenir compte de:

• leurs propres qualifications
• leur participation au projet
• est en conflit avec d'autres exigences
• lacunes dans les exigences
• frais
• toute considération technique
• etc.

Je pense que les documents "Word" sont la mauvaise voie à suivre pour les exigences, pour les raisons suivantes:

1. Aucun moyen de "différencier" deux documents pour voir ce qui a changé.
2. L'interface utilisateur décourage l'utilisation d'un style cohérent tout au long. Oui, utiliser des styles peut être fait, mais la plupart des gens ne peuvent pas être dérangés à cause de la difficulté.
3. Le format du document est essentiellement masqué. Bien sûr, il existe une spécification pour les fichiers OLE, ce que je suppose que les documents "Word" sont, mais Microsoft a enterré tout ce qui est utile sous des tonnes de blather, donc personne ne le sait vraiment. Tôt ou tard, votre nouveau "Word" brillant n'ouvrira pas le document.
4. Ne joue pas bien avec d'autres formats. Autrement dit, sauf si vous utilisez Windows et IE, vous n'avez pas de chance si quelqu'un organise les documents d'un projet dans des fichiers HTML avec des liens vers des fichiers au format "Word". Cliquez sur le mauvais lien, et vous devez vous asseoir pendant une longue période de téléchargement et de démarrage de Word, interrompant le flux de la pensée. Les hyperliens des documents "Word" vers d'autres peuvent ou non fonctionner.
5. "Word" est essentiellement destiné à la rédaction de documents destinés à apparaître sur papier. Un objectif admirable, mais qui le rend moins qu'utile pour la visualisation en ligne.

Je n'ai pas d'autre suggestion avec laquelle j'ai de l'expérience, mais j'ai pensé au texte restructuré de Python ou au Markdown comme alternatives.

Nous utilisons généralement Word, mais en réalité, la façon dont vous les créez dans les logiciels est moins importante que la façon dont vous collectez les données pour les créer et si la personne qui recueille les informations en sait suffisamment pour savoir quand une exigence est trop compliquée et sera beaucoup plus chère que une exigence plus simple, mais n'ajoutant aucune valeur réelle à quiconque (comme quand ils veulent que les numéros d'identification soient toujours attribués dans l'ordre sans qu'aucun ne soit ignoré) ou quand cela entrera en conflit avec une exigence existante ou une autre fonctionnalité planifiée. Souvent, les utilisateurs réels ne sont jamais contactés et il y a de nombreuses surprises lorsque leurs gestionnaires ne savaient pas quelque chose qui devait absolument être fait et ce n'est pas dans la nouvelle version du logiciel.

Nous pouvons également utiliser divers fichiers pdf, Excel ou Visio. Tous pour le projet sont collectés et modifiés à partir de SharePoint, afin que nous puissions voir les versions antérieures si nécessaire.

Je gère un backlog de produit (un par projet ou produit) contenant des User Stories . Ils peuvent être stockés dans un logiciel de suivi des bogues comme celui que vous utilisez. J'utilise personnellement Excel pour le backlog et Trac pour le backlog de sprint (vous utilisez probablement un outil comme cet outil).

Lorsque requis uniquement, je crée un document Word qui décrit la User Story avec plus de détails et je l'attache à la User Story. Mais j'essaie d'éviter cela en divisant la user story en plus petites.

Les petites histoires d'utilisateurs sont plus faciles à gérer (y compris l'estimation)

J'aime le document Word car il me permet de mettre des liens, de formater des textes, de mettre des tableaux, des captures d'écran et plus encore, et tout le monde peut le lire.

Bien sûr, chaque User Story est expliquée en détail dans la session d'estimation et la planification du sprint, et je suis toujours disponible pour plus de questions lorsque le développeur décide d'y travailler. Les retours fréquents à l'aide de la revue de sprint empêchent les développeurs de faire quelque chose de différent de celui demandé par le propriétaire du produit.

Personnellement, dans le passé, j'ai utilisé des documents Word, mais j'ai résolu de trouver un outil à l'avenir pour gérer cela pour moi ... en particulier avec la possibilité de définir des bogues selon les exigences, car la plupart du temps, le bogue est dans les exigences, pas l'écart entre les spécifications et la mise en œuvre.

Il ne m'est même jamais venu à l'esprit d'utiliser un outil de suivi des bogues, mais c'est tout à fait logique.

Par curiosité, qu'est-ce que vous n'aimez pas?

EDIT: une mise en garde; dites à votre responsable de renommer le logiciel de suivi des bogues. Sinon, tout est supposé être un bug. J'ai eu ce problème politique chez mon dernier client, où j'ai mis des tâches dans le traqueur de bogues. Pas bon.

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.

J'ai utilisé une fois http://www.pivotaltracker.com/ mais dans mon entreprise actuelle, nous utilisons .doc comme source de spécification principale et Lighthouse comme liste de fonctionnalités et suivi des problèmes. Pour moi, il est difficile de faire en sorte que d'autres membres de l'équipe commencent à utiliser d'autres outils alors qu'ils sont tellement habitués à Word.

Si vous pouvez suivre la méthodologie Agile, les liens suivants peuvent vous guider dans le choix d'un bon outil de gestion de projet Agile:

• Outils de gestion de projet Agile
• Comparaison de différents outils de gestion de projet Agile

Et sérieusement, essayez la méthodologie Agile - elle prêche une approche sensorielle simple, élégante, sans fioritures, non jazzy et commune dans tout ce que vous faites, de sorte que chaque membre de l'équipe comprenne et apprécie le rôle et les efforts de tous les autres membres.

Bonne chance!