27
«SEG3601» D. Amyot U. Ottawa SEG 3601 SEG 3601 Gestion des exigences avec Gestion des exigences avec DOORS DOORS Adapté de présentations par Telelogic et Amyot 2005- 2012

«SEG3601» D. Amyot U. Ottawa SEG 3601 Gestion des exigences avec DOORS Adapté de présentations par Telelogic et Amyot 2005-2012

Embed Size (px)

Citation preview

Page 1: «SEG3601» D. Amyot U. Ottawa SEG 3601 Gestion des exigences avec DOORS Adapté de présentations par Telelogic et Amyot 2005-2012

«SEG3601»

D. AmyotU. Ottawa

SEG 3601SEG 3601

Gestion des exigences avec DOORSGestion des exigences avec DOORS

Adapté de présentations par Telelogic et Amyot 2005-2012

Page 2: «SEG3601» D. Amyot U. Ottawa SEG 3601 Gestion des exigences avec DOORS Adapté de présentations par Telelogic et Amyot 2005-2012

«SEG3601»

D. AmyotU. Ottawa

Gestion des exigences avec DOORS 2

Préparation du laboratoire• Vérifiez que vous pouvez exécuter DOORS• Téléchargez DOORS_101.dpa de TWiki et

sauvegardez le sur votre bureau (desktop)

http://cserg0.site.uottawa.ca/seg/bin/view/SEG3601/WebHome

Page 3: «SEG3601» D. Amyot U. Ottawa SEG 3601 Gestion des exigences avec DOORS Adapté de présentations par Telelogic et Amyot 2005-2012

«SEG3601»

D. AmyotU. Ottawa

Gestion des exigences avec DOORS 3

Avantages de la gestion des exigences

Traçabilité entres les exigences de haut niveau et ceux d’implémentation• Établie grâce à des liens ajoutés dans une base de données des

exigences• Liens entre les exigences, les modèles de design, les tests, le

code. Analyse de l’impact de changements proposés

• Des outils d’analyse permettent de visualiser quelles exigences (et autres artéfacts) sont affectés par un changement.

Accès contrôlé à l’information courante d’un projet• Une base de données partagée assure que tous les utilisateurs

travaillent avec la plus récente copie des données• Une base de données centrale permet à tous les utilisateurs de

voir toute l’information requiseGestion des changements

• Un système de proposition des changements implémente un processus contrôlé pour gérer les changements.

Page 4: «SEG3601» D. Amyot U. Ottawa SEG 3601 Gestion des exigences avec DOORS Adapté de présentations par Telelogic et Amyot 2005-2012

«SEG3601»

D. AmyotU. Ottawa

Gestion des exigences avec DOORS 4

Base de données DOORS (v8.x)

Répertoiresupprimé

Modules de liens (Link modules)

Répertoires (Folders)

Projets Modules formels (Formal Modules)

Page 5: «SEG3601» D. Amyot U. Ottawa SEG 3601 Gestion des exigences avec DOORS Adapté de présentations par Telelogic et Amyot 2005-2012

«SEG3601»

D. AmyotU. Ottawa

Gestion des exigences avec DOORS 5

Titre de colonne

Objet courant

Identificateur d’objet

“Aucun changement” (barre verte)

“Changé cette session”(non sauvegardé, barre rouge)

Numéro de section ou d’objet

“Changé” (sauvegardé, barre jaune)

Titre d’objet

Texte d’objet

Indicateur de lien (entrant et sortant)

Information affichée (v8.2 / v8.3)

Page 6: «SEG3601» D. Amyot U. Ottawa SEG 3601 Gestion des exigences avec DOORS Adapté de présentations par Telelogic et Amyot 2005-2012

«SEG3601»

D. AmyotU. Ottawa

Gestion des exigences avec DOORS 6

Objet titre ou objet texte ?

Organisation hiérarchique des objetsObjet Titre

• A une valeur dans Object Heading, mais pas dans Object Text

• Mise en place de contexte pour objets sous le titreObjet Texte

• A une valeur dans Object Text, mais pas dans Object Heading

• Les exigences sont entrés dans les objets textes• Devraient être des feuilles dans la hiérarchie de

modules

Pas plus d’une exigence dans un objet texte

