Deployment Package – Software Requirements Analysisprofs.etsmtl.ca/claporte/VSE/Trousses/Trousse de depl… · Web viewCe document est la propriété intellectuelle de l’organisation

Trousse de déploiementAnalyse des exigences

Profil basique

Remarque:Ce document est la propriété intellectuelle de l’organisation des auteurs. Cependant, l’information de ce document peut être utilisée de manière libre. La distribution du document complet ou des parties individuelles est autorisée pour l’utilisation non commerciale pourvue que la notification suivante légale soit mentionnée :

© École de technologie supérieure

L’utilisation commerciale de ce document est strictement interdite. Ce document est distribué afin d’augmenter l’échange d’information technique et scientifique.

Ce matériel est fourni «tel quel». L'auteur n’offre aucune garantie d'aucune sorte, explicite ou implicite, quant à toute question, y compris, mais sans s'y limiter, à la garantie de performance, à l'usage ou de qualité marchande, l'exclusivité, ou les résultats obtenus par l'utilisation du matériel.

Les processus décrits dans cette trousse de déploiement ne visent pas à empêcher ou à décourager l’utilisation de processus additionnels dont les très petits organismes pourraient trouver utiles.

Auteur(s) Jeljeli Houcine – École de technologie supérieure (ÉTS), (Canada)Éditeur C. Y. LAPORTE – École de technologie supérieure (ÉTS), (Canada)Date de création 20 Décembre 2012Dernière mise à jour 02 Février 2013Statut ÉbaucheVersion 0.1

Historique des versions

Date Version Auteur Modification© Prénom Nom

Trousse de déploiement – Analyse des exigences du logiciel – Profil basique Page 2 / 36Version 0.1

(jj-mm-aaaa)20-12-2012 0.1 Houcine Jeljeli Création initiale21-12-2012 0.1 Houcine Jeljeli Section 1 et 222-12-2012 0.1 Houcine Jeljeli Section 423-12-2012 0.1 Houcine Jeljeli Version Ébauche prête pour une revue25-01-2013 0.1 Elie Joseph Revue du document02-02-2013 0.1 Elie joseph Modification du document

Abréviations/acronymes

Abré./Acro. DéfinitionsTD Trousse de déploiement – Un ensemble d’artefacts développés pour faciliter

l’implémentation dans un très petit organisme, un ensemble de pratiques provenant d’un cadre de référence sélectionné.

TPO Très petit organisme – une entreprise, une organisation, un département ou un projet de 25 personnes ou moins.

SI Processus de mise en œuvre du logicielISO Organisation internationale de normalisationIEC/CEI International Electrotechnical Commission/Commission Electrotechnique

InternationaleTR Technical ReportPM Processus de gestion de projet

© Prénom Nom


Table des matières1. Description Technique...............................................................................4

1.1 But de ce document................................................................................................................4Pourquoi la gestion des exigences est-elle importante ?...............................................................4

2. Définitions................................................................................................72.1 Termes génériques.................................................................................................................72.2 Termes spécifiques.................................................................................................................7

3. Liens avec la norme ISO/IEC 29110.............................................................94. Description des processus, activités, tâches, étapes, rôles et produits.......10

4.1. Les tâches de l’activité d’Analyse des exigences du logiciel................................................114.2 Description des rôles.............................................................................................................164.3. Description des artefacts.....................................................................................................16

5. Gabarits et outils....................................................................................185.1 Gabarits..............................................................................................................................185.1.1 Spécification des exigences............................................................................................185.2 Outils..................................................................................................................................185.2.1 Outils de gestion des exigences......................................................................................18

6. Exemple de la mise en œuvre de tâches...................................................197. Listes de vérification...............................................................................208. Matrices de couverture............................................................................21

8.1 Matrice de couverture de l'ISO 9001.....................................................................................218.2 Matrice de couverture de l’ISO/IEC 12207.............................................................................218.3 Matrice de couverture du modèle CMMI pour le développement...........................................22

9. Références..............................................................................................2310. Formulaire d’évaluation de la trousse.....................................................24Annexe A : Exemple de document de Spécification des exigences..................25Annexe B : Exemple de matrice de tracabilité...............................................32Annexe C : Outils de gestion des exigences (Logiciels libres).........................36

© Prénom Nom


1. Description Technique1.1 But de ce documentCette trousse de déploiement (TD) soutient le profil basique tel que définit dans le document ISO/IEC TR 29110-5-1-2:2011-Guide de gestion et d'ingénierie: Groupe de profil générique: Profil basique [ISO/IEC 29110]. Le profil basique est un profil du groupe des profils génériques. Le groupe des profils génériques est applicable aux très petits organismes (TPO) qui ne développent pas des logiciels critiques. Le groupe des profils génériques est composé de 4 profils : entrée (Entry), basique (Basic), intermédiaire (Intermediate) et avancé (Advanced). Le groupe des profils génériques n'implique pas un domaine spécifique d'applications. Le profil basique est destiné aux TPO qui développent un seul projet à la fois.

Une trousse de déploiement est un ensemble d’artefacts qui facilitent l’implémentation d’un ensemble de pratiques dans un TPO. Une TD n’est pas un modèle de référence de processus (c.-à-d. qu’elle n’est pas prescriptive). Les éléments d’une TD sont : la description du processus, les activités, les tâches, les étapes, les rôles et les produits, les gabarits, les listes de vérification (check-lists), les exemples et les outils.

Le contenu de ce document n’est pas normatif, ce document est informatif.

Ce document est destiné à être utilisé par un TPO afin d’établir des processus pour mettre en œuvre une approche de développement ou une méthodologie, par exemple, agile, évolutive, itérative, développement dirigé par les tests, etc. sur la base des besoins de l'organisme ou du projet d'un TPO.

Le document ISO/IEC TR 29110-5-1-2:2011 est disponible sans frais sur le site de l'ISO suivant:http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html

Pourquoi la gestion des exigences est-elle importante ?La gestion des exigences est fondamentale pour la réussite d'un projet. Elle constitue, en effet, un processus qui se focalise d’une part, sur la définition, la vérification et la validation des besoins des clients afin d’assurer une compréhension commune entre les différentes parties prenantes, et d’autre part sur la gestion de l’évolution des exigences tout au long d’un projet. Une récente enquête informe que les entreprises utilisant des pratiques médiocres en termes de gestion des exigences ont subi des coûts pouvant atteindre jusqu'à 60% du budget et enregistraient trois fois plus d’échecs de leurs projets que de réussites [IBM]. Par conséquent, le processus de gestions des exigences est considéré comme étant très critique dans le processus de mise en œuvre du logiciel car elle est la base de l’estimation des coûts, de la planification, de l’exécution et du suivi des activités tout au long d’un projet. En d’autres termes, l’introduction de toute erreur au niveau de ce processus aura des répercussions non négligeables sur toutes les activités subséquentes d’un projet. Lorsqu’une gestion adéquate des exigences est mise en œuvre, on récolte les avantages suivants :

