® IBM Software Group © 2009 IBM Corporation La gestion des exigences : Levier de ma î trise de la...

®

IBM Software Group

© 2009 IBM Corporation

La gestion des exigences :

Levier de maîtrise de la qualité et de la conformité réglementaire dans les industries régulées

Dominique HOUDIERCOMPLIANCE Technologies (http://www.compliance-technologies.com)

IBM Software Group | Rational software

2

COMPLIANCE Technologies

Création :

Siège Social :

Activité :

Références :

Partenaire :

2004

Région Lyonnaise

Conseil & Formation en Gestion des Exigences

Air Liquide, Bombardier Transport, Cnim, Iter, Mutualité Socialiste, Otan, Pgp, Schneider Electric, Sncf, Thales, Total…

IBM Rational


3

Enjeux de la Gestion des Exigences


4

Gestion des exigences : le constat

Clear business objectives

17%

User involvement

7%

Minimized scope

12%

Agile requirements process

Executive support

14%15%

14%

6%5% 5%

5%

Experienced Project Manager

Standard infrastructure

Reliable EstimatesFormal

methodology

Skilled Staff

Source: “Chaos Chronicles, III, 2003”. www.standishgroup.com

Approximately 60%-70% of IT project failures result from poor requirements gathering, analysis, and management.

- Meta Group, March 2003

“If you do a post-mortem evaluation on unsuccessful software projects, you'll find that most of them failed because the person responsible didn't properly manage the project's requirements and expectations.”

- Andy Feibus


5


42%

37%

27%

26%

24%

24%

0% 10% 20% 30% 40% 50%

Unclear or continually changing productdefinitions

Product does not meet customer or marketrequirements

Unrealistic schedule expectations

Projects not adequately staffed

Unclear or continually changing priorities

Unrealistic financial expectations

Source: AberdeenGroup, August 2006

Pourquoi les projets échouent-ils?


6


Les exigences ne sont pas toujours formulées de manière appropriée

Les exigences ne sont pas toujours bien comprises par toutes les parties-prenantes

Le problème et la solution ne sont pas systématiquement dissociés

Le produit/système ne répond pas systématiquement à toutes les exigences client

La validation ne couvre pas toutes les exigences

L’impact des modifications d’exigences client n’est pas complètement évalué sur la conception ou les tests


7

Attention, un système simple…


8

… peut cacher des dizaines d’exigencesThe swing shall be able to support a weight of 100lbs

The swing should be large enough to carry 2 small children

The swing shall never be lower than 0.5 meters from the ground

The swing shall be not be able to swing through more than 180 degrees

The swing rope shall have an elasticity of…….

The swing shall comply with the following safety standards………..

The swing shall……

The swing shall……


9

Exigences et Qualité

Qualité : conformité aux exigences = satisfaction client

Gestion des exigences : garantir la qualité de chaque niveau de définition tout au long du cycle de développement


10

Les exigences sont capitales

Les exigences représentent une expression claire des objectifs.

Les exigences définissent le problème à résoudre et les besoins à satisfaire

Les exigences identifient les caractéristiques des solutions acceptables

Les exigences contiennent les clés pour sélectionnerles solutions les plus appropriées

Les exigences permettent de se concentrer sur les objectifs les plus importants

Les exigences permettent de garder le capsur l’objectif à atteindre


11

Les exigences dans le cycle de vie

Les exigences sont un point d’entrée pour les activités de gestion de projet : Estimation et planification

Gestion des risques

Gestion de la sous-traitance

Analyse des solutions alternatives

Maîtrise des évolutions

Vérification / Validation / Qualification

Maintenance


12

Les bénéfices de la gestion d’exigences

Communication : les parties prenantes ont une idée cohérente du produit

Satisfaction : tous les besoins clients sont satisfaits

Complétude : on a pas de mauvaises surprises

Visibilité : le management a une vue d’ensemble fiable pour mieux piloter

Testabilité : les tests sont réalisés en regard des exigences

Traçabilité : l’historique de la déclinaison des exigences est conservé

Maîtrise des évolutions : l’impact d’une évolution peut être évalué

Qualité : le niveau de conformité est connu dans toutes les phases

Optimisation : on réalise uniquement ce qui est demandé

Integration : les composants fonctionnent ensemble


13

Vérification de la Conformité par la Traçabilité


14

Problème

SolutionSpécifique

SolutionAbstraite

L’utilisateur doit être capable de …

Le système doit …

Conception

Ce que l’utilisateur veut

Comment le systèmeest conçu

Modifier le designn’impacte pasles exigencessystème

Ce que le systèmedoit faire

“Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity.”Général Patton

Problème et Solution


15

Problème et Solution

Mauvaise compréhension du problème

Produit inadapté aux besoins client

Domination du concepteur par rapport à l’utilisateur

Validation et acceptation du produit difficile

Besoins utilisateur et fonctions système mal discernés


16

Trois Questions Clés

1. Pourquoi ? Quel est le but ?• Permet de cerner précisément le problème par rapport à la solution (Pourquoi les

pommes tombent-elles des arbres?)

2. Quelles sont les solutions envisageables ?• Permet d’identifier si une exigence a été exprimée en terme de solution

• Permet de comprendre pourquoi une solution particulière est choisie

• Permet d’exprimer une exigence de manière abstraite

3. Comment vérifier que l’exigence est satisfaite ?• Permet de rendre l’exigence testable


17

Traçabilité des exigences

Compréhension de la façon dont une exigence de haut-niveau est déclinée en exigences de plus bas niveau

Ou comment les besoins sont satisfaits et qualifiés :

Impact

Couverture

Complétude

Pertinence


18

ExigencesSystème

ExigencesSous-système

ExigencesComposant

Tests deValidation

Tests deVérification

Tests deVérification

Tests de Qualification

Qualification système

Validation système

Vérification des sous-systèmes

Vérification des composants

ExigencesUtilisateur

Expression des besoins

Mise en service

Cycle en V : Exigences à tous les niveaux


19

Analyse d’impactExigences

ClientExigencesSystème

Validation

satisfait satisfait

Qualification

vérifie

Vérifie

Vérifie

Architecture

Vérification

Standards

Et si o

n Change … ?

conforme à


20

ExigencesSystème

Analyse de couverture

ExigencesClient

Validation

satisfait satisfait

Qualification

vérifie

vérifie

vérifie

Architecture

Vérification

Standards

% Complétude … ?

conforme à


21

Pourquoi … ?

Analyse de traçabilité

ExigencesClient

ExigencesSystème

Validation

satisfait satisfait

Qualification

vérifie

vérifie

vérifie

Architecture

Vérification

Standards

Conforme à


22

Analyse de pertinence

ExigencesClient

ExigencesSystème

Validation

satisfait satisfait

Qualification

vérifie

vérifie

vérifie

Architecture

Vérification

Standards

“Contribution ?”

conforme à?

?


23

La traçabilité avec IBM® Rational® DOORS®

Données

Projet

DonnéesProjetStructurées, organisées et tracées

Design

Tables

Word CDC

FeaturesList

Plan de test

Standards Access

Specs Word

Visio

RapportValidation Excel

Functionality Cas de tests

Résultatde Test

BesoinsUtilisateur

Exigences

client

Exigences

Système

Tests de validation

Test de vérification

Tests de qualification

Génération de :

•Matrices de traçabilité

•Rapport de conformité

•Analyse d’impact


24

Rational DOORSGestion et Traçabilité des Exigences


25

Rational DOORS : Gestion de documents d’exigences

Hiérarchies de projets et de dossiers

Dossier supprimé

Documents Rational DOORS

Dossier

Projet


26

Rational DOORS : Import / Export d’informations

Rational Rational DOORSDOORS

ASCII

Spreadsheet

MS-Project

Tool Integrations*

FrameMaker

HTML

PowerPoint

Word

Outlook

ExcelMicrosoft

MS-WordRTF

OLE

ASCII

Spreadsheet

MS-Project

Tool Integrations*

FrameMaker

MS-Word

RTFMS-Word

Print

Direct Entry


27

Rational DOORS : Import depuis Microsoft Word

Initi

alem

ent W

ord

Création d’un document dans Rational DOORS


28

Rational DOORS : Une vue


29

Rational DOORS : Export vers Microsoft Word

DocumentTable Book


30

Rational DOORS : Historique et Baseline

Version Courante

BaselinePrécédente

Historique des modifications


31

Rational DOORS : Créer simplement votre traçabilité

Glisser-Déposer pour créer un lien dans un document . . .

. . . ou de document à

document


32

Rational DOORS : Rapport 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

ExigencesUtilisateur

ExigencesSystème

TestsConception


33

Rational DOORS : Vérification de la “complétude”

Détection des “Orphelins”& rapports de traçabilité montrent les liens “absents”

La création et l’effacement de liens sont enregistrés dans l’historique.


34

Rational DOORS : Liens suspects

Les mises à jour non effectuées sont détectées

Levée de la suspicion

par clique-droit


35

Rational DOORS : Accès web pour les revues et les discussions


36

Démonstration


37

Solutions Rational DOORS : Ingénierie Système et Logiciel

Gestion de la conformité des systèmes aux cahiers des charges

Justification des choix techniques

Gestion de la sous-traitance

Validation & qualification des systèmes

Suivi d’avancement technique

Capitalisation et Gestion des lignes de produits

SRD

Reports

Matrix Refers to

Is justified by Requirements

Analysis IDModule

User Requirements

URModule

System Requirements

SRModule

satisfies

Requirements Analysis

S y s t e m s a n d S o f t w a r e D e p a r t m e n t / S . E . C E TI n f o r m a t i o n i n c l u d e d i n t h i s d o c u m e n t i s t h e p r o p e r t y o f T h o m s o n - C S F g r o u p . I t m u s t n o t b e d i s c l o s e d w i t h o u t t h e p r i o r w r i t t e n c o n s e n t o f T h o m s o n - C S F T e c h n o l o g i e s & M e t h o d s M o d e l t t m c o v 3 . 2 . . 0

A T G S - G 2

V e r i f i c a t i o nP r o c e d u r e s

V e r i f i c a t i o nV e r i f i c a t i o nP r o c e d u r e sP r o c e d u r e s

I V V

S y s t e mR e q u i r e m e n t s

S y s t e mS y s t e mR e q u i r e m e n t sR e q u i r e m e n t s

S R

S u b - S y s t e mR e q u i r e m e n t s

S u bS u b -- S y s t e mS y s t e mR e q u i r e m e n t sR e q u i r e m e n t s

S R

s a t i s fi e s

sa

tis

fie

s

U s e rR e q u i r e m e n t s

U s e rU s e rR e q u i r e m e n t sR e q u i r e m e n t s

U R

P r o d u c t B r e a k d o w n

S t r u c t u r e

P r o d u c t P r o d u c t B r e a k d o w nB r e a k d o w n

S t r u c t u r eS t r u c t u r eP B S

I n t e g r a t i o nP r o c e d u r e s

I n t e g r a t i o nI n t e g r a t i o nP r o c e d u r e sP r o c e d u r e s

I V V

v e r i fi e s v e r i fi e s

s a t i s fi e sP r i m e I t e m

R e q u i r e m e n t s

P r i m e I t e mP r i m e I t e mR e q u i r e m e n t sR e q u i r e m e n t s

S R

I s a l l o c a t e d b y

V a l i d a t i o n &I n s t a l l a t i o n

P r o c e d u r e s

V a l i d a t i o n &V a l i d a t i o n &I n s t a l l a t i o nI n s t a l l a t i o n

P r o c e d u r e sP r o c e d u r e sI V V

v e r i fi e s


38

Solutions Rational DOORS : Pilotage de projets Gestion des risques

Collecte, Analyse et consolidation des risques

Liens entre les risques et les processus

Liens entre les risques et les actions

Tableau de bord de synthèse des risques

Plan Directeur de Validation

Liens entre les tests et les exigences

Liens entre les rapports de tests et les plans

Tableau de bord d’avancement des tests

® IBM Software Group © 2009 IBM Corporation La gestion des exigences : Levier de ma î trise de la...

Documents

Transcript of ® IBM Software Group © 2009 IBM Corporation La gestion des exigences : Levier de ma î trise de la...