Page 7: «SEG3601» D. Amyot U. Ottawa SEG 3601 Gestion des exigences avec DOORS Adapté de présentations par Telelogic et Amyot 2005-2012

«SEG3601»

D. AmyotU. Ottawa

Gestion des exigences avec DOORS 7

Raccourcis

Ctrl-N … insérer un objet au même niveau

Ctrl-L … insérer un objet sous le niveau courant

Ctrl-H … changer l’objet dans le mode entête

Ctrl-T … changer l’objet dans le mode texte

Ctrl-C … copier l’objet courant seulement (sans hiérarchie)

Ctrl-V … insérer après l’objet courant

Ctrl-X … coupe l’objet courant avec hiérarchie

Ctrl-Z …annuler

Page 8: «SEG3601» D. Amyot U. Ottawa SEG 3601 Gestion des exigences avec DOORS Adapté de présentations par Telelogic et Amyot 2005-2012

«SEG3601»

D. AmyotU. Ottawa

Gestion des exigences avec DOORS 8

Attributs pour Objets, Liens et Modules

Les attributs permettent d’associer de l’information additionnelle avec chaque exigence (objet), lien ou module.

Page 9: «SEG3601» D. Amyot U. Ottawa SEG 3601 Gestion des exigences avec DOORS Adapté de présentations par Telelogic et Amyot 2005-2012

«SEG3601»

D. AmyotU. Ottawa

Gestion des exigences avec DOORS 9

Exemples d’attributs pour les objets

Numéro absolu, créé par, date de dernière modification• Automatiquement géré par DOORS

Source• Qui a rédigé l’exigence?

Priorité• Quelle est la priorité de cette exigence?

Vérifiabilité, Sûreté, …• Est-ce que cette exigence est vérifiable ? De grande

importance pour la sécurité humaine ?Révision

• L’état de révision de l’exigenceRaison (justification)

Page 10: «SEG3601» D. Amyot U. Ottawa SEG 3601 Gestion des exigences avec DOORS Adapté de présentations par Telelogic et Amyot 2005-2012

«SEG3601»

D. AmyotU. Ottawa

Gestion des exigences avec DOORS 10

Le concept de lien

Une relation entre deux objets dans la base de données DOORS est établie en utilisant un lien

Objets origine et destination (source and target)

• Le de l’origine à la destination

Les liens peuvent être suivis dans les deux directions.

Page 11: «SEG3601» D. Amyot U. Ottawa SEG 3601 Gestion des exigences avec DOORS Adapté de présentations par Telelogic et Amyot 2005-2012

«SEG3601»

D. AmyotU. Ottawa

Gestion des exigences avec DOORS 11

Le concept de lien

Les liens sont stockés dans des modules de liens

• Le nom du module indique le type de lien

• Une partie de l’information est stocké avec l’origine (exemple: on ne peut effacer un objet qui possède des liens entrants)

Ensemble de liens (Linkset)

• Les liens sont regroupés en linkset.

• Un linkset contient tous les liens d’un type spécifique qui existent entre une paire de modules formels.

• Les modules de liens peuvent contenir plusieurs linksets.

Page 12: «SEG3601» D. Amyot U. Ottawa SEG 3601 Gestion des exigences avec DOORS Adapté de présentations par Telelogic et Amyot 2005-2012

«SEG3601»

D. AmyotU. Ottawa

Gestion des exigences avec DOORS 12

Schéma pour un projet simple

Combien y a-t-il de

• Modules formels ?

• Modules de liens ?

• Linksets?

Quels sont les noms

des modules de liens?

Exigencesclient

Exigences système

Spécification du design

Tests de satisfaction

Tests fonctionnels

Teste

Teste

Teste

Satisfait

Satisfait

Tests unitaires

Standards

Contraint par

Page 13: «SEG3601» D. Amyot U. Ottawa SEG 3601 Gestion des exigences avec DOORS Adapté de présentations par Telelogic et Amyot 2005-2012

«SEG3601»

D. AmyotU. Ottawa

Gestion des exigences avec DOORS 13

La direction des liens est importante

La direction des liens est déterminée principalement par le contrôle des accès

• L’utilisateur doit pouvoir écrire à l’origine (exemple: les standards ne peuvent pas être l’origine car le développeur n’a pas les permissions pour y écrire)

• L’utilisateur n’a besoin que des permissions pour la lecture de la destination

