SEG 3601 Gestion des exigences avec DOORScserg0.site.uottawa.ca/.../DOORSintro-fr.pdf ·...

SEG 3601

Gestion des exigences avec DOORS

Adapté de présentations par Telelogic et

Amyot 2005-2012

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


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 requise

Gestion des changements

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


Base de données DOORS (v8.x)

Répertoire

supprimé

Modules de liens (Link modules)

Répertoires (Folders)

Projets Modules formels (Formal Modules)


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)


Objet titre ou objet texte ?

Organisation hiérarchique des objets

Objet Titre

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

• Mise en place de contexte pour objets sous le titre

Objet 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


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


Attributs pour Objets, Liens et Modules

Les attributs permettent d’associer de l’information additionnelle

avec chaque exigence (objet), lien ou module.


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’exigence

Raison (justification)


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.


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.


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?

Exigences

client

Exigences

système

Spécification

du design

Tests de

satisfaction

Tests

fonctionnels

Teste

Teste

Teste

Satisfait

Satisfait

Tests

unitaires

Standards

Contraint par


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


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

NON NON


Exercice – Appliquer un schéma Créez trois modules formels: A, B, C

Créez deux objets dans chaque module (A1, A2; B1, …)

Dans le menu View:

• sélectionnez Show Link Modules et Show Deleted Items

Cré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 Test

Cré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 Test

Cré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é ?


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 development

activities and define responsibility for implementation.

The plans shall identify and describe the interfaces with different groups or activities that provide, or result

in, 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 Input

2.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 user

and patient.

2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to a


and 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 of

design 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 use

2.10.3.2. user/patient/clinical

2.10.3.3. performance characteristics

2.10.3.4. safety

2.10.3.5. limits and tolerances

2.10.3.6. risk analysis

2.10.3.7. toxicity and biocompatibility

2.10.3.8. electromagnetic compatibility (EMC)

2.10.3.9. compatibility with accessories/auxiliary devices

2.10.3.10. compatibility with the environment of intended use

2.10.3.11. human factors

2.10.3.12. physical/chemical characteristics

2.10.3.13. labeling/packaging

2.10.3.14. reliability

2.10.3.15. statutory and regulatory requirements

2.10.3.16. voluntary standards

2.10.3.17. manufacturing processes

2.10.3.18. sterility

2.10.3.19. MDRs/complaints/failures and other historical data

2.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 information

1.1. Input electronically formatted data

1.2. Reference external information sources

1.3. Reference external documentation

2. Store design and related information

2.1. Identify and tag design information as unique “design elements”

2.2. Organize design elements

2.2.1. Organize by Design Control Guidance Element

2.2.2. Organize by inter-relationships

2.3. Ensure all design elements are available

2.3.1. Store design elements by Design Control Guidance Element

2.3.2. Store design elements and their historical values

3. Manage all user needs

3.1. Identify the source of the user need

3.2. Identify all user types (groups)

3.3. Identify the customer (s)

3.4. Profile the expected patients

3.5. State the intended use of the product (family)

3.6. Capture the acceptance criteria for each user need

4. Manage design input requirements

4.1. Identify the source of the requirement

4.2. Identify the associated user need

4.3. Capture requirement description and attributes

4.4. Capture acceptance criteria

4.5. Assign responsibility for each requirement

4.6. Manage incomplete requirements

4.7. Manage ambiguous requirements

4.8. Manage conflicting requirements

4.9. Approve all requirements

5. Manage acceptance

5.1. Ensure the acceptance of every user need

5.2. Ensure the acceptance of every design input requirement

5.3. Document the results of every user need acceptance test

5.4. Document the results of every design input requirements test

5.5. Make acceptance results available

6. Manage change

6.1. Maintain history of design element changes

6.1.1. Make complete change history available

6.1.2. Maintain history within and across any organizational procedure

6.1.3. Maintain history within and across any project milestone

6.1.4. Maintain history within and across any Design Control Guidance Elements

6.2. Capture frequency and nature of element changes

6.2.1. Provide rationale for change

6.2.2. Describe decisions made

6.2.3. Identify approval authority for the change

6.2.4. Capture date, time, and signature of approving authority

6.3. Identify impacted elements due to a change in another element

6.3.1. Create backward traces to design elements within and across any organizational procedure

6.3.2. Create backward traces to design elements within and across any project milestone


Traceability Reports: consistency with driving design elements

Impact Reports: other design elements affected

Links to impacted design elements

1.1.1. Create backward traces to design elements within and across any organizational

procedure

Traceability Reports: Procedure Attribute


Traceability Reports: Milestone Attribute

