Journal Reqflow

Posté par  . Licence CC By‑SA.
Étiquettes :
22
6
mar.
2014
Ce journal a été promu en dépêche : Sortie de Reqflow pour tracer vos exigences.

Reqflow

Reqflow est un outil open-source 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é.

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 aval couvrent les exigences 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.

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.

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 amont sont couvertes par des exigences aval.

Pour fonctionner, on a besoin de placer dans les documents des marqueurs d'exigence. Exemple :

PRINTF_01
La commande `printf --help` doit afficher un message d'aide et se terminer.

Ensuite dans le plan de test on doit référencer cette exigence :

T_PRINTF_01
- lancer la commande `printf --help`
- vérifier qu'un message d'aide s'affiche.
- vérifier que la commande se termine avec un code retour zéro
Ref: PRINTF_01
Ref: PRINTF_03

Reqflow indique ensuite:
- les exigences de la spécification qui ne sont pas prises en compte dans les tests
- les erreurs (exigences en double, références vers des exigences inexistantes, etc.)
- les matrices de traçabilité entre exigences et entre 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, j'ai utilisé la bibliothèque Poppler, qui est utilisé 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 sur 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.

Conclusion

J'utilise Reqflow dans mon travail, pour tracer 750 exigences de 8 documents de spécification 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

  • # Qualifié ?

    Posté par  (site web personnel) . Évalué à 1.

    Le programme est qualifié ?

    "La première sécurité est la liberté"

    • [^] # Re: Qualifié ?

      Posté par  . Évalué à 1.

      Non, il n'est pas qualifié.
      Il y a un test unitaire, mais c'est tout.

    • [^] # Re: Qualifié ?

      Posté par  . Évalué à 1.

      Je n'ai pas d'objectif de qualification pour l'instant. J'ai pour objectif de faciliter le travail. Je connais plusieurs personnes qui ont à leur disposition Reqtify, mais qui ont quand même développé leurs scripts maison (en python par exemple) pour se faciliter le travail de relecture et vérification.

  • # excellente nouvelle

    Posté par  (site web personnel) . Évalué à 7.

    La norme de fait aujourd'hui est le propriétaire Doors
    http://www-03.ibm.com/software/products/fr/ratidoor/
    et le seul concurrent que je connais est (lui aussi proprio) reqtify
    http://fr.wikipedia.org/wiki/Reqtify
    qui semble un ton en dessous.

    ウィズコロナ

    • [^] # Re: excellente nouvelle

      Posté par  (site web personnel) . Évalué à 6.

      Doors est une base de donnés de requirement. Reqtify est, pour moi, un moyen de faire des matrices de traçabilités entre document (y compris depuis doors), voir du code.

      J'ai aussi compris que Doors, n'évolue plus tellement, jouant sur son quasi monopole. Un logiciel libre a vraiment une place à prendre.

      "La première sécurité est la liberté"

      • [^] # Re: excellente nouvelle

        Posté par  (site web personnel) . Évalué à 2.

        Oui, mais Reqtify étant moins cher que Doors, certains le privilégient, en prétendant que ça fait le même boulot…

        ウィズコロナ

        • [^] # Re: excellente nouvelle

          Posté par  (site web personnel) . Évalué à 2.

          J'imagine que les spec sont eux même dans un .doc ou équivalent.

          "La première sécurité est la liberté"

          • [^] # Re: excellente nouvelle

            Posté par  . Évalué à 1. Dernière modification le 07 mars 2014 à 12:21.

            Oui, en fait on fait bien la distinction entre "requirement definition", ce que fait Doors (et si on est pas exigent, ce que font les clients avec Excel, ou pire, du jpeg dans les pires cas), et "requirement management", ce dont s'occupe Reqtify.

            Pour y avoir beaucoup touché, je dirais que Reqtify raisonne en "tout est document", que ce soit un .doc, un .xls ou un répertoire de code (ou alors un serveur Doors aussi…).
            On passe par des "interfaces" pour parser/analyser le tout, et le soft agglomère tout ça dans un projet de traçabilité.

            Après, comme le soft présenté ici, une fois le modèle de projet obtenu, on en tire un peu ce qu'on veut, que ce soit des matrices de traçabilité, des analyses d'impact (si je modifie une exigence, en quoi ça impacte mon code 3 niveaux en dessous ?), des snapshots pour suivre les modifs entre 2 révisions par exemple (l'équivalent grossier d'un diff sur les exigences).

            • [^] # Re: excellente nouvelle

              Posté par  . Évalué à 2.

              Euh, je ne vois pas de fonctions de Reqtify de "requirement management" que ne fait pas Doors. En fait, pour avoir utilisé les deux, je ne vois pas de fonctions de Reqtify non faites par Doors (le DXL c'est madjik).

              • [^] # Re: excellente nouvelle

                Posté par  (site web personnel) . Évalué à 1.

                On me souffle
                "Doors est une base de données de tout le référentiel, alors que reqtify est basé sur des macros Word"

                ウィズコロナ

                • [^] # Re: excellente nouvelle

                  Posté par  . Évalué à 2.

                  Des macros Word ?? Je ne suis pas sûr qu'on parle du même logiciel… Tu ne parlerais pas de RequisitePro ?

                  En fait, pour être plus précis, Reqtify procède dans un premier temps à une conversion du document d'origine en plain text ou en xml, selon le type de document (typiquement, quand la structure est importante, on procède vers du XML, avec des fichiers Simulink ou XML par exemple).
                  Ensuite, soit par expressions régulières, soit par des patterns XML, on identifie les sections, exigences, relations d'implémentation, etc…
                  Rien à voir avec des macros donc. Ce qui est vrai par conte, c'est que pour certains softs (Word, Excel entre autres) on utilise l'interface COM pour avoir une navigation un peu plus pratique (genre, on clique sur une exigence dans Reqtify, ça ouvre Word et saute jusqu'à l'exigence en question, pratique quand tu as 600 pages de specs et pas envie de chercher dedans).

                  Pour ce qui est de Doors, à ma connaissance, on ne sait pas lire de fichiers xls, pdf, ou même du code source, donc non je ne pense pas qu'on puisse dire qu'il fait tout ce que fait Reqtify.
                  Le premier est vraiment dédié à la définition d'exigence, là où je verrais plutôt le second comme un aggrégateur d'exigences venant de différentes sources.

                  • [^] # Re: excellente nouvelle

                    Posté par  . Évalué à 3.

                    Ensuite, soit par expressions régulières, soit par des patterns XML, on identifie les sections, exigences, relations d'implémentation, etc…

                    De mémoire, ça se fait surtout avec des styles word (ou alors ça a fondamentalement changé de quand je faisais du dev, ce qui remonte certes un peu :) )

                    Pour ce qui est de Doors, à ma connaissance, on ne sait pas lire de fichiers xls, pdf, ou même du code source, donc non je ne pense pas qu'on puisse dire qu'il fait tout ce que fait Reqtify.

                    Ben ta connaissance est partiellement fausse ou j'ai raté une killer friture de Reqtify :)
                    Il est possible d'importer des documents excels/word dans doors (même si ce n'est pas un workflow normal), mais tu ne peux pas travailler directement sur les fichiers xls/doc. L'idée avec Doors c'est de travailler uniquement dans la base de donnée et d'exporter le(s) document(s) après avec les matrices qui vont bien.

                    • [^] # Re: excellente nouvelle

                      Posté par  (site web personnel) . Évalué à 1.

                      Comment tu fais la traçabilité dans ce cas ?

                      "La première sécurité est la liberté"

                    • [^] # Re: excellente nouvelle

                      Posté par  . Évalué à 2. Dernière modification le 08 mars 2014 à 10:37.

                      Je n'ai jamais utilisé Doors donc effectivement mes connaissances sont lacunaires. J'ai cité Word et Excel comme exemples parmi les plus fréquemment utilisés, mais on peut aussi partir sur des fichiers PDF, des fichiers Rhapsody, des modèles Simulink, etc…

                      En gros ce que nous disent les commerciaux IBM, c'est "migrez toutes vos données sous Doors, et ensuite restez dessus". Alors oui mais non, quand tu reçois tes specs clients en PDF (oui, ça sux) ou en .doc ou je ne sais quoi (des fois en papier, c'est pour dire), tu n'as pas envie de tout reimporter dans Doors à chaque fois !

                      Pour ce qui est des styles, effectivement on peut s'en servir, mais ce n'est pas obligatoire. Disons que ça aide à discriminer plus facilement. Si ton exigence s'appelle REQ1 et que tu le trouves à la fois dans le corps de texte et ailleurs avec un style donné, ça t'évitera d'avoir des matchs incorrect avec un regexp du type ^REQ\d+ par exemple.

                      • [^] # Re: excellente nouvelle

                        Posté par  (site web personnel) . Évalué à 2.

                        En gros ce que nous disent les commerciaux IBM, c'est "migrez toutes vos données sous Doors,

                        d'ailleurs un certain nombre de boites demandent lors d'appels d'offres des fichiers au format Doors.
                        Est-ce que Reqflow a prévu de proposer cela ?
                        (oui, je sais, le genre de truc pour lequel on est peu motivé à développer…)

                        ウィズコロナ

    • [^] # Re: excellente nouvelle

      Posté par  (site web personnel) . Évalué à 1.

      Je vais juste rajouter RMF un outil open source sous Eclipse : http://www.eclipse.org/rmf/

      RMF est plus proche d'un DOORS dans l'esprit que d'un Reqtify (qui effectivement ne fait que de la tracabilité et qui part des documents qui contiennent les "choses" à tracer alors qu'un DOORS et RMF sont la source des "choses" à tracer), mais les liens de traça peuvent être directement exprimés dans RMF.

      Comme derrière c'est de l'Eclipse EMF y a tous les outils dispo ensuite pour générer de la doc, modifier programmatiquement la base d'exigences, l'intégrer avec des outils tiers pour faire de la vérif, de la trace…

    • [^] # Alternative libre

      Posté par  . Évalué à 1.

      À noter l'existence du projet Squash TM qui propose une interface de gestion des exigences aussi.

      Le projet est encore jeune et poursuit un objectif plus ambitieux. Il est actuellement "sponsorisé" mais je ne sais pas pour combien de temps encore.
      En tout cas, je suis son développement sans vraiment l'utiliser car il me semble aller dans la bonne direction concernant les objectifs.

    • [^] # Re: excellente nouvelle

      Posté par  . Évalué à 1.

      J'avais contacté un distributeur de Reqtify pour l'acheter (GeenSoft), mais je n'ai jamais eu de réponse. Je ne sais pas si Reqtify est vraiment commercialisé.

      • [^] # Re: excellente nouvelle

        Posté par  (site web personnel) . Évalué à 2.

        Ils se sont fait racheter par Dassaut system. Les équipes ont du être dilué.

        "La première sécurité est la liberté"

      • [^] # Re: excellente nouvelle

        Posté par  . Évalué à 1.

        Je confirme que c'est toujours commercialisé :)
        Ceci dit, il y a eu une période assez chaotique vers 2010, qui a correspondu effectivement au rachat par Dassault Systemes (genre, Q2 2010).

    • [^] # Re: excellente nouvelle

      Posté par  . Évalué à 1.

      Reqtify et DOORS sont-ils scriptables ? (pour intégration continue par exemple)

      • [^] # Re: excellente nouvelle

        Posté par  . Évalué à 1.

        Pour Doors, je ne sais pas pour être honnête.

        Pour Reqtify, tu as une sorte de langage de script intégré, qui s'appelle OTScript, qui te permet de faire certaines choses, comme rajouter des règles perso à valider, voire dans certains cas créer de nouvelles interfaces (j'ai dû faire ça pour rajouter un système de gestion de conf qui n'était pas intégré dans la version vendue).

        Par contre, pas de chance, ce langage de script ne ressemble pas vraiment à grand chose de connu/répandu. C'est un mélange de script/fonctionnel qui pour être franc est assez bizarre. On dirait un langage tout droit sorti d'un projet de recherche, ou quelque chose comme ça.
        Il était question à une époque d'avoir la possibilité d'utiliser Java en plus de ce langage, mais je ne sais pas dans quelle mesure c'est possible maintenant.

      • [^] # Re: excellente nouvelle

        Posté par  . Évalué à 2.

        Je sais que Doors est scriptable, un collègue était spécialisé la dedans pour nous ressortir des données sur un format pratique pour nous. Après, je crois bien que c'était galère.

        On avait même un script Doors qui nous sortait les spec dans word (sûrement basé sur un template). Ça copiait également notre code source du .h stocké ligne par ligne (1 ligne de code = 1 ligne Doors) dans ce document word.
        Après, pour obtenir notre .h, il fallait copier depuis le document word et coller ça dans un fichier texte qu'on renommerait habilement *.h .
        La magie des outils bien utilisés. (Et bien sûr, cette procédure était obligatoire dans cet ordre là. Tout contrevenant était sévèrement puni)
        Je ne vous parle pas d'insérer une ligne du .h dans Doors.
        Je ne citerai pas d'entreprise, mais au secours quand même.

  • # Intéressant!

    Posté par  (site web personnel) . Évalué à 5.

    Je suis dans une petite boite où on a une approche assez pragmatique et peu formelle du développement. Pourtant, même dans ce contexte, je vois bien l'utilité de ce genre de programme. Même pour des projets de 1 mois, on se perd vite entre des grosses specs de fonctionnalités, des grosses spec de tests, et une implémentation des tests.

    A mon boulot, mon équipe a développé un framework de test en Python pour faire des tests avec beaucoup de meta-données. Chaque test référence notamment un requirement, ou une référence du plan de test (parfois les deux) plus deux ou trois autres informations utiles.

    Du coup, on peut générer un plan de test assez touffu à partir de l'implémentation même. Ce qui est bien, c'est que les deux informations "ce qui est testé" et "le test même" sont au même endroit, donc on a pas le risque que l'implémentation des tests soit moins à jour que le plan de test lui-même.

    Avec ton outil, je pourrai prouver que mon plan de test généré à partir de ma suite de test couvre bien toute la spec de test et tous les requirements identifiés.

    • [^] # Re: Intéressant!

      Posté par  . Évalué à 1.

      Dans ton cas, quels seraient les fichiers d'entrée de Reqflow ?
      - un fichier qui constitue le plan (format word ou autre) ?
      - un fichier qui constitue le rapport de test généré ?

      Une fonctionnalité que je rajouterai peut-être plus tard à Reqflow est d'aller capturer les exigences dans une multitude de fichiers. Du genre */*.py. Pour l'instant il faut configurer à la main chaque fichier, ce qui s'avère fastidieux si on a des dizaines de fichiers.

      • [^] # Re: Intéressant!

        Posté par  (site web personnel) . Évalué à 2.

        Les entrées:

        • un document word qui est une spec de test assez générale
        • un document html généré par ma suite de test Python qui est le plan de test exact.

        Evidemment, si je peux me passer de générer le html du plan de test, c'est encore mieux. Dans ce cas, un **/test_*.py est parfait.

  • # Dépêche ?

    Posté par  (site web personnel) . Évalué à 10.

    Non, tout n'est pas dans le titre :) Je ne demande pas que ce journal soit promut en dépêche.

    Ton projet a l'air intéressant, mais ne connaissant pas vraiment le domaine, j'ai un peu de mal à juger et le situer par rapport au reste (ainsi qu'a mes potentiels besoins)

    Vous êtes plusieurs à avoir de s'y connaitre dans le domaine. Si vous n'avez rien à faire, je serais bien intéressé par un dépêche que vous pourriez faire à ce sujet.

    Genre:

    • Qu'est ce qu'un spec (bon, ça je sais, mais ça fait pas de mal de le rappeler)
    • À quoi ça ressemble (idem)
    • Comment vérifier qu'une spec est complète (si possible?)
    • Comment vérifier qu'un code correspond à la spec
    • Comment générer des tests qui vérifient la spec
    • Quels sont les outils utilisés
    • Les différents cas d'utilisation
    • Des exemples
    • La différence entre Reqflow et Doors
    • Plein de trucs auxquels je ne pense pas parce que je connais pas…

    Merci d'avance :)

    Matthieu Gautier|irc:starmad

    • [^] # Re: Dépêche ?

      Posté par  (site web personnel) . Évalué à 1.

      "Qu'est ce qu'un spec (bon, ça je sais, mais ça fait pas de mal de le rappeler)"

      Un ensemble de paragraphe avec parfois, plusieurs couches, pour "raffiner" les exigences. Dans la pratique, les exigences sont très bas niveau pour faciliter la traçabilité avec le code. Vu que les traçabilités multiples sont interdites (on peut lié plusieurs requirement à un même bout de code, un bout de code à plusieurs requirement, mais pas plusieurs bout de code à plusieurs requirement, car les matrices de traçabilité qui servent à vérifier que l'on n'oublie rien, deviennent inutile).

      "À quoi ça ressemble (idem)"

      [PLOP_123]
      blablabla shall blablabla

      "Comment vérifier qu'une spec est complète (si possible?)"

      A la main, avec des fiches de relecture prévu par un plan (document également à écrire).

      "Comment vérifier qu'un code correspond à la spec"

      Avec les tests, qui sont censé être écrit uniquement par rapport à la spec, en utilisant le code comme une boite noire. On vérifie aussi la traçabilité du code avec la spec : rien ne doit venir de null part, aucune spec doit être oublié.

      "Comment générer des tests qui vérifient la spec"

      En général, les tests générés sont interdis. Le but est de faire de la vérification croisé, si c'est généré, il n'y a rien de vérifié de façon croisé.

      La façon la plus simple de faire les tests est de faire un modèle de tests (oui on recode une 2ième fois tout, plus le programme est gros et plus on gagne du temps au final). Le modèle de test et le code doivent avoir les mêmes sorties. En théorie, on doit pouvoir générer les entrées automatiquement en utilisant la couverture de code du modèle de teste. La comparaison des sorties peut aussi être automatique.

      Dans la pratique, on écrit tout à la main, avec des bout de modèle pour générer les sorties attendues.

      "Quels sont les outils utilisés"

      Un peu de tout :) On peut aussi utiliser des outils qualifié pour la vérification. L'idée est de pouvoir se passe d'étape de revu manuel. Un outil de vérification est plus facile à qualifier car il ne génère rien pour le projet. Cela peut être très utile.

      "Des exemples"

      http://dnlcenter.esterel-technologies.com/index.php cf les handbook/white paper de ma boite ? :) Oui, c'est un peu de pub et oui, il demande de créer un compte pour y avoir accès, mais il n'y a pas de confirmation.

      "La première sécurité est la liberté"

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.