Une réduction du nombre d'exigences inexactes, incomplètes ou oubliées [IBM]. Un raccourcissement du délai de mise en production via une collaboration avec les parties

prenantes [IBM]. Une preuve de conformité grâce à une traçabilité entre les exigences et les différentes

activités du projet [IBM]. Une hausse de la productivité grâce à un contrôle et une gestion des modifications des

exigences [IBM].© Prénom Nom

http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html


Une réduction des coûts et des risques via une mesure de l'impact des changements lorsque ceux-ci surviennent [IBM].

On saisit mieux l’importance de la phase de gestion des exigences quand on sait que le taux d’introduction d’erreurs lors de cette phase est de l’ordre de 50% (Selby 2007)1 :

Figure 1 Les origines des défauts de logiciel (Selby 2007)

De plus, la non-découverte des erreurs lors de cette phase engendre des coûts énormes qu’on peut bien éviter en implantant des activités d’assurance qualité standards. En effet selon des études effectuées par IBM2 la correction des erreurs en production, introduites lors de cette phase, coûte jusqu’à 100 fois plus qu’en phase des exigences:

1 Selby, P., Selby, R.W., Measurement-Driven Systems Engineering Using Six Sigma Techniques to Improve Software Defect Detection, Proceedings of 17th International Symposium, INCOSE, June 2007, San Diego.2 http://mcnickle.org/are-you-testing-your-software-too-late-in-the-process/.

© Prénom Nom

http://mcnickle.org/are-you-testing-your-software-too-late-in-the-process/


Figure 2 : IBM Systems Sciences Institute – Les coûts relatives aux corrections d’erreurs

À la lumière de ces évidences, il devient primordial de mettre en place les activités nécessaires à la réalisation d’une gestion adéquate des exigences d’un projet.

© Prénom Nom


2. Définitions

Dans cette section, le lecteur trouvera deux groupes de définitions. Le premier groupe définit les termes utilisés dans toutes les trousses de déploiement, c'est-à-dire, les termes génériques. Le deuxième groupe définit les termes utilisés dans cette trousse de déploiement, c'est-à-dire, les termes spécifiques. Ces termes sont énumérés en ordre alphabétique.

2.1 Termes génériques Activité : ensemble de tâches liées. [ISO/IEC 12207].Artefact : Une information qui n'est pas décrite dans l'ISO/CEI TR 29110-5 mais qui peut aider un TPO pendant l'exécution d'un projet. (p. ex. un cas d’utilisation).Étape : Dans une trousse de déploiement, une tâche/sous-tâche est décomposée en une suite d’étapes.Processus : Un ensemble d’activités corrélées ou en interaction, qui transforme des éléments d’entrée en éléments de sorite. [ISO/IEC 12207].Produit : Un ensemble d’information ou un livrable qui peut être produit (de manière non obligatoire) par une ou plusieurs tâches. (p. ex. le document de conception, le code source). Rôle : Une fonction définie, destinée à être exécutée par un membre de l’équipe du projet. Par exemple testeur, inspecteur, codeur. [ISO/IEC 24765]Sous-Tâche: Lorsqu’une tâche est complexe, elle est divisée en sous-tâches.Tâche: Une action requise, recommandée ou permise destinée à contribuer à l’accomplissement d’un ou plusieurs résultats d’un processus. [ISO/IEC 12207].

2.2 Termes spécifiques

Analyse des exigences: Le processus d'étude des besoins des utilisateurs pour en arriver à une définition des systèmes, matériels ou logiciels requis. [ISO / IEC 24765]

Document d’exigences: Un document contenant toute combinaison de recommandations, exigences ou règlements à respecter par un logiciel. [ISO / IEC 24765]

Phase d'exigences: la période de temps dans le cycle de vie du logiciel au cours de laquelle les conditions requises pour un produit logiciel sont définis et documentés. [ISO / IEC 24765]

Spécification des exigences du logiciel: La spécification pour un produit logiciel particulier, un programme ou ensemble de programmes qui effectue certaines fonctions dans un environnement spécifique. La spécification des exigences du logiciel peut être écrite par un ou plusieurs représentants du fournisseur, un ou plusieurs représentants du client, ou par les deux. [IEEE830-98]La spécification des exigences du logiciel contient à la fois fonctionnels et non fonctionnels exigences.La spécification des exigences du logiciel peut être matérialisée dans un document Word, mais il peut également être géré dans une base de données ou dans un fichier Excel.

Exigence: © Prénom Nom


1. Une déclaration qui identifie ce qu’un un produit ou un procédé doit accomplir pour produire un comportement et/ou des résultats souhaités. [IEEE 1220-2005] 2. Un système ou une exigence logicielle qui spécifie une fonction qu'un système/system logiciel ou un système/composant logiciel doit être capable d'accomplir. [ISO / CEI 24765]3. Une exigence qui spécifie une fonction qu'un système ou un composant du système doit être capable d'exécuter. [ISO/IEC24765]

Tâche: une exigence, recommandation ou action admissible, qui vise à contribuer à la réalisation d'un ou plusieurs résultats d'un processus [ISO / IEC 12207]

UP (Unified Process) : Le processus unifié est un processus de développement, centré sur l’architecture, piloté par des cas d’utilisation et orienté verts la diminution des risques. C’est un patron de processus pouvant être adapté à une large classe de systèmes logiciels, à différents domaines d’application, à différents types d’entreprise, à différents niveaux de compétence et à différentes tailles d’entreprise.

© Prénom Nom


3. Liens avec la norme ISO/IEC 29110

Cette trousse de déploiement présente les activités liées au rapport technique ISO/IEC 29110-5-1-2 pour les très petits organismes (TPO) - groupe de profils génériques : profil basique [ISO/IEC 29110].

Le rapport technique, le Guide de gestion et d’ingénierie, fournit un processus de gestion de projet et un processus de mise en œuvre du logiciel. Ces processus intègrent des pratiques basées sur la sélection de processus de la norme ISO/IEC 12207:2008 Ingénierie des systèmes et du logiciel - Processus du cycle de vie du logiciel et de produits de documentation du standard ISO/IEC 15289:2011 Ingénierie des systèmes et du logiciel - Contenu des systèmes et produits d'information du processus de cycle de vie du logiciel (documentation).