De plus, le choix est renforcé par le désir d’être constant pour utiliser les fonctionnalités offertes par DOORS pour les rapports.

• L’utilisation de liens du bas vers le haut (recommandé) ou du haut vers le bas de façon constante permet d’utiliser des outils de traçabilité à niveau multiples

Page 14: «SEG3601» D. Amyot U. Ottawa SEG 3601 Gestion des exigences avec DOORS Adapté de présentations par Telelogic et Amyot 2005-2012

«SEG3601»

D. AmyotU. Ottawa

Gestion des exigences avec DOORS 14

Appliquer un schéma en limitant les liens

Activer les options suivantes dans File - Module Properties – Linksets (pour tous les modules formels)

• Only allow outgoing links as specified in the above list• Mandatory

Sinon, DOORS créera un module de liens par défaut (DOORS Links)

• L’utilisation de ce module par défaut n’est pas recommandée

Exigences client

Exigences système

Tests de satisfaction

Satisfait

NONNON

Page 15: «SEG3601» D. Amyot U. Ottawa SEG 3601 Gestion des exigences avec DOORS Adapté de présentations par Telelogic et Amyot 2005-2012

«SEG3601»

D. AmyotU. Ottawa

Gestion des exigences avec DOORS 15

Exercice – Appliquer un schémaCréez trois modules formels: A, B, CCréez deux objets dans chaque module (A1, A2; B1, …)Dans le menu View:

• sélectionnez Show Link Modules et Show Deleted ItemsCréez un lien de A1 à B1 (utilisez le glisser-déposer (drag & drop))

• Quels modules de liens ont été créés ?• Quels linksets ont été créés ?

Créez un module de lien TestCréez un linkset obligatoire dans le module A (File – Module Properties – Linksets) pour les liens vers le module B en utilisant le module de liens TestCréez un lien de A2 à B2– qu’est-il arrivé ?

• Double-cliquez les modules de liens…Créez un lien de A1 à C1 – qu’est-il arrivé ?Activez l’option “Only allow outgoing links as specified in the above list” dans module A (File – Module Properties – Linksets)Créez un lien de A2 à C2 – qu’est-il arrivé ?

Page 16: «SEG3601» D. Amyot U. Ottawa SEG 3601 Gestion des exigences avec DOORS Adapté de présentations par Telelogic et Amyot 2005-2012

«SEG3601»

D. AmyotU. Ottawa

Gestion des exigences avec DOORS 16

Vue de traçabilité

1. 820.30(b) Design and Development Planning

Each manufacturer shall establish and maintain plans that describe or reference the design and developmentactivities and define responsibility for implementation.

The plans shall identify and describe the interfaces with different groups or activities that provide, or resultin, input to the design and development process.

The plans shall be reviewed as design and development evolves.The plans shall be updated as design and development evolves.The plans shall be approved as design and development evolves.

2. 820.30(c) Design Input2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a

device are appropriate and address the intended use of the device, including the needs of the userand patient.

2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to adevice are appropriate and address the intended use of the device, including the needs of the userand patient.

2.3. The procedures shall include a mechanism for addressing incomplete requirements.2.4. The procedures shall include a mechanism for addressing ambiguous requirements.2.5. The procedures shall include a mechanism for addressing conflicting requirements.2.6. The design input requirements shall be documented by a designated individual(s).2.7. The design input requirements shall be reviewed by a designated individual(s).2.8. The design input requirements shall be approved by a designated individual(s).2.9. The approval, including the date and signature of the individual(s) approving the requirements,

shall be documented.2.10. Questions.

2.10.1. Summarize the manufacturer's written procedure(s) for identification and control ofdesign input.

2.10.2. From what sources are design inputs sought?2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and

list additional aspects.)2.10.3.1. intended use2.10.3.2. user/patient/clinical2.10.3.3. performance characteristics2.10.3.4. safety2.10.3.5. limits and tolerances2.10.3.6. risk analysis2.10.3.7. toxicity and biocompatibility2.10.3.8. electromagnetic compatibility (EMC)2.10.3.9. compatibility with accessories/auxiliary devices2.10.3.10. compatibility with the environment of intended use2.10.3.11. human factors2.10.3.12. physical/chemical characteristics2.10.3.13. labeling/packaging2.10.3.14. reliability2.10.3.15. statutory and regulatory requirements2.10.3.16. voluntary standards2.10.3.17. manufacturing processes2.10.3.18. sterility2.10.3.19. MDRs/complaints/failures and other historical data2.10.3.20. design history files (DHFs)

