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


24

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.

Réponses:


18

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'ai trouvé que vous pouvez incorporer relativement facilement des données de votre système de suivi dans votre wiki, et si vous configurez des bogues hiérarchiques, vous pouvez les regrouper dans l'exigence, alors les jalons du projet ont des pages wiki, tout comme les projets et les clients et tout est facile à comprendre. Le wiki est la colle, mais utilise toujours un traqueur de bogues. Examinez la capacité de votre traqueur de bogues à pointer vers une page Web sur le wiki!
Tim Williscroft

Absolument, un wiki ne remplace pas un système de suivi de bogues, il est complémentaire. La planification et la collaboration du projet sont mieux effectuées sur le wiki; les problèmes doivent encore être suivis sur un IMS ou une file d'attente prioritaire.
Aaronaught

6

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!


5

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.

MAIS ... une fois que l'exigence incomplète est entrée, elle serait attribuée, et quiconque à qui elle est attribuée doit résoudre toute information incomplète, n'est-ce pas? Je veux dire une fois qu'il est dans le système, en supposant que les gens ne déposent pas d'articles, cela ne devrait-il pas être résolu? Je ne suggère pas qu'un profane de logiciel complet devrait entrer des éléments, mais même s'ils l'ont fait .. il est dans le système et doit être géré. Exemple: l'entreprise ajoute l'exigence «imprimer le reçu» dans le suivi des bogues et l'attribue à l'analyste de bus, l'analyste de bus le traite en remplissant les trous (via plus de communication si nécessaire), puis le développeur l'obtient.
John MacIntyre

Une panne de communication ne serait-elle pas le symptôme d'un problème de processus? (sincérité voulue)
John MacIntyre

@JohnMacIntyre (1): le résultat est du ping-pong au lieu de la collaboration. Le cessionnaire n'est pas toujours la bonne personne, les problèmes rares peuvent être résolus par une seule personne; là où davantage de personnes sont nécessaires, le cessionnaire a rarement le pouvoir de leur dire quoi faire, voit rarement toutes les dépendances (les exigences sont rarement indépendantes); perdu sont les avantages de l'auto-organisation, la priorisation par le retour sur investissement ou le coût du retard, etc.
azheglov

@JohnMacIntyre (2): la rupture de la communication est bien sûr un signe que leur processus ne fonctionne pas ou qu'ils n'ont aucun processus ou qu'ils n'ont tout simplement pas une saine culture de communication et de collaboration dans leur entreprise. Ma position est qu'ils devraient s'attaquer à ces causes profondes.
azheglov

@asheglov - Je suppose que cela pourrait être un problème si le cessionnaire est le réalisateur et n'est pas autorisé à réaffecter ou à parler à quiconque. Mais ma position est que ce n'est pas l'outil, et que cela se produirait avec les meilleurs outils n'est-ce pas?
John MacIntyre du

2

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.


1
Je pense que la plupart de ces arguments ressemblent à du FUD. Word n'est peut-être pas le meilleur choix, mais ce n'est pas si mal: 1. Il a de très bonnes fonctionnalités de révision / collaboration pour le suivi et l'acceptation / le rejet des modifications, à mon avis beaucoup plus convivial que tous les outils vcs + diff. 2. Les styles sont plus importants depuis l'interface utilisateur du ruban de 2007. Il est probablement plus facile d'expliquer pourquoi les styles doivent être utilisés que d'expliquer un tout nouveau logiciel 3. Le dernier Word peut lire / enregistrer des fichiers Word 97 créés il y a 16 ans. Word 2003 peut lire / enregistrer des fichiers 2010 à l'aide de packs de compatibilité. Je suis d'accord avec 4. et 5. bien que le pdf puisse être une option pour la visualisation en ligne.
kapex

@kapep - mes arguments ne sont pas FUD dans le sens classique de "Peur, Incertitude et Doute", vous utilisez peut-être "FUD" d'une manière différente. On peut répondre à chacun de mes arguments. Par exemple, vous pouvez dire "Do control-shift- @ dans le menu" Insertion "pour obtenir un diff ligne par ligne du document actuel contre un autre document". Cela ne peut pas être fait, car tout ce que vous avez proposé était une contre-opinion. Microsoft a l'habitude d'abandonner les formats de documents, ou du moins de rendre coûteux ou difficile l'utilisation d'anciens formats, ce qui augmente les ventes de mises à niveau, j'imagine.
Bruce Ediger

Ok je dois me corriger, seulement 3. semble être un argument FUD qui est souvent utilisé quand il s'agit de dénigrer word / doc pour être propriétaire. Bien sûr, Microsoft a abandonné les formats - mais les fichiers doc existent depuis très longtemps, donc `` tôt ou tard '' ne s'applique qu'aux versions archaïques du siècle dernier, s'ils décident de supprimer le support en> 2016 ou chaque fois que le prochain mot sera publié. Je voulais également souligner qu'il existe un moyen simple de "diff" les documents. Bien sûr, il ne s'agit pas de comparer ligne par ligne, cela n'aurait pas beaucoup de sens dans un format non basé sur une ligne. Cela ressemble plus au diff en ligne ici sur SE.
kapex

2

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.


1

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.


1

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.


1

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.


1
Il existe des logiciels de suivi des exigences commerciales, tels que DOORS.
M. Dudley

1

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.


0

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:

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!

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.