Le but du processus de gestion de projet est d’établir et de réaliser, systématiquement, les tâches inhérentes au projet de déploiement du logiciel, lesquelles permettent d’assurer la conformité avec les Objectifs du projet en matière de qualité, de durée et de budget.

Le but du processus de mise en œuvre du logiciel consiste à assurer la performance systématique des activités d'analyse, de conception, de développement, d'intégration et de tests de produits logiciels, nouveaux ou modifiés, selon les exigences établies.

Ces processus sont interdépendants (voir la figure 1).

Figure 1 — Processus directeurs du profil basique [ISO 29110-5-1-2]

© Prénom Nom


4. Description des processus, activités, tâches, étapes, rôles et produits

Le diagramme suivant montre le flux d'information entre les activités du processus de mise en œuvre du logiciel et montre les produits de travail les plus importants.

Figure 2 — Diagramme du processus de la mise en œuvre du logiciel du profil basique [ISO/IEC 29110]

Cette trousse de déploiement s’intéresse à l’activité d’Analyse des exigences du logiciel qui consiste à analyser les exigences établies en accord avec le client et à valider la portée du projet.

Dans cette section, le lecteur trouvera la liste des tâches de ladite activité, la description de ses rôles et enfin la description de ses artefacts.

4.1. Les tâches de l’activité d’Analyse des exigences du logiciel

© Prénom Nom


4.1.1 Assignation des tâches

But : Assigner les tâches aux membres de l’équipe de travail selon le plan de projet.

Justification : Les tâches doivent être partagées entre les membres de l’équipe de travail selon leurs rôles et l’échéancier établi dans le plan du projet.

Rôles : TL : Chef technique.WT : Équipe de travail.

Artefacts : - Plan de projet (Tâches).

Étapes : Étape 1. Consulter les tâches du plan de projet.Étape 2. Assigner les tâches aux membres de l’équipe de travail.

Description des étapes :

Étape 1. Recueillir les tâches du plan de projetLe chef technique consulte le plan de projet, et plus précisément la section où les tâches ont été définies.Étape 2. Assigner les tâches aux membres de l’équipe de travailLe chef technique assigne les tâches aux membres de l’équipe de travail selon leurs rôles et l’échéancier du projet. Cette étape peut être effectuée en collaboration entre le chef technique et les membres de l’équipe de travail.

4.1.2 Documenter ou mettre à jour la Spécification des exigences du logiciel

But : Identifier ou mettre à jour les exigences établies afin de les analyser et de déterminer la portée et la faisabilité du projet.

Justification : L’établissement de la faisabilité du projet ainsi que sa portée reposent essentiellement sur la spécification des exigences.

Rôles : AN : Analyste.CUS : Client.

Artefacts : - Plan de projet (Description du produit).- Document de spécification des exigences.

Étapes : Étape 1. Consulter le document des exigences s’il a déjà été établi.Étape 2. Repérer et consulter les sources d’information nécessaires afin d’identifier ou de découvrir les exigences du logiciel.Étape 3. Analyser les exigences établies à l’étape précédente.Étape 4. Générer ou mettre à jour la Spécification des exigences.


Étape 1. Consulter le document des exigences s’il a déjà été établiSi le document de spécification des exigences a déjà été établi, il faut le consulter et prendre connaissance des exigences déjà établies afin de préparer l’étape 2.Étape 2. Repérer et consulter les sources d’information afin d’identifier ou de découvrir les exigencesL’analyste recense les exigences en consultant le client, les utilisateurs, les systèmes précédents, les documents, etc.

© Prénom Nom


Étape 3. Analyser les exigences recueilliesUne fois que les exigences ont été recueillies et établies, l’analyste doit les analyser afin de les répertorier, de les classer par catégorie (exigences fonctionnelles, exigences non fonctionnelles, etc.), de leur donner des priorités, de déterminer leur faisabilité, et de déterminer les liens et les conflits entre elles.Étape 4. Générer ou mettre à jour la Spécification des exigencesUne fois les exigences ont été analysées, regroupées et priorisées, l’analyste procède à la génération ou à la mise à jour du document de Spécification des exigences en utilisant des techniques formelles (UML, réseaux de pétri, etc.) ou non pour spécifier ou décrire ces exigences en vue d’une utilisation dans les phases suivantes du cycle de développement.

4.1.3 Vérifier la Spécification des exigences et en obtenir l’approbation

But : Vérifier l’exactitude et la testabilité de la spécification des exigences ainsi que de sa cohérence avec la description du produit.

Justification : Il est primordial de lever toute ambigüité et de s’assurer que les exigences sont complètes et ne se contredisent pas. Ce document est la base de toutes les activités subséquentes du processus de mise en œuvre du logiciel et toute incohérence ou erreur peut avoir des conséquences négatives sur la qualité du produit.

Rôles : AN : Analyste.TL : Chef technique.

Artefacts : - Spécification des exigences.- Plan de projet (Description du produit).- Résultats de la vérification.- Demande de changement.

Étapes : Étape 1. Vérifier les exigences.Étape 2. Générer le document des Résultats de la vérification.Étape 3. Mettre à jour le document de Spécification des exigences.Étape 4. Initier une Demande de changement si nécessaire.


Étape 1. Vérifier les exigencesVérifier l’exactitude et la testabilité des exigences et leur cohérence avec la description du produit, il faut s’assurer qu’elles sont complètes, non ambigües et qu’elles ne se contredisent pas.Étape 2. Générer le document des Résultats de la vérificationUne fois la vérification est effectuée, on répertorie les résultats des vérifications dans le document des Résultats de la vérification.Étape 3. Mettre à jour le document de Spécification des exigencesLes vérifications peuvent aboutir à des changements plus au moins mineurs aux exigences, il faut alors mettre à jour le document de Spécification des exigences.Étape 4. Initier une Demande de changement si nécessaireLes vérifications peuvent aboutir à des changements majeurs. Dans tel

© Prénom Nom


cas, il faut initier des demandes de changements.

4.1.4 Valider la Spécification des exigences et en obtenir l’approbation

But : S’assurer que la Spécification des exigences réponde aux besoins et aux attentes du client.

Justification : Cette tâche permet, d’une part, au client de réviser les exigences et de s’assurer que l’analyste a bien compris ses besoins et, d’autre part, de minimiser les demandes de changements majeurs.

Rôles : CUS : Client.AN : Analyste.

Artefacts : - Spécification des exigences.- Résultats de la validation.

Étapes : Étape 1. Valider les exigences.Étape 2. Générer le document des Résultats de la validation.Étape 3. Mettre à jour le document de Spécification des exigences.