2.10.4. For the specific design covered, how were the design input requirements identified?2.10.5. For the specific design covered, how were the design input requirements reviewed for

adequacy?

Comply with FDA Design Control Guidance GMP Regulation

1. Capture design and related information1.1. Input electronically formatted data1.2. Reference external information sources1.3. Reference external documentation

2. Store design and related information2.1. Identify and tag design information as unique “design elements”2.2. Organize design elements

2.2.1. Organize by Design Control Guidance Element2.2.2. Organize by inter-relationships

2.3. Ensure all design elements are available2.3.1. Store design elements by Design Control Guidance Element2.3.2. Store design elements and their historical values

3. Manage all user needs3.1. Identify the source of the user need3.2. Identify all user types (groups)3.3. Identify the customer (s)3.4. Profile the expected patients3.5. State the intended use of the product (family)3.6. Capture the acceptance criteria for each user need

4. Manage design input requirements4.1. Identify the source of the requirement4.2. Identify the associated user need4.3. Capture requirement description and attributes4.4. Capture acceptance criteria4.5. Assign responsibility for each requirement4.6. Manage incomplete requirements4.7. Manage ambiguous requirements4.8. Manage conflicting requirements4.9. Approve all requirements

5. Manage acceptance5.1. Ensure the acceptance of every user need5.2. Ensure the acceptance of every design input requirement5.3. Document the results of every user need acceptance test5.4. Document the results of every design input requirements test5.5. Make acceptance results available

6. Manage change6.1. Maintain history of design element changes

6.1.1. Make complete change history available6.1.2. Maintain history within and across any organizational procedure6.1.3. Maintain history within and across any project milestone6.1.4. Maintain history within and across any Design Control Guidance Elements

6.2. Capture frequency and nature of element changes6.2.1. Provide rationale for change6.2.2. Describe decisions made6.2.3. Identify approval authority for the change6.2.4. Capture date, time, and signature of approving authority

6.3. Identify impacted elements due to a change in another element6.3.1. Create backward traces to design elements within and across any organizational procedure6.3.2. Create backward traces to design elements within and across any project milestone

1.1. Identify impacted elements due to a change in another element Traceability Reports: consistency with driving design elements Impact Reports: other design elements affected Links to impacted design elements1.1.1. Create backward traces to design elements within and across any organizational

procedure Traceability Reports: Procedure Attribute

1.1.2. Create backward traces to design elements within and across any project milestone Traceability Reports: Milestone Attribute

1.1.3. Create backward traces to design elements within and across Design ControlGuidance Elements Traceability Reports: Linked design elements

1.1.4. Create forward impacts to design elements within and across any organizationalprocedure Impact Reports: Procedure Attribute

1.1.5. Create forward impacts to design elements within and across any project milestone Impact Reports: Milestone Attribute

1.1.6. Create forward impacts to design elements within and across Design ControlGuidance Elements Impact Reports: Linked design elements

1.2. Associate changed design elements with related elements Link Change Design Object with affected design element(s) Traceability Links and Reports from affected design element(s) Impact Links and Reports from affected design element(s)1.2.1. Associate design element changes with decisions, rationale, and approval authority

information Change Decision Objects with following Attributes: Disposition Attribute Decision Attribute Rationale Attribute Owner Attribute Management Approval Attribute

1.2.2. Provide associations within and across any organizational procedure Change Design Object Traceability Link on Procedure Attribute Change Design Object Impacts Link on Procedure Attribute

1.2.3. Provide associations within and across any project milestone Change Design Object Traceability Link on Milestone Attribute Change Design Object Impacts Link on Milestone Attribute

1.2.4. Provide associations within and across Design Control Guidance Elements Change Design Object Traceability Link to traced design elements Change Design Object Impacts Link to linked design elements

1.3. Mange the change process Design Change Module Design Change Reports Object History Object History Reports Versions Baselines

1. 820.30(b) Design and Development Planning

Each manufacturer shall establish and maintain plans that describe or reference the design and developmentactivities and define responsibility for implementation.

The plans shall identify and describe the interfaces with different groups or activities that provide, or resultin, input to the design and development process.

