Reqflow est un outil open-source, sous licence GPL v2+, de traçabilité d'exigences entre documents. Ce genre de traçabilité s'avère utile dès que la taille d'un projet devient conséquente : plusieurs centaines d'exigences.
J'avais plusieurs fois cherché et mentionné le besoin d'un tel outil open-source et, ne trouvant rien, je l'ai réalisé.
NdM : merci à goeb pour son journal.
Sommaire
Reqflow
Le concept d'exigence
Pour résumer le concept d'exigence à ceux qui n'en ont pas l'habitude, une exigence (requirement en anglais) est typiquement une fonctionnalité, décrite en quelques lignes. De cette exigence peuvent découler :
- des exigences plus fines, décrivant comment on va réaliser la fonctionnalité
- des tests, qui décrivent comment la vérifier sur le produit fini.
On dit que les exigences en aval couvrent les exigences en amont.
L'intérêt de décrire un système par exigences est de fragmenter la complexité en portions de dimensions réduites, plus faciles à maîtriser humainement (comprendre, discuter, vérifier, tester). Cela oblige également à synthétiser les documents de spécifications. On a trop souvent vu des documents de plusieurs centaines de pages verbeux, imprécis, et confus. Pour bien travailler avec les exigences, il faut que ceux qui écrivent les spécifications aient dès le début une approche par exigence, ce qui n'est malheureusement pas toujours le cas.
La manière de travailler ensuite peut grossièrement se résumer ainsi : on vérifie qu'on n'a oublié aucune exigence en réalisant le système.
Les entreprises industrielles qui conçoivent de gros systèmes (véhicules, avions, etc.) utilisent la fragmentation en exigences pour définir et réaliser leurs systèmes.
Exemple de spécification
Prenons l'exemple d'un logiciel de navigation Internet qui souhaite se conformer à la norme CSS2 (dans la vraie vie, les navigateurs web ne s'encombrent pas de traçabilité d'exigences, car c'est un procédé coûteux qui n'est pas justifié pour ce genre de logiciel non critique).
Le document de spécification est donc la norme CSS2, extrait :
15.6 Font boldness: the 'font-weight' property
'font-weight'
Value: normal | bold | bolder | lighter | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900 | inherit
The 'font-weight' property selects the weight of the font. The values '100' to '900' form an ordered sequence, where each number indicates a weight that is at least as dark as its predecessor. The keyword 'normal' is synonymous with '400', and 'bold' is synonymous with '700'.
Ici, il n'y a pas de marqueur d'exigence dédié. Donc, on prend le numéro du paragraphe "15.6" pour cet exemple (mais ce n'est pas une manière très rigoureuse de procéder et il va être difficile pour l'outil de traçabilité de capturer les exigences).
Et on code le navigateur web, avec ses petites mains. Pendant ce temps un testeur va écrire le plan de test, comme ceci :
Exemple de plan de test
T_FONT_01
1. écrire une page HTML utilisant un mot avec font-weight 'normal'
2. vérifier que le navigateur affiche ce mot avec un poids 400.
Ref: 15.6 Font boldness: the 'font-weight' property
T_FONT_02
1. écrire une page HTML utilisant un mot avec font-weight 'bold'
2. vérifier que le navigateur affiche ce mot avec un poids 700.
Ref: 15.6 Font boldness: the 'font-weight' property
Ensuite la méthode va consister à dérouler les activités suivantes :
- on exécute le logiciel de traçabilité :
- pour vérifier si aucune exigence de la spécification n'a été oubliée;
- pour générer la matrice de traçabilité (utile aux étapes suivantes).
- quelqu'un va ensuite vérifier pour chaque exigence de la spécification, si les tests indiqués par la matrice de traçabilité, couvrent effectivement l'exigence dans son intégralité. C'est une étape manuelle et fastidieuse pendant laquelle la matrice de traçabilité générée est une aide précieuse car elle sert de support au suivi de l'avancement (on coche les exigences que l'on vérifie au fur et à mesure, jour après jour.
- ensuite quelqu'un effectue les tests à partir du plan de test. Mais ce n'est plus du domaine de la traçabilité des exigences.
- si tous les tests sont OK, alors le logiciel est conforme à la spécification.
Principe de Reqflow
Reqflow est un outil en ligne de commande. Il analyse les fichiers d'entrée (au format Open XML, Open Document, etc.), capture les exigences, capture les liens entre exigences, et génère un rapport (format texte, CSV ou HTML), indiquant si toutes les exigences en amont sont couvertes par des exigences en aval.
Pour fonctionner, on a besoin de placer dans les documents des marqueurs d'exigence, comme dans l'exemple CSS ci-dessus. Et via des expressions régulières on indique comment capturer les exigences :
-req [1-9][0-9]*\..*
Et pour le plan de test :
-req T_.*
-ref "Ref: .*"
Reqflow indique ensuite :
- les exigences de la spécification qui ont été oubliées dans les tests
- les erreurs (exigences en double, références vers des exigences inexistantes, etc.)
- les matrices de traçabilité entre exigences et documents
Exemple de rapport HTML : http://goeb.github.io/reqflow/reqReport.html
Analyse des PDF
Pour analyser les fichiers d'entrée au format PDF, Reqflow utilise la bibliothèque Poppler, que l'on retrouve dans plusieurs lecteurs PDF open-source.
Autant pour analyser les fichiers HTML, texte, ODT, DOCX, c'est relativement simple (bibliothèque libxml2 et analyse manuelle), autant pour le PDF c'est compliqué.
Car le format PDF, s'il est bien pour transférer un document en gardant le rendu visuel, n'est pas du tout adapté pour être traité informatiquement. En effet les mots que l'on voit se suivre sur l'écran ne sont pas toujours consécutifs dans le fichier. Et ils peuvent même être inversés.
Je crois (mais ne suis pas certain) que Poppler est capable de remettre les mots dans l'ordre en se basant sur leur emplacement dans la page.
Expressions Régulières
J'avais commencé avec la bibliothèque POSIX regex. Puis je me suis réorienté vers la bibliothèque PCRE car elle me paraissait plus conviviale (pas besoin d'échapper les parenthèses notamment). Heureusement, la bibliothèque PCRE fournit une interface identique à la lib regex (libpcreposix), donc je n'ai pas eu à changer mon code source.
Autres outils du marché
D'autres outils propriétaires dominent sur le marché.
Reqtify, outil graphique et qualifié selon certaines normes de développement aéronautique (DO178-B je crois), présente une interface graphique assez pratique.
Reqtify capture les exigences des documents par des expressions régulières, ou par les styles Word.
Il a une fonctionnalité intéressante : cliquer sur une exigence, dans son interface graphique, provoque l'ouverture du document Word ou Excel associé et le positionnement au paragraphe de cette même exigence.
DOORS (IBM® Rational® DOORS®) ne capture pas les exigences à partir des documents, mais possède les exigences dans une base de données et a une interface graphique. Il peut toutefois importer des documents externes dans sa base de données. Ensuite DOORS peut génèrer les matrices de traçabilité et éventuellement les documents (au format Word par exemple) pour échanger avec d'autres parties prenantes qui ne possèderaient pas DOORS.
En comparaison de ces outils, Reqflow est très petit, très rustique car il a moins de convivialité, moins d'ergonomie, moins de fonctionnalités. Mais Reqflow a les atouts suivants :
- il est simple
- il est possible de générer les matrices de traçabilité par un bête script shell ou batch
- il est gratuit et open-source et a tout le temps devant lui pour s'améliorer
- il est en ligne de commande, et greffer une interface graphique au-dessus est possible
Conclusion
J'utilise Reqflow dans mon travail, pour tracer 750 exigences de 8 documents de spécifications en amont, et il me rend bien service.
Page web de Reqflow: http://goeb.github.io/reqflow
Code source sur Github: http://github.com/goeb/reqflow
Aller plus loin
- Journal à l'origine de la dépêche (395 clics)
- Page web de Reqflow (1199 clics)
- Code source sur Github (210 clics)
# Je pinaille, mais...
Posté par liberforce (site web personnel) . Évalué à 2.
J'ai cru comprendre que juste dire qu'un outil qu'il est sous GPL indiquait que la version était au choix de l'utilisateur. Or ce n'est pas le cas ici, c'est GPLv2 uniquement.
Merci pour cet outil intéressant.
[^] # Re: Je pinaille, mais...
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Sur http://goeb.github.io/reqflow/ on peut lire « either version 2 of the License, or (at your option) any later version ». J'ai modifié la dépêche en ce sens.
[^] # Re: Je pinaille, mais...
Posté par liberforce (site web personnel) . Évalué à 2. Dernière modification le 10 mars 2014 à 16:48.
J'avais déjà regardé le fichier de licence dans le projet, et celui ci reprend la GPLv2 verbatim, et il n'y a pas d'info supplémentaire dans le README.md.
https://github.com/goeb/reqflow/blob/master/LICENSE
Ensuite je me suis arrêté au "License GPLv2" juste au dessus de ta citation et dans le menu de gauche (puisque effectivement il n'y avait pas de '+'). @Goeb, tu as une petite source d'améliorations ici ;-).
[^] # Re: Je pinaille, mais...
Posté par goeb . Évalué à 1.
Je ne suis pas sûr de comprendre ta remarque. Si la licence est GPLv2, alors c'est suffisant et exact de dire que c'est GPLv2, il me semble, non ? (même si GPLv2 donne la possibilité de GPLv3)
[^] # Re: Je pinaille, mais...
Posté par Zenitram (site web personnel) . Évalué à 6.
La GPLv2 ne donne pas la possibilité de GPLv3. C'est d'ailleurs tout le plaisir du noyau Linux (qui est en GPLv2 et ne peux pas du tout migrer vers GPLv3 car les auteurs ont bien dit "GPLv2").
"How to Apply These Terms to Your New Programs" veut dire : comment appliquer les conditions. Donc comment tu fais pour mettre la licence à tes fichiers, ce n'est pas la licence. Certains font comme préconisé par la FSF ("either version 2 of the License, or (at your option) any later version.") d'autres non ("version 2").
Donc quand tu marques d'un côté "GPLv2" et de l'autre "either version 2 of the License, or (at your option) any later version", c'est incohérent (tu dis une chose et son contraire, tu dis GPL v2 seulement" dans le titre puis "v2 ou plus" dans le paragraphe), on s'y perd, et pas mal de monde n'aime pas le risque, donc si il y a un seul endroit avec "GPLv2" on considère que c'est GPLv2 pour les gens qui font attention, en attendant que l'auteur précise bien qu'il veut GPLv2+.
La license est moins incohérente : c'est v2 et point barre.
Dit-nous déjà si tu veux v2 ou v2+.
- Si v2, supprime "either version 2 of the License, or (at your option) any later version" de la page http://goeb.github.io/reqflow/
- si v2+, modifie "GPLv2" en "GPLv2+" sur http://goeb.github.io/reqflow/ et ajoute un en-tête (le texte de la FSF) avant la licence sur https://github.com/goeb/reqflow/blob/master/LICENSE (certes, mettre l'en-tête dans les fichier cpp c'est déjà assez précis, mais vaut mieux être clair)
Dans tous les cas :
- https://github.com/goeb/reqflow/blob/master/LICENSE on évite de coller tout ce qu'il y a après "END OF TERMS AND CONDITIONS", ça fait bizarre (ben oui, c'est la fin ;-) )
- On fait bien attention à mettre la licence partout, car pour le moment ton logiciel est non libre ( par exemple https://github.com/goeb/reqflow/blob/master/src/ReqDocumentDocx.cpp n'a pas de licence, donc aucun droit donc non libre)
Si tu penses que je suis casse-couille sur les licences, que je pinaille, ne te frotte jamais en packageurs des distros, ils sont pires que moi ;-)
(j'ai testé, et même en faisant attention j'avais omis quelques fichiers et les robots chasseurs de licence de Debian et Fedora ne m'ont pas loupé sur des fichiers que j'avais oublié)
[^] # Re: Je pinaille, mais...
Posté par goeb . Évalué à 1.
Ok, vu. Je vais mettre GPLv2+.
[^] # Re: Je pinaille, mais...
Posté par liberforce (site web personnel) . Évalué à 2. Dernière modification le 11 mars 2014 à 11:05.
Tu as plus d'infos sur: http://www.dwheeler.com/essays/floss-license-slide.html
# Et dans le monde Eclipse (/!\ cliquodrome)
Posté par Clément David (site web personnel) . Évalué à 2.
Un logiciel est apparemment développé dans la fondation Eclipse est aussi disponible en open-source : ProR. Je ne le connais pas mais il semble être basé sur ReqIF un standard de l'OMG.
Une vidéo de démo est disponible.
[^] # Re: Et dans le monde Eclipse (/!\ cliquodrome)
Posté par goeb . Évalué à 3.
ProR semble adopter la même approche que DOORS : rédiger un document consiste à remplir une base de données. En conséquence il manque d'agilité :
- pour prendre en compte une diversité de documents venant de l'extérieur
- pour utiliser des schémas ou images dans les exigences
- pour renseigner des parties de document qui ne sont pas des exigences (qui expliquent le contexte par exemple)
Et je vois mal un chef de petit projet installer Eclipse seulement pour ça.
# Traçabilité et gestion d'exigences
Posté par SaintGermain . Évalué à 4. Dernière modification le 10 mars 2014 à 16:30.
J'ai eu l'occasion d'investiguer un peu ces outils de gestion/traçabilité d'exigences et il faut avouer que c'est plutôt difficile de s'y retrouver.
Ces documents sont assez pertinents (j'ai un doute sur l'objectivité, mais ce n'est qu'un doute) :
- ISO/IEC TR 24766:2009 : Guide for requirements engineering tool capabilities
- Requirements Engineering Tools (désolé pour le lien bizarre, je n'arrive plus à trouver le lien vers le document original)
- Requirements Management Tools Evaluation
Notons que Reqtify est un outil de traçabilité d'exigences et que Doors est un outil de gestion d'exigences.
Le premier se contente de capturer les exigences et de faire du reporting (matrice de traçabilité, analyse d'impact, etc.). Le second couvre tout le cycle de vie de l'exigence (réunion de brainstorming, définition de l'exigence, gestion des changements d'exigences, traçabilité d'exigences, etc.).
À noter que des outils de gestion d'exigence peuvent s'interfacer avec des outils de traçabilité d'exigences (Reqtify avec Cradle/Doors par exemple).
J'ai eu l'occasion de regarder un peu sous le capot de Reqtify et il faut avouer que c'est assez flexible.
De mémoire pour repérer/capturer les exigences dans un document (Word, PDF, Excel, etc.) il travaille sur une représentation texte du document + un script Perl (configurable par l'utilisateur).
C'est à ma connaissance le seul outil qui fait cela (les autres imposent plus ou moins le format, en se basant par exemple sur les styles Word).
Il y a d'autres logiciels intéressant comme Jama (application web) et Polarion (basé sur un dépôt SVN).
À mon grand regret c'était assez vide au niveau logiciel libre lorsque je m'y suis intéressé. Je vais donc suivre avec intérêt Reqflow !
[^] # Re: Traçabilité et gestion d'exigences
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"Le second couvre tout le cycle de vie de l'exigence (réunion de brainstorming, définition de l'exigence, gestion des changements d'exigences, traçabilité d'exigences, etc.)."
La traçabilité dans doors ne gère pas d'objets externe à lui-même comme le code.
"La première sécurité est la liberté"
[^] # Re: Traçabilité et gestion d'exigences
Posté par SaintGermain . Évalué à 9.
Si tu poses la question à un commercial IBM, il te répondra "Si si c'est possible avec notre outil". ;-)
Par exemple pour importer des exigences de Word à Doors:
Exporting from Microsoft Word to Rational DOORS
L'ennui que j'ai régulièrement avec les solutions propriétaires c'est que c'est toujours "possible" mais que l'on me cache presque toujours le contexte d'application, les contraintes et les coûts de développement nécessaires (c'est un constat hein, pas une surprise…).
Dans le cas que tu présentes, un commercial Doors va sans doute me dire que Doors gère la traçabilité et la capture/importation d'exigences externes. Mais il va par exemple passer sous silence que cela ne marche qu'avec Word, que c'est valable que dans un sens (Word->Doors) et à la condition que les exigences soient formatées comme il faut et que sinon il faudra prendre un développeur certifié Doors pendant 2 mois pour adapter le plugin comme il faut, etc.
Bref comme d'habitude, il faut tester par soi-même. Mais le soucis ici c'est que ce genre de logiciels est plutôt dédié aux grosses entreprises, et donc toute recherche sur le web retourne pleins de plaquettes commerciales et de buzzwords/business loto avec peu de comparaisons pertinentes.
[^] # Re: Traçabilité et gestion d'exigences
Posté par PyroTokyo . Évalué à 3.
D'ailleurs, je peux vous dire que ce manque de flexibilité de Doors vis à vis des autres outils nous a permis de vendre du Reqtify assez facilement à des utilisateurs Doors, grâce au connecteur qui prend en compte l'exportation et la synchro.
Par exemple:
spec en PDF (ou autre) => lecture et analyse dans Reqtify => export dans DOORS
Si le doc de spec est mis à jour, pas de soucis, on le réanalyse, et au prochain export c'est synchronisé.
Ça permet aussi de faire des choses sympathique,
comme par exemple du mirroring entre 2 bases de données, comme Doors et Enovia pour une transition un peu plus douce :)
# GenSpec : a voir avec ça.
Posté par Selso (site web personnel) . Évalué à 4.
Oué… donc je ne suis pas le seul à déplorer un manque d'outils.
Et malheureusement le plus utilisé reste l'un des moins adapté : Word… et toute sa clique de macro pas vraiment compatibles entre versions. Mais allez faire avaler à un marketeux / client, qu'un outil web, avec une base de données centralisée, une séparation de la présentation du contenu, etc… serait mieux qu'un WYSIWG.
Et oui il manque a ses outils un démarrage de projet en mode simple/avancé.
Je rêve d'un outil qui permette d'historiser les exigences, de tracer celles-qui sont abandonnées, d'établir en un simple drag-and-drop des liens entres elles, de le regrouper dans des vues différentes par catégories (surêté de fonctionnment, fonctionnalités)…
Et non impossible de se passer d'un word, mais avec un outil web on pourrait exporter vers PDF/WORD, voir même l'inverse en respectant une consigne de rédaction.
Ha au fait je me suis incris au group de GenSpec. Je ne l'ai pas essayé, c'est un "client riche" VC6. Il faut s'incrire au groupe de discussion. J'estimais qu'il pouvait faire un bon point de départ.
# Sens de "non critique" ?
Posté par cluxter . Évalué à 2.
Tout dépend de ce qu'on entend par "non critique".
Je pense qu'un certain nombre de failles de sécurité pourraient être évitées en étant plus rigoureux sur les processus de développement, ce qui pourrait éviter pas mal de cas de cybercriminalité.
J'imagine qu'en l’occurrence "non critique" signifie "ne mettant pas de vies humaines en danger" ( http://linuxfr.org/news/encore-un-exemple-de-code-spaghetti-toyota ) ou "ne causant pas de préjudice économique important". Reste qu'un bon nombre de piratages se font via des pages webs vérolées et qu'en la matière tous les moyens sont bons ( http://travaux.ovh.net/?do=details&id=8998 ), ce qui peut mener à des désastres ( http://www.lemonde.fr/argent/article/2014/03/06/apres-mtgox-la-plateforme-flexcoin-ferme-victime-d-un-vol_4378348_1657007.html ).
En poussant un peu, on peut se dire que des systèmes SCADA pourraient être mis en danger à cause d'un navigateur web mal conçu (toujours via des pages webs vérolées).
Voilà pourquoi je milite pour du code propre et rigoureux en toute circonstance.
# importer des documents Doors ou Reqtify ?
Posté par palm123 (site web personnel) . Évalué à 2.
As-tu prévu de faciliter la migration de Doors/Reqtify vers Reqflow ?
ウィズコロナ
[^] # Re: importer des documents Doors ou Reqtify ?
Posté par goeb . Évalué à 1.
Non, je n'ai pas prévu. Je ne dispose pas de Doors ni de Reqtify.
# Intéressant !
Posté par bat13 . Évalué à 2.
Ça fait longtemps que je recherche moi-même ce type d'outils.
J'ai essayé de l'utiliser, mais la doc ne semble pas correspondre tout à fait à la réalité :
Ou alors j'ai loupé un truc.
Mais j'aimerais bien l'utiliser, je pense qu'il me simplifierait la vie.
La commande "report" me semble importante, elle permettrait de faire la "preuve" dans un format lisible par le commun des mortels de la traçabilité des exigences.
Question subsidiaire : j'ai des exigences au format
NOM_EXIGENCE_XXX [
Texte de l'exigence
] NOM_EXIGENCE_XXX
Où XXX est le numéro de l'exigence
Je n'ai pas réussi à écrire une expression régulière qui permette de traiter correctement les exigences : elles sortent toutes en erreur "Duplicate requirement". Je suis très mauvais en expressions régulières, aurais tu une idée, je n'ai pas réussi à faire en sorte de traiter le pattern 'NOM_EXIGENCE_XXX ['
Merci déjà pour cet outil !
[^] # Re: Intéressant !
Posté par bat13 . Évalué à 1.
Oups : je me rends compte (trop tard pour modifier) que la fin de mon texte n'est pas très clair : mes exigences sont au format NOM_EXIGENCE_XXX, où NOM_EXIGENCE_ est constant, seul le numéro collé derrière varie
[^] # Re: Intéressant !
Posté par goeb . Évalué à 1. Dernière modification le 12 mars 2014 à 18:41.
En effet, la page web n'est pas à jour.
La commande 'report' a été remplacée par 'trac -x html'.
Je vais corriger l'exemple.
Tu peux capturer cela avec l'expression régulière suivante :
NOM_EXIGENCE_[A-Z0-9_]*[^] # Re: Intéressant !
Posté par bat13 . Évalué à 1.
En effet, c'est mieux (en même temps, j'aurais du mieux lire l'aide en ligne).
On s'est mal compris : j'arrive bien à capturer les exigences avec l'expression régulière que j'utilise, mais comme certaines exigences font référence à d'autres, je me retrouve avec des "Duplicate requirement". Pour éviter ça, il faudrait que je ne prenne en compte que celles qui commencent par 'NOM_EXIGENCE_XXX [', c'est à dire avec l'espace et le crochet ouvrant
[^] # Re: Intéressant !
Posté par bat13 . Évalué à 1.
J'utilise l'expression ci-dessous:
Qui me sort bien la liste des exigences, mais avec l'erreur indiquée plus haut
En la modifiant comme ceci:
Pour englober l'espace et le crochet suivant le numéro de l'exigence, et avec des '\' pour échapper ces caractères spéciaux, j'ai l'erreur :
[^] # Re: Intéressant !
Posté par goeb . Évalué à 1.
Le \ est un caractère d'échappement du fichier de config.
Essaye ceci :
- échapper le \
- mettre des parenthèses autour de NOM_EXIGENCE_xxx, pour ne pas prendre le [ dans la capture
[^] # Re: Intéressant !
Posté par bat13 . Évalué à 1.
Merci beaucoup !
En effet, la règle que tu suggères a permis de supprimer l'erreur, mais aussi de corriger l'autre problème auquel je faisais référence (voir plus bas)
[^] # Re: Intéressant !
Posté par goeb . Évalué à 1.
Et merci de ton retour. Je suis preneur de tout ce qui peut conduire à des améliorations.
[^] # Re: Intéressant !
Posté par bat13 . Évalué à 1. Dernière modification le 13 mars 2014 à 11:36.
Alors, j'ai une autre question :
En faisant abstraction de ma précédente question relative aux expressions régulières, j'ai un document qui contient 18 exigences au format précédemment décrit.
Je fais un document qui est supposé faire référence à ces exigences. Si ce document est au format docx, la sortie html me donne la liste des exigences du document 'SPEC', et rien concernant le document 'TEST'.Si je convertis mon document TEST au format pdf, j'ai maintenant 5 erreurs, qui correspondent à toutes les fois où j'ai fait référence dans TEST à une exigence définie dans SPEC.
Par exemple :
Je retrouve dans le document html toutes les exigences définies dans SPEC, et toutes celles définies dans TEST, mais sans aucun lien de dépendances entre mes deux documents.
J'ai sûrement loupé un truc, mais je ne vois pas où …
Je ne retrouve pas dans la sortie html le lien de dépendance entre le SPEC et TEST de l'exemple fourni avec reqflow, je suis pourtant parti du même fichier de configuration
[^] # Re: Intéressant !
Posté par goeb . Évalué à 1.
Je cherche à comprendre l'organisation de ton document en partant de ton exemple un peu modifié :
La signification que tu donnes à cela est-elle : "NOM_EXIGENCE_YYY couvre NOM_EXIGENCE_XXX" ?
Si oui, alors tu dois définir l'option -ref comme ceci :
-ref "\] NOM_EXIGENCE_.*"
Sinon, pourrais-tu préciser comment, dans ton document, tu fais le lien entre une exigence en amont, et une en aval ?
Par ailleurs, voici une astuce pour tester les regex :
shell> req regex " NOM_EXIGENCE_.* [" toto
ERROR Could not compile regex
Ok.
shell> req regex " NOM_EXIGENCE_.* \[" toto
No match
Ok.
[^] # Re: Intéressant !
Posté par bat13 . Évalué à 2.
Merci de t'intéresser à mon cas !
Non, une exigence amont est écrite comme ceci :
Uniquement afin de délimiter le début et la fin du texte de l'exigence (ce n'est pas moi qui ai choisi ce formalisme, je n'en suis donc pas maître)
Ce document est celui du client.
Moi, je rédige celui aval (ou plutôt ceux en aval, mais dans un premier temps, je n'en ai qu'un), qui doit faire référence aux exigences amont
Le -ref est le même que celui de l'exemple fourni.
Mais ta suggestion de correction d'écriture de l'expression régulière m'a permis de corriger le problème: plus d'erreur de compilation de la règle, plus d'erreur "Duplicate", et bonne liaison entre exigences amont et aval.
Du coup, j'ai fait un troisième document, le deuxième étant nos specs internes, et j'ai ainsi une traçabilité Specs client <=> Specs internes <=> Tests.
Génial !
[^] # Re: Intéressant !
Posté par goeb . Évalué à 1.
Parfait.
En complément, je précise que dans ton document de test, peut-être, il ne faudrait pas définir l'option -req de la même manière que dans le document amont. Ça me paraîtrait étonnant que les exigences et tests aient le même formalisme.
[^] # Re: Intéressant !
Posté par bat13 . Évalué à 1.
Non, effectivement, mes exigences sont du style
Pour les spécifications, et
Pour respecter un tant soit peu le formalisme du client et éviter de se faire des noeuds
# Une super idée
Posté par Chuck #1 . Évalué à 2.
Ce projet à l'air très intéressant. Les outils commerciaux du marché, outre un prix très élevé, sont difficilement interopérables. Les temps de saisie, extraction, conversion, et réimportation les rendent peu à même d'être utilisé pour des petits projets ou des projets non critiques (= sans dommages corporels). Sur le long terme, l'utilisation d'un tel système est pourtant souvent payant. J'aime bien l'exemple de gestion des exigences sur Wikipédia : un constructeur automobile cherche à réduire le coût de fabrication d'un de ses modèles et décide de supprimer une exigence farfelue qui spécifie de résister à un vent arrière de 200 km/h avec de la pluie. Quelques mois plus tard, les concessionnaires reçoivent des voitures avec le coffre plein d'eau : les voitures étaient transportées par train Express.
Cette signature est publiée sous licence WTFPL
# Il existait ça
Posté par JN . Évalué à 1.
J'avais trouvé ça (sans avoir le temps de l'évaluer).
http://www.flonatel.de/index.php?id=9
Qu'est ce qui différencie
reqflowdermtoo?[^] # Re: Il existait ça
Posté par goeb . Évalué à 1.
Quelques différences :
# Gestion des exigences
Posté par djano . Évalué à 2.
En libre et qui gere les exigences (a quel point? Je ne sais pas!) de manière un peu intégrée (forge, bugtracker, etc.), je connais Tuleap: http://www.enalean.com/?q=fr/tuleap#gestion-exigences
Par contre, je n'ai pas joue avec alors je ne sais pas du tout ce qu'il vaut.
[^] # Re: Gestion des exigences
Posté par djano . Évalué à 2.
Ah ben justement c'est marrant: http://linuxfr.org/news/nouveau-site-communautaire-de-la-forge-libre-tuleap
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.