Étape 1. Valider les exigencesS’assurer que la Spécification des exigences réponde aux besoins et aux attentes du client en contrôlant leur cohérence, leur complétude, leur accessibilité, leur vérifiabilité, la convivialité de l’interface, etc.Étape 2. Générer le document des Résultats de la validationUne fois la validation est effectuée, on répertorie les résultats des validations dans le document des Résultats de la validation.Étape 3. Mettre à jour le document de Spécification des exigencesEn cas de non approbation du document de Spécification des exigences par le client, il faut alors modifier les exigences qui s’y trouvent.

4.1.5 Produire ou Mettre à jour la matrice traçabilité

But : Décrire et suivre la vie d’une exigence dans les deux directions amont et avale d’un projet.

Justification : Elle facilite la maitrise de l’évolution des exigences et la gestion des relations entre les exigences.

Rôles : AN : Analyste.Artefacts : - Dépôt d’information du projet

- Document de Spécifications logicielles.- Matrice de traçabilité.

Étapes : Étape 1. Lier les besoins aux exigences spécifiées.Étape 2. Lier les exigences spécifiées aux différents artefacts du projet.


Étape 1. Lier les besoins aux exigences spécifiéesEn se basant sur les documents de dépôt d’information et de Spécification des exigences, produire ou mettre à jour la matrice de traçabilité afin de pouvoir contrôler l’évolution des exigences et gérer les

© Prénom Nom


relations entre les exigences.Étape 2. Lier les exigences spécifiées aux différents artefacts du projetÉtablir une liaison entre les exigences spécifiées et les autres artefacts du projet afin d’une part de mieux analyser l’impact d’un changement sur les spécifications et d’autre part de mieux comprendre l’existence et L’origine des artefacts produits durant le cycle de vie du projet.

4.1.6 Documentation de l’utilisateur du logiciel (Facultatif)

But : Documenter la version préliminaire de la Documentation de l’utilisateur du logiciel ou la mettre à jour.

Justification : La documentation utilisateur décrit les différentes fonctionnalités du logiciel. Cela aide les utilisateurs à mieux comprendre l’utilisabilité du produit en s’appuyant sur des procédures ou même des tutoriels.

Rôles : AN : Analyste.Artefacts : - Spécification des exigences.

- Documentation de l’utilisateur du logiciel.

Étapes : Étape 1. Produire la documentation de l’utilisateur du logiciel.Description des étapes :

Étape 1. Produire la Documentation de l’utilisateur du logicielEn se basant sur la Spécification des exigences, produire la documentation de l’utilisateur du logiciel, cela peut avoir la forme de tutoriels par exemple.

4.1.7 Vérifier la Documentation de l’utilisateur du logiciel (Facultatif)

But : Vérifier et approuver la Documentation de l’utilisateur du logiciel.Justification : Les documents des utilisateurs doivent être cohérents avec la

Spécification des exigences afin de s’assurer que les utilisateurs utilisent le logiciel tel qu’il a été spécifié.

Rôles : AN : Analyste.TL : Chef technique.

Artefacts : - Spécification des exigences.- Documentation de l’utilisateur du logiciel.- Résultats de la vérification.- Demande de changement.

Étapes : Étape 1. Vérifier la Documentation de l’utilisateur du logiciel en se basant sur la Spécification des exigences.Étape 2. Générer le document des Résultats de la vérification.Étape 3. Mettre à jour la Documentation de l’utilisateur du logiciel.Étape 4. Initier une Demande de changement si nécessaire.

© Prénom Nom



Étape 1. Vérifier la Documentation de l’utilisateur du logicielVérifier la cohérence de la Documentation de l’utilisateur du logiciel avec la Spécification des exigences.Étape 2. Générer le document des Résultats de la vérificationUne fois la vérification est effectuée, on répertorie les résultats des vérifications dans le document des Résultats de la vérification.Étape 3. Mettre à jour le document de Spécification des exigencesLes vérifications peuvent aboutir à des changements plus au moins mineurs à la Documentation de l’utilisateur du logiciel, il faut alors la mettre à jour.Étape 4. Initier une Demande de changement si nécessaireLes vérifications peuvent aboutir à des changements majeurs. Dans tel cas, il faut initier des demandes de changements.

4.1.8 Intégrer la Spécification des exigences et la Documentation de l’utilisateur du logiciel

But : Gérer la configuration du logiciel en y intégrant la Spécification des exigences et la Documentation de l’utilisateur du logiciel.

Justification : Tous les livrables du projet doivent être intégré à la Configuration du logiciel.

Rôles : TL : Chef technique.Artefacts : - Configuration du logiciel.

o Spécification des exigences.o Documentation de l’utilisateur du logiciel (Facultatif).

Étapes : Étape 1. Intégrer la Spécification des exigences et la Documentation de l’utilisateur du logiciel à la Configuration du logiciel.


Étape 1. Intégrer la Spécification des exigences et la Documentation de l’utilisateur du logiciel à la Configuration du logicielSelon la stratégie établie pour la gestion de configuration pour le projet, le chef technique intègre la Spécification des exigences et la Documentation de l’utilisateur du logiciel à la Configuration du logiciel.

4.2 Description des rôlesCette section donne une liste alphabétique des rôles, des abréviations et de la description des compétences souhaitées. Il est suggéré d’utiliser les rôles, abréviations du Guide de gestion et d’ingénierie.

Rôle Abréviation

Compétences

Client CUS - Connaissance des processus d’affaires de la compagnie.- Contribution à l’identification des exigences.- Valider et approuver les exigences et les demandes de

changements.

Analyste AN - Identification et analyse des exigences.© Prénom Nom


Rôle Abréviation

Compétences

- Connaissance des processus d’affaires génériques que le client opère.

- Maitrise et connaissance de l’activité d’analyse des exigences.

- Connaissance du processus de mise en œuvre du logiciel.

Chef technique TL - Maitrise des aspects techniques et technologiques du projet.

- Connaissance du processus de mise en œuvre du logiciel.

Équipe de travail WT - Connaissance et expérience de chaque membre dans le domaine du rôle qui lui est attribué.

4.3. Description des artefacts Cette section donne une liste alphabétique des artefacts (c.-à-d. des documents papier ou électroniques) nécessaires à la réalisation des tâches décrites ci-dessus. Ce sont les intrants, les extrants et les documents produits pendant l’exécution des tâches mais qui ne seront pas diffusés à l’extérieur du projet.

Nom de l'artefact Description