The plans shall be reviewed as design and development evolves.The plans shall be updated as design and development evolves.The plans shall be approved as design and development evolves.

2. 820.30(c) Design Input2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a

device are appropriate and address the intended use of the device, including the needs of the userand patient.

2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to adevice are appropriate and address the intended use of the device, including the needs of the userand patient.

2.3. The procedures shall include a mechanism for addressing incomplete requirements.2.4. The procedures shall include a mechanism for addressing ambiguous requirements.2.5. The procedures shall include a mechanism for addressing conflicting requirements.2.6. The design input requirements shall be documented by a designated individual(s).2.7. The design input requirements shall be reviewed by a designated individual(s).2.8. The design input requirements shall be approved by a designated individual(s).2.9. The approval, including the date and signature of the individual(s) approving the requirements,

shall be documented.2.10. Questions.

2.10.1. Summarize the manufacturer's written procedure(s) for identification and control ofdesign input.

2.10.2. From what sources are design inputs sought?2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and

list additional aspects.)2.10.3.1. intended use2.10.3.2. user/patient/clinical2.10.3.3. performance characteristics2.10.3.4. safety2.10.3.5. limits and tolerances2.10.3.6. risk analysis2.10.3.7. toxicity and biocompatibility2.10.3.8. electromagnetic compatibility (EMC)2.10.3.9. compatibility with accessories/auxiliary devices2.10.3.10. compatibility with the environment of intended use2.10.3.11. human factors2.10.3.12. physical/chemical characteristics2.10.3.13. labeling/packaging2.10.3.14. reliability2.10.3.15. statutory and regulatory requirements2.10.3.16. voluntary standards2.10.3.17. manufacturing processes2.10.3.18. sterility2.10.3.19. MDRs/complaints/failures and other historical data2.10.3.20. design history files (DHFs)

2.10.4. For the specific design covered, how were the design input requirements identified?2.10.5. For the specific design covered, how were the design input requirements reviewed for

adequacy?

Comply with FDA Design Control Guidance GMP Regulation

1. Capture design and related information1.1. Input electronically formatted data1.2. Reference external information sources1.3. Reference external documentation

2. Store design and related information2.1. Identify and tag design information as unique “design elements”2.2. Organize design elements

2.2.1. Organize by Design Control Guidance Element2.2.2. Organize by inter-relationships

2.3. Ensure all design elements are available2.3.1. Store design elements by Design Control Guidance Element2.3.2. Store design elements and their historical values

3. Manage all user needs3.1. Identify the source of the user need3.2. Identify all user types (groups)3.3. Identify the customer (s)3.4. Profile the expected patients3.5. State the intended use of the product (family)3.6. Capture the acceptance criteria for each user need

4. Manage design input requirements4.1. Identify the source of the requirement4.2. Identify the associated user need4.3. Capture requirement description and attributes4.4. Capture acceptance criteria4.5. Assign responsibility for each requirement4.6. Manage incomplete requirements4.7. Manage ambiguous requirements4.8. Manage conflicting requirements4.9. Approve all requirements

5. Manage acceptance5.1. Ensure the acceptance of every user need5.2. Ensure the acceptance of every design input requirement5.3. Document the results of every user need acceptance test5.4. Document the results of every design input requirements test5.5. Make acceptance results available

6. Manage change6.1. Maintain history of design element changes

6.1.1. Make complete change history available6.1.2. Maintain history within and across any organizational procedure6.1.3. Maintain history within and across any project milestone6.1.4. Maintain history within and across any Design Control Guidance Elements

6.2. Capture frequency and nature of element changes6.2.1. Provide rationale for change6.2.2. Describe decisions made6.2.3. Identify approval authority for the change6.2.4. Capture date, time, and signature of approving authority

6.3. Identify impacted elements due to a change in another element6.3.1. Create backward traces to design elements within and across any organizational procedure6.3.2. Create backward traces to design elements within and across any project milestone

1.1. Identify impacted elements due to a change in another element Traceability Reports: consistency with driving design elements Impact Reports: other design elements affected Links to impacted design elements1.1.1. Create backward traces to design elements within and across any organizational

procedure Traceability Reports: Procedure Attribute

1.1.2. Create backward traces to design elements within and across any project milestone Traceability Reports: Milestone Attribute