1.1.3. Create backward traces to design elements within and across Design Control

Guidance Elements

Traceability Reports: Linked design elements

1.1.4. Create forward impacts to design elements within and across any organizational

procedure

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 Control

Guidance 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 development

activities and define responsibility for implementation.

The plans shall identify and describe the interfaces with different groups or activities that provide, or result

in, 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 Input

2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a


and patient.

2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to a


and 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 of

design 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 use

2.10.3.2. user/patient/clinical

2.10.3.3. performance characteristics

2.10.3.4. safety

2.10.3.5. limits and tolerances

2.10.3.6. risk analysis

2.10.3.7. toxicity and biocompatibility

2.10.3.8. electromagnetic compatibility (EMC)

2.10.3.9. compatibility with accessories/auxiliary devices

2.10.3.10. compatibility with the environment of intended use

2.10.3.11. human factors

2.10.3.12. physical/chemical characteristics

2.10.3.13. labeling/packaging

2.10.3.14. reliability

2.10.3.15. statutory and regulatory requirements

2.10.3.16. voluntary standards

2.10.3.17. manufacturing processes

2.10.3.18. sterility

2.10.3.19. MDRs/complaints/failures and other historical data

2.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 information

1.1. Input electronically formatted data

1.2. Reference external information sources

1.3. Reference external documentation

2. Store design and related information

2.1. Identify and tag design information as unique “design elements”

2.2. Organize design elements

2.2.1. Organize by Design Control Guidance Element

2.2.2. Organize by inter-relationships

2.3. Ensure all design elements are available

2.3.1. Store design elements by Design Control Guidance Element

2.3.2. Store design elements and their historical values

3. Manage all user needs

3.1. Identify the source of the user need

3.2. Identify all user types (groups)

3.3. Identify the customer (s)

3.4. Profile the expected patients

3.5. State the intended use of the product (family)

3.6. Capture the acceptance criteria for each user need

4. Manage design input requirements

4.1. Identify the source of the requirement

4.2. Identify the associated user need

4.3. Capture requirement description and attributes

4.4. Capture acceptance criteria

4.5. Assign responsibility for each requirement

4.6. Manage incomplete requirements

4.7. Manage ambiguous requirements

4.8. Manage conflicting requirements

4.9. Approve all requirements

5. Manage acceptance

5.1. Ensure the acceptance of every user need

5.2. Ensure the acceptance of every design input requirement

5.3. Document the results of every user need acceptance test

5.4. Document the results of every design input requirements test

5.5. Make acceptance results available

6. Manage change

6.1. Maintain history of design element changes

6.1.1. Make complete change history available

6.1.2. Maintain history within and across any organizational procedure

6.1.3. Maintain history within and across any project milestone

6.1.4. Maintain history within and across any Design Control Guidance Elements

6.2. Capture frequency and nature of element changes

6.2.1. Provide rationale for change

6.2.2. Describe decisions made

6.2.3. Identify approval authority for the change

6.2.4. Capture date, time, and signature of approving authority


6.3.1. Create backward traces to design elements within and across any organizational procedure



Traceability Reports: consistency with driving design elements

Impact Reports: other design elements affected

Links to impacted design elements

1.1.1. Create backward traces to design elements within and across any organizational

procedure

Traceability Reports: Procedure Attribute


Traceability Reports: Milestone Attribute

1.1.3. Create backward traces to design elements within and across Design Control

Guidance Elements

Traceability Reports: Linked design elements

1.1.4. Create forward impacts to design elements within and across any organizational

procedure

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 Control

Guidance 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 tests Design


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


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écification

design

Tests de

satisfaction

Tests

fonctionnels

Teste

Teste

Teste

Satisfait

Satisfait

Tests

unitaires

Standards Contraint par


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écification

design

Tests de

satisfaction

Tests

fonctionnels

Teste

Teste

Teste

Satisfait

Satisfait

Tests

unitaires

Standards Contraint par


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 attributs

Vues

• 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


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”


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)

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



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.

Intégration jUCMNav-URN

Voir la documentation et les démos sur Twiki:

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

oorsExport

Il faut installer une librairie DOORS supplémentaire pour

importer des modèles URN:

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

tallingTheDXLLibrary


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

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

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

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

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.


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.


http://www.seilevel.com/wp-content/uploads/RequirementsManagementToolWP_2.pdf



SEG 3601 Gestion des exigences avec DOORScserg0.site.uottawa.ca/.../DOORSintro-fr.pdf ·...

Documents

Transcript of SEG 3601 Gestion des exigences avec DOORScserg0.site.uottawa.ca/.../DOORSintro-fr.pdf ·...