Plan de projetLe plan de projet est élaboré en fonction de l’Énoncé des travaux et comporte entre autres les tâches et les ressources nécessaires pour accomplir le travail.

Spécification des exigencesDocument contenant toutes les exigences identifiées, analysées et vérifiées par l’équipe de travail. Ce document doit être validé par le client.

Résultats de la vérification (Spécification es exigences)

Registre listant les vérifications effectuées par l’analyste et le chef technique pour la Spécification des exigences.

Demande du changement (Spécification es exigences)

Document demandant et justifiant un changement souhaité pour une ou plusieurs exigences.

Résultats de la validation (Spécification es exigences)

Registre listant les validations et leurs résultats effectués par le client pour la Spécification des exigences.

Documentation de l’utilisateur logiciel

Décrit les différentes fonctionnalités du logiciel. Cela aide les utilisateurs à mieux comprendre l’utilisabilité du produit en s’appuyant sur des procédures ou même des tutoriels.

Résultats de la vérification (Documentation de l’utilisateur logiciel)

Registre listant les vérifications effectuées par l’analyste et le chef technique pour la Documentation de l’utilisateur logiciel.

Demande du changement (Documentation de l’utilisateur logiciel)

Document demandant et justifiant un changement souhaité pour la Documentation de l’utilisateur logiciel.

© Prénom Nom


Configuration du logiciel Suivi et contrôle des changements et des versions du logiciel.

Matrice de traçabilité Document contenant les liens entre les exigences et les différentes activités réalisées tout au long du projet.

© Prénom Nom


5. Gabarits et outils

Cette section décrit les gabarits et outils qui facilitent la mise en œuvre du contenu de cette trousse. 5.1 Gabarits

Le gabarit qui est fourni dans ce document n’est qu’un exemple, il doit être personnalisé à votre projet.

5.1.1 Spécification des exigences

Le lecteur peut se référer à la norme IEEE Std 830-98 qui offre huit (8) modèles différents pour produire le document de Spécification des exigences. Le lecteur trouvera dans les annexes A et B des exemples de document de Spécification des exigences et de matrice de traçabilité qui ont été réalisés dans le cadre d’un projet scolaire. 5.2 Outils

Les outils proposés sont disponibles à titre de logiciels libres sur internet.

5.2.1 Outils de gestion des exigences

Plusieurs outils de gestion de exigences sont disponibles gratuitement, l’Annexe C présente une liste de ces outils ainsi qu’un lien pour télécharger le logiciel. La liste n’est pas exhaustive et d’autres outils peuvent y être ajoutés.

© Prénom Nom


6. Exemple de la mise en œuvre de tâches

Note: Cette section fournit un exemple d'une représentation graphique de la mise en œuvre de tâches. Cet exemple vise à aider le lecteur à mettre en œuvre son propre cycle de développement en l’adaptant au contexte de son projet.Exemple de la mise en œuvre de tâches[Ceci est un exemple qui utilise le patron SPEM de Microsoft Visio (http:// www.pa.icar.cnr.it/cossentino/FIPAmeth/docs/SPEM.vss) pour produire ce diagramme.

Figure 3 Exemple de la mise en œuvre de tâches]

© Prénom Nom


7. Listes de vérification

Cette section présente des listes de vérification afin d'aider à la mise en œuvre des tâches de cette trousse.La liste de vérification des exigences est base sur [Constr07]

SE 1 Testable Toutes les exigences sont vérifiables (objectivement)SE 2 Complet Est-ce que toutes les exigences sont complètes?SE 3 Traçable Les exigences sont traçables.SE 4 Exact Les exigences doivent être exactes et satisfont les besoins et

les attentes du client.SE 5 Unique Les exigences doivent être indiquées une seule fois.SE 6 Élémentaire Les exigences doivent être divisées dans leur forme la plus

élémentaire.SE 8 Haut Niveau L’exigence doit être indiquée en termes de nécessité finale,

pas en termes de moyen perçu (solutions).SE 9 Qualité Les attribues de qualité ont été définiesSE 11 Matériel Les composants matériels sont complètement définis.SE 12 Solide Les exigences sont une base solide pour la conception.

© Prénom Nom


8. Matrices de couverture

Cette annexe démontre la traçabilité de cette trousse de déploiement avec des standards de l'ISO et avec le CMMI® pour le développement, version 1.3. Pour chacun des éléments, sa couverture est indiquée selon la convention suivante:

o Couverture complète = C o Couverture partielle = Po Aucune couverture = A

8.1 Matrice de couverture de l'ISO 9001

Titre de la tâche et étape1 CouvertureC/P/A Clause de l'ISO 9001 Commentaires

Documenter ou mettre à jour la Spécification des exigences du logiciel – Étape 2, 3 et 4

P7.2.1 Détermination des exigences relatives au produit

Valider la Spécification des exigences et en obtenir l’approbation – Étape 1

P 7.2.2 Revue des exigences relatives au produit

8.2 Matrice de couverture de l’ISO/IEC 12207

Titre de la tâche et étape1 CouvertureC/P/A

Tâches de l'ISO/IEC 12207 Commentaires


C

7.1.2 Processus d'analyse des exigences di logiciel7.1.2.2 Résultats

Vérifier la Spécification des exigences et en obtenir l’approbation – Étape 1

P

7.1.2 Processus d'analyse des exigences du logiciel

7.1.2.3 Activités et tâches


P



Documentation de l’utilisateur du logiciel – Étape 1 P



© Prénom Nom


Produire ou Mettre à jour la matrice traçabilité – Étape 1, 2 P



8.3 Matrice de couverture du modèle CMMI pour le développement

Titre de la tâche et étape3 CouvertureC/P/A

Objectifs / Pratiques du modèle CMMI V1.3 Commentaires


PDéveloppement des exigences SP 3.5Gérer les exigences SG 1

Vérifier la Spécification des exigences et en obtenir l’approbation – Étape 1

P Vérification SG 1 et SG 3


P Développement des exigences SP 3.5

Produire ou Mettre à jour la matrice traçabilité – Étape 1, 2 P

Développement des exigences SP 3.5Gérer les exigences SG 1

3SM CMM Integration est une marque de service de Carnegie Mellon University.® Capability Maturity Model, CMMI est enregistré U.S. Patent and Trademark Office par Carnegie

Mellon University. Ceci est le titre de la tâche de la section 4 de cette trousse.

© Prénom Nom


9. Références

Nom Référence[ISO/IEC 29110-5-1-2] ISO/IEC TR 29110-5-1-2:2011, Ingénierie du logiciel - Profils de