1.1.3. Create backward traces to design elements within and across Design ControlGuidance Elements Traceability Reports: Linked design elements

1.1.4. Create forward impacts to design elements within and across any organizationalprocedure Impact Reports: Procedure Attribute

1.1.5. Create forward impacts to design elements within and across any project milestone Impact Reports: Milestone Attribute

1.1.6. Create forward impacts to design elements within and across Design ControlGuidance Elements Impact Reports: Linked design elements

1.2. Associate changed design elements with related elements Link Change Design Object with affected design element(s) Traceability Links and Reports from affected design element(s) Impact Links and Reports from affected design element(s)1.2.1. Associate design element changes with decisions, rationale, and approval authority

information Change Decision Objects with following Attributes: Disposition Attribute Decision Attribute Rationale Attribute Owner Attribute Management Approval Attribute

1.2.2. Provide associations within and across any organizational procedure Change Design Object Traceability Link on Procedure Attribute Change Design Object Impacts Link on Procedure Attribute

1.2.3. Provide associations within and across any project milestone Change Design Object Traceability Link on Milestone Attribute Change Design Object Impacts Link on Milestone Attribute

1.2.4. Provide associations within and across Design Control Guidance Elements Change Design Object Traceability Link to traced design elements Change Design Object Impacts Link to linked design elements

1.3. Mange the change process Design Change Module Design Change Reports Object History Object History Reports Versions Baselines

Ex. Client Ex. Techniques Cas de testsDesign

Page 17: «SEG3601» D. Amyot U. Ottawa SEG 3601 Gestion des exigences avec DOORS Adapté de présentations par Telelogic et Amyot 2005-2012

«SEG3601»

D. AmyotU. Ottawa

Gestion des exigences avec DOORS 17

Analyse des liens

Analyse de traçabilité

• Suit les liens entrants (du haut niveau au bas niveau si les liens sont du bas vers le haut)

Analyse de l’impact

• Suit les liens sortants (du bas niveau au haut niveau si les liens sont du bas vers le haut)

Analysis Wizard

Liens suspects

• Indicateur de liens suspects

• Nettoyer des liens suspects

Page 18: «SEG3601» D. Amyot U. Ottawa SEG 3601 Gestion des exigences avec DOORS Adapté de présentations par Telelogic et Amyot 2005-2012

«SEG3601»

D. AmyotU. Ottawa

Gestion des exigences avec DOORS 18

Exercice – Analyse des liens

Utilisez l’analyse de traçabilité pour “S333” dans les standards (profondeur de 3).

• Y a-t-il des tests unitaires?

Analysez l’impact pour“Second Unit Test” (profondeur de 3).

• Quels exigences client sont

affectées?

Utilisez le Analysis Wizard pour

trouver quelles exigences client

n’ont pas de tests

unitaires.

Exigences client

Exigences système

Spécificationdesign

Tests de satisfaction

Tests fonctionnels

Teste

Teste

Teste

Satisfait

Satisfait

Tests unitaires

StandardsContraint par

Page 19: «SEG3601» D. Amyot U. Ottawa SEG 3601 Gestion des exigences avec DOORS Adapté de présentations par Telelogic et Amyot 2005-2012

«SEG3601»

D. AmyotU. Ottawa

Gestion des exigences avec DOORS 19

Exercice – Liens suspects

Changez le “Third Design Specification”

• Où croyez-vous que les liens

suspects apparaîtront?

Nettoyez les liens suspects

Exigences client

Exigences système

Spécificationdesign

Tests de satisfaction

Tests fonctionnels

Teste

Teste

Teste

Satisfait

Satisfait

Tests unitaires

StandardsContraint par

Page 20: «SEG3601» D. Amyot U. Ottawa SEG 3601 Gestion des exigences avec DOORS Adapté de présentations par Telelogic et Amyot 2005-2012

«SEG3601»

D. AmyotU. Ottawa

Gestion des exigences avec DOORS 20

Filtrer, Trier, Vues, Rapports

Filtrer des objets• Par rapport à leurs attributs, leurs liens, leur position

dans la hiérarchie (feuille ou non) et leurs colonnes. Trier les objets

• Par rapport à la valeur de leurs attributsVues

• Définit la mise en page (colonnes, filtres, tris, …)• Spécifiques aux modules (sauvegardés dans ceux-ci)