cycle de vie pour très petits organismes (TPO) - Partie 5-1-2: Guide de gestion et d'ingénierie: Groupe de profil générique: Profil basique.Ce document est disponible gratuitement sur le site suivant:http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html

[ISO/IEC 12207] ISO/IEC 12207:2008 Systems and software engineering – Software life cycle processes.

[ISO/IEC 15289] ISO/IEC 15289:2011 Systems and software engineering - Content of systems and software life cycle process information products (Documentation)

[ISO/IEC/IEEE 24765] ISO/IEC/IEEE 24765:2010 Systems and software engineering vocabulary.Une version électronique du vocabulaire est disponible à: http://pascal.computer.org/sev_display/index.action

[CMMI] Software Engineering Institute, CMMI pour le Développement, Version 1.3, CMU/SEI-2010-TR-033, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, 2010.

[ISO 9001] ISO 9001, Systèmes de management de la qualité — Exigences, Organisation internationale de normalisation, Genève, 2008.

[IEEE 830-98] IEEE Std 830-98, IEEE Recommended Practice for Software Requirements Specifications

IBM http://www-01.ibm.com/software/fr/rational/rm/

© Prénom Nom

http://pascal.computer.org/sev_display/index.action

http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html


10. Formulaire d’évaluation de la trousse

Trousse de déploiement – Analyse des exigences du logiciel – Profil basique Version 0.1Vos commentaires nous permettront d'améliorer cette trousse de déploiement; vos suggestions sont les bienvenues.

1. Est-ce que le contenu de cette trousse de déploiement vous satisfait? Très satisfait Satisfait Ni Satisfait ni insatisfait Insatisfait Très Insatisfait

2. Par rapport à la SÉQUENCE dans laquelle les sujets sont discutés, vous êtes ? Très satisfait Satisfait Ni Satisfait ni insatisfait Insatisfait Très Insatisfait

3. Par rapport à l’APPARENCE/FORMAT de cette trousse de déploiement, vous êtes? Très satisfait Satisfait Ni Satisfait ni insatisfait Insatisfait Très Insatisfait

4. Considérez-vous que cette trousse contient des sujets inutiles? (décrivez-les S.V.P.)

5. Considérez-vous que cette trousse manque de sujets importants? (décrivez-les S.V.P.) Sujet proposé : Justification du nouveau sujet:

6. Considérez-vous que cette trousse a des erreurs? S’il vous plaît indiquez:

Description de l’erreur: Position de l’erreur dans le document (section #, figure #, table #) :

7. Avez-vous d’autres informations ou commentaires?

8. Est-ce que vous recommanderez cette trousse de déploiement à un collègue d’une autre TPO?

Certainement Probablement Peut-être Probablement non Certainement non

Optionnel Nom: courriel : _________________________________________

Complétez ce formulaire et envoyez-le à l’adresse suivante: [email protected]

© Prénom Nom

mailto:[email protected]


Annexe A : Exemple de document de Spécification des exigences

Deployment Package – Software Requirements Analysis1. Introduction

[Elle comprend l’objectif du document, sa portée, les définitions, acronymes et abréviations, les références et une vue d’ensemble du document.]

1.1 Objectif

[Préciser les objectifs de ce document en décrivant le comportement externe de l’application ou sous-système identifié ainsi que les exigences non-fonctionnelles ou tout autre facteur nécessaire à une description complète et compréhensible des exigences pour le logiciel.]

L’objectif de ce document est d’exposer le comportement externe du système Client Management And Shared Agenda (CMSA) du point de vue de l’utilisateur. Il présente avec minutie une liste des exigences fonctionnelles et non fonctionnelles contenues dans le document de vision rédigé préalablement en partenariat avec les différents intervenants du projet. En d’autres termes, ce document constitue une vue globale du système CMSA en tenant compte des acteurs et des cas d'utilisation. Chaque cas d'utilisation fait également l'objet d'une spécification, qui sera intégrée à ce document en annexe.

1.2 Portée

[Une brève description de la portée de ce document, l’application qu’il décrit, les caractéristiques ou autres sous-systèmes auxquels l’application est associée, ainsi que tout autre chose qui peut être influencée ou affectée par ce document.]

Le système CSMA se veut une solution dans la gestion informatisée des entreprises travaillant conjointement avec le ministère de l’emploi au Québec. Il permettra aux utilisateurs d’effectuer les opérations (ajout, modification et recherche) inhérentes aux clients, de gérer leur calendrier d’activités (rendez-vous et réunion) et de planifier les différentes réunions, en utilisant une interface ergonomique. Ce document contient l’analyse détaillée des spécifications et englobe l’ensemble des exigences qui s’appliquent au système CMSA.

Pour avoir des informations plus détaillées sur la portée du système CMSA, référez-vous à la section 1.2 du document de vision.

1.3 Références

[Cette section comporte la liste de tous les documents cités dans le document. Chaque document doit être identifié par son titre, son numéro, lorsque applicable, sa date et l’organisation qui l’a publiée. Les sources qui peuvent fournir les références doivent être citées. Cette dernière information peut être elle-même une référence à une annexe ou à un autre document.]

CMSA-REF-01. Petit Larousse illustré 2008, Librairie Larousse

CMSA-REF-02. http://msdn.microsoft.com/en-us/library/aa378932(VS.85).aspx

CMSA-REF-03. Site de cours MGL801 Exigences et Spécifications de Systèmes Logiciels, www.etsmtl.ca.CMSA-REF-04. Document de Vision de CMSA, Elie JOSEPH, octobre 2010 CMSA-REF-05. Site de Quint2.

1.4 Hypothèses et Dépendances

[Décrire tout élément de faisabilité technique, disponibilité de sous-système ou de composant ou toute autre hypothèse liée au projet de laquelle dépend la viabilité du logiciel.]

© Prénom Nom

http://www.etsmtl.ca/

http://msdn.microsoft.com/en-us/library/aa378932(VS.85).aspx


Pour réaliser ce logiciel, nous devons assumer certaines hypothèses. Ces dernières peuvent se résumer comme suit:

H1. Nous présumons qu’il n’y aura pas de changements au niveau des exigences qui pourraient avoir un impact considérable sur le développement de ce logiciel.

H2. Nous présumons qu’il n’y aura pas des changements de hardware et de software qui pourraient avoir un impact sur le développement de ce logiciel.

H3. Tout changement approuvé dans le document de vision aura un impact sur ce document.

2. Survol du Modèle des Cas d’Utilisation [Cette section comporte le modèle des cas d’utilisation et une brève description de chaque cas d’utilisation.] Le survol du modèle des cas d’utilisation illustre les principales fonctionnalités du système CMSA et est subdivisé en quatre (4) sections:

- Secrétaire: Cette section représente les différents cas d’utilisation (ajout d’un client, générer un rapport, etc.) inhérents à un secrétaire. (Figure I)

- Conseiller: Cette section représente les différents cas d’utilisation (ajout d’un rendez-vous, etc.) inhérents à un conseiller. (Figure II)

- etc.

Secrétaire

Figure I: Diagramme de cas d’utilisation du secrétaire

Chaque cas d’utilisation mentionné plus haut est décrit dans les lignes qui suivent:

© Prénom Nom


CMSA-UCS-000.S’authentifier

L’utilisateur accède au système en utilisant un nom d’utilisateur unique et un mot de passe afin d’exploiter les fonctionnalités qui lui sont permises.

Acteurs associés : Secrétaire / Administratrice / Conseiller / Administrateur du système.

CMSA-UCS-001. Générer un rapport sur les clients

L’utilisateur peut demander au système de lui produire un rapport contenant un ensemble d’informations sur les clients en sélectionnant une session ou une année. Ce rapport peut être consulté à l’écran ou imprimé sur papier.

Acteurs associés : Secrétaire / Administratrice.

3. Les acteurs

[Cette section comporte la liste de tous les acteurs et les fonctionnalités du système qui s’y rapportent.]

CMSA-ACT-001. Secrétaire

Le secrétaire est un utilisateur qui se sert du système en vue de réaliser ses tâches quotidiennes. Il est responsable principalement de:

- la gestion des clients

- la production des rapports inhérents aux clients

- la gestion des rendez-vous entre un client et un conseiller

- l’intégration des activités réalisées ou planifiées dans son agenda.

CMSA-ACT-002. Conseiller

Le conseiller est un utilisateur qui se sert principalement du système pour pouvoir:

- gérer ses rendez-vous avec les clients

- Intégrer les activités réalisées ou planifiées dans son agenda.

4. Les exigences

4.1 Les exigences fonctionnelles

[Décrire les exigences fonctionnelles du système qui ne peuvent pas être exprimées par des cas d’utilisation.]

CMSA-FSR-001. La fiche d’un client doit contenir les éléments suivants:

- Ses informations personnelles (nom, prénom, identifiant d’emploi-Québec, adresse, téléphone, formation, service, session, année, identifiant du système)

- Ses rendez-vous (date, nom du conseiller, heure)

- Ses réunions de groupe ou ateliers (date, heure, nom du conseiller, sujet)

CMSA-FSR-002. Lors d’un ajout ou d’une modification, le logiciel doit vérifier que tous les champs obligatoires ont été correctement remplis.

4.2 Les exigences non fonctionnelles

[Décrire d’une manière vérifiable les exigences non fonctionnelles que doivent respecter le système]

© Prénom Nom


Les exigences suivantes sont regroupées selon les caractéristiques du modèle QUINT2.

4.2.1 Facilité d’utilisation

1. Facilité d’apprentissage CMSA-NFCS-001: Apprentissage à partir d’une séance de formation

Un secrétaire doit pouvoir apprendre en cent vingt (120) minutes de formation les opérations suivantes :

Ajout d’un client. Ajout d’un rendez-vous. Rechercher la fiche d’un client. Générer un rapport sur un ensemble de clients.

CMSA-NFCS-002: Apprentissage à partir de l’aide en ligneUn utilisateur doit être capable d’apprendre les opérations (ajout, modification et la suppression d’une activité, etc.) liées à la gestion de son agenda à partir de l’aide en ligne dans moins de cent vingt (120) minutes.

5. Documentation en direct pour l’utilisateur et exigences du système d’aide

[Décrire les exigences de documentation]

Les exigences de documentation sont présentées dans les lignes qui suivent:

CMSA-DSR-001: Langage des documents.

Tous les documents doivent être rédigés en français.

6. Contraintes de conception

[Décrire les contraintes imposées au développement du système]

Cette section présente les contraintes de conception.

CMSA-CC-001: Langage de programmation. Le logiciel doit être codé en utilisant le langage Microsoft Visual Studio 2008.

7. Composants achetés

[Décrire les composants spécifiques (logiciels ou matériels) achetés pour la réalisation du système.]

NA.

8. Interfaces

8.1 Interfaces Utilisateur

[Décrire les interfaces utilisateur ou référer au prototype d’interface utilisateur.]

Les interfaces présentées ci-dessous ne sont que des suggestions. Elles ne représentent en aucun cas des modèles définitifs.

Interface 1 :

Cas d’utilisation associé(s): CMSA-UCS-000

© Prénom Nom


La figure suivante illustre le processus d’identification d’un utilisateur auprès du système. Cette boite de dialogue permet à l’utilisateur de se connecter au système en fournissant un nom d’utilisateur unique ainsi qu’un mot de passe. Ce dernier est voilé par le caractère *.

Figure 5: Fenêtre de connexion au système.

8.2 Interfaces Matérielles

[Définir les interfaces entre le logiciel et le matériel, incluant la structure logique, les adresses physiques, le comportement attendu, etc.]

NA

8.3 Interfaces Logicielles

[Décrire les interfaces logicielles avec les autres composants du système. Ce peut être des composants achetés. Des composants de d’autres applications qui sont réutilisés ou des composants développés pour des sous-systèmes hors de la portée du présent document.]

NA

8.4 Interfaces de Communications

[Décrire les interfaces de communication avec les autres systèmes comme les réseaux locaux, les serveurs distants, etc.]

NA

9. Exigences de Licences

[Décrire les licences nécessaires pour le développement du système. Cela peut être les licences d’un composant acheté]

NA

10. Remarques légales, de droits d’auteur, et diverses

[Décrire les contraintes légales qui sont imposées au développement du système]

NA

11. Standards Applicables

[Décrire par référence toutes normes applicables et les sections précises de ces normes qui s’appliquent au système. Cela inclut, par exemple, les normes de qualité, légales ou réglementaire, les normes industrielles d’utilisabilité, l’interopérabilité, les normes d’internationalisation, conformité au système d’exploitation, etc.]

© Prénom Nom


Le processus de développement ainsi que le produit résultant doivent respecter le modèle de qualité ISO 9126 et QUINT2.

La mise en forme du code source doit respecter les règles proposées par le document: Coding Style Conventions de Windows.

© Prénom Nom


Développement des cas d’utilisation[Décrire en détail chaque cas d’utilisation en spécifiant les post conditions et les pré conditions ainsi que le scénario nominal.]

CMSA-UCS-000. S’authentifierBrève Description

L’utilisateur accède au système en utilisant un nom d’utilisateur unique et un mot de passe afin d’exploiter les fonctionnalités qui lui sont permises.

Pré-condition1. Avoir un compte utilisateur.

Flux d’événements

Flux de Base

1. L’utilisateur demande au système de lui afficher la fenêtre de connexion au système CMSA.2. Le système affiche la fenêtre de connexion.3. Dans la fenêtre qui apparait l’utilisateur saisit son nom utilisateur et son mot de passe puis clique sur le bouton OK.4. Si les informations saisies sont correctes, le système affiche la fenêtre principale du système CMSA.*

Flux alternatif

a. Les informations saisies ne sont pas correctes : Ce flux arrive à l’étape 4 du flux de base.

1. Le système affiche un message « Les informations saisies sont incorrectes ».2. Le système retourne à l’étape 3 du flux de base

b. La personne qui tente d’accéder au système est déjà connectée : Ce flux arrive à l’étape 4 du flux de base.

1. Le système affiche un message « Vous êtes déjà connecté ».2 Le système retourne à l’étape 3 du flux de base

Post conditions

1. Le système change la valeur de l’état de l’utilisateur en connecté.

2. La transaction est enregistrée dans un fichier Log.

© Prénom Nom


Annexe B : Exemple de matrice de traçabilité

Caractéristique Cas d’utilisation Exigence fonctionnelle

Exigence non fonctionnelle

Contrainte de conception

Ajout d'un nouveau client (CAR.1)

CMSA-UCS-002 CMSA-FSR-001CMSA-FSR-002CMSA-FSR-004CMSA-FSR-006CMSA-FSR-008

CMSA-NFCS-006CMSA-NFCS-010CMSA-NFCS-011CMSA-NFCS-014

Modification de la fiche d'un client (CAR.2)

CMSA-UCS-003 CMSA-FSR-001CMSA-FSR-002CMSA-FSR-004CMSA-FSR-005CMSA-FSR-006CMSA-FSR-008


Recherche de la fiche d'un client (CAR.3)

CMSA-UCS-004 CMSA-FSR-006CMSA-FSR-008

CMSA-NFCS-006CMSA-NFCS-010CMSA-NFCS-014

Afficher tous les clients pour une session donnée (CAR.4)

CMSA-UCS-001 CMSA-FSR-008 CMSA-NFCS-006CMSA-NFCS-014

CMSA-CC-003

Afficher tous les clients pour une année donnée (CAR.5)


CMSA-CC-003

Ajout d'un rendez-vous (CAR.6)

CMSA-UCS-005 CMSA-FSR-002CMSA-FSR-004CMSA-FSR-006CMSA-FSR-008


Modification d'un rendez-vous (CAR.7)



Suppression d'un rendez-vous (CAR.8)

CMSA-UCS-007 CMSA-FSR-005CMSA-FSR-006CMSA-FSR-008

CMSA-NFCS-006CMSA-NFCS-014

Afficher la liste des rendez-vous pour une date donnée


CMSA-CC-003

© Prénom Nom


(CAR.9)Créer un service (CAR.10)



Modifier un service (CAR.11)



Afficher la liste des services (CAR.12)


CMSA-CC-003

Ajout d'une activité dans l'agenda (CAR.13)



Modifier une activité existante dans l'agenda (CAR.14)



Supprimer une activité existante dans l'agenda (CAR.15)



Afficher la liste des activités par employé pour une période donnée (CAR.16)


CMSA-CC-003

Créer un nouvel utilisateur (CAR.17)



Désactiver un utilisateur (CAR.18)



Définir les droits liés à un utilisateur (CAR.19)



© Prénom Nom


CMSA-FSR-008Planifier une réunion (CAR.20)



Modifier la planification d'une réunion (CAR.21)

CMSA-UCS-016

CMSA-UCS-017

CMSA-FSR-002CMSA-FSR-004CMSA-FSR-005CMSA-FSR-006CMSA-FSR-008


Afficher la liste des réunions (CAR.22)


CMSA-CC-003

Afficher les heures libres d'un ensemble de personnes pour une date donnée (CAR.23)

CMSA-UCS-015

CMSA-UCS-016

CMSA-FSR-008 CMSA-NFCS-006CMSA-NFCS-014

CMSA-CC-003

Enregistrer une transaction effectuée (CAR.24)

CMSA-FSR-008 CMSA-NFCS-015

Afficher la liste des transactions par utilisateur ou pour une période donnée (CAR.25)

CMSA-UCS-025 CMSA-NFCS-006CMSA-NFCS-014

CMSA-CC-003

Fiabilité (CAR.26)

CMSA-NFCS-007CMSA-NFCS-008CMSA-NFCS-009CMSA-NFCS-010CMSA-NFCS-011CMSA-NFCS-012CMSA-NFCS-013

Rapidité (CAR.27)


CMSA-CC-004

Efficacité (CAR.28)


CMSA-CC-004

© Prénom Nom



Convivialité (CAR.29)


© Prénom Nom


Annexe C : Outils de gestion des exigences (Logiciels libres)

Outil Description LiensOpen Source Requirements Management Tool

Conçu pour atteindre une traçabilité complète pour SDLC fonctionnalités, les spécifications, la conception, l'implémentation et de test. Il a une interface utilisateur pour la dérivation des exigences, de contrôle de version, et les attributs communs ou personnalisés (justification, la source, le risque, l'effort, etc.) Il est adapté pour les gestionnaires de produits, les développeurs et les analystes de collaborer avec la flexibilité et l'évolutivité.

http://sourceforge.net/projects/osrmt/

SLAM Software Lifecycle Artefact Manager

Application gère les besoins logiciels et des tests fonctionnels associés, y compris les résultats, correspondant aux besoins de traçabilité / tests à tous les temps. Exigences et essais sont formatés comme dans le traitement de texte; documents prêts à imprimer sont générés.

http://slamreq.sourceforge.net/

Agilefant Outil open source de gestion backlog renforcée avec capacités de traitement des exigences hiérarchiques. Agilefant offre trois différents niveaux de planification pour la gestion des retards: des produits, des projets et des backlog d'itération. En plus de traditionnelles listes backlog, les exigences peuvent être exprimées sous forme d'arborescence, afin d'assurer la traçabilité et la transparence.

http://www.agilefant.org/

© Prénom Nom

http://www.agilefant.org/

http://slamreq.sourceforge.net/

http://sourceforge.net/projects/osrmt/

Documents

Deployment Package – Software Requirements Analysisprofs.etsmtl.ca/claporte/VSE/Trousses/Trousse de depl… · Web viewCe document est la propriété intellectuelle de l’organisation