Rapports• Combine une vue avec un format de page pour

l’impression• Report Wizard

Page 21: «SEG3601» D. Amyot U. Ottawa SEG 3601 Gestion des exigences avec DOORS Adapté de présentations par Telelogic et Amyot 2005-2012

«SEG3601»

D. AmyotU. Ottawa

Gestion des exigences avec DOORS 21

Exercices – Filtrer, trier et vues

• Filtrez “Design Specifications” pour que les titres soient cachés

• Désactivez le filtre

• Filtrez “Design Specifications” pour trouver les objets qui n’ont pas de liens vers “Unit Tests”

• Triez par priorité

• Sauvegardez la vue “Ma vue”

• Activez la vue standard

• Activez “Ma Vue”

Page 22: «SEG3601» D. Amyot U. Ottawa SEG 3601 Gestion des exigences avec DOORS Adapté de présentations par Telelogic et Amyot 2005-2012

«SEG3601»

D. AmyotU. Ottawa

Gestion des exigences avec DOORS 22

DOORS/Analyst: Intégration avec UML 2.x

Ajoutez des diagrammes UML 2.x et leurs éléments en tant qu’objets liables grâce au plug-in Analyst (Éditeur UML 2.x Tau G2)

Page 23: «SEG3601» D. Amyot U. Ottawa SEG 3601 Gestion des exigences avec DOORS Adapté de présentations par Telelogic et Amyot 2005-2012

«SEG3601»

D. AmyotU. Ottawa

DOORS/Analyst

Si DOORS/Analyst est installé, vous pouvez:

• Explorer le menu Analyst dans DOORS

• Créer un module et sélectionner Analyst --> Enable Analyst

• Vous devriez alors avoir la permission d’insérer des diagrammes UML via le menu Analyst

Gestion des exigences avec DOORS 23

Page 24: «SEG3601» D. Amyot U. Ottawa SEG 3601 Gestion des exigences avec DOORS Adapté de présentations par Telelogic et Amyot 2005-2012

«SEG3601»

D. AmyotU. Ottawa

Gestion des exigences avec DOORS 24

DOORStoURN: Intégration avec URN

Ajoutez des diagrammes URN et leurs éléments en tant qu’objets liables grâce à la fonction DXL export dans jUCMNav.

Page 25: «SEG3601» D. Amyot U. Ottawa SEG 3601 Gestion des exigences avec DOORS Adapté de présentations par Telelogic et Amyot 2005-2012

«SEG3601»

D. AmyotU. Ottawa

Intégration jUCMNav-URN

Voir la documentation et les démos sur Twiki:

• http://jucmnav.softwareengineering.ca/twiki/bin/view/ProjetSEG/DoorsExport

Il faut installer une librairie DOORS supplémentaire pour importer des modèles URN:

• http://jucmnav.softwareengineering.ca/ucm/bin/view/ProjetSEG/InstallingTheDXLLibrary

Gestion des exigences avec DOORS 25

Page 26: «SEG3601» D. Amyot U. Ottawa SEG 3601 Gestion des exigences avec DOORS Adapté de présentations par Telelogic et Amyot 2005-2012

«SEG3601»

D. AmyotU. Ottawa

Pour votre projet…

Vous pouvez plus simplement:

• Exporter vos diagrammes (de jUCMNav ou autres)

• Les inclure dans un nouveau module DOORS.

• Énumérer manuellement les élements importants (buts, scénarios, etc.) inclus dans ces diagrammes.

• Créer vos liens de traçabilité entre vos exigences et ces éléments.

Gestion des exigences avec DOORS 26

Page 27: «SEG3601» D. Amyot U. Ottawa SEG 3601 Gestion des exigences avec DOORS Adapté de présentations par Telelogic et Amyot 2005-2012

«SEG3601»

D. AmyotU. Ottawa

Voir aussi

Seilevel’s Evaluations of Requirements Management Tools: Summaries and Scores •http://www.seilevel.com/wp-content/uploads/RequirementsManagementToolWP_2.pdf

•DOORS au milieu de peloton, selon leurs critères et besoins

•On peut tout faire, c’est un outil populaire et robuste, mais l’utilisabilité est faible, surtout en ce qui a trait à la modélisation.

Gestion des exigences avec DOORS 27