Guide IEEE Pour La Specification

Norme IEEE 1233, dition 1998
(comprend la norme IEEE 1233-1996 et la norme IEEE 1233a-1998)
Guide de l'IEEE pour la Spcification dExigences de Systme

(Ceci est une traduction de la norme officielle IEEE Guide for Developing System Requirements Specifications)
Commanditaire :
Software Engineering Standards Committee de l'IEEE Computer Society

Norme IEEE 1233-1996, approuve le 17 avril 1996 Norme IEEE 1233a-1998, approuve le 8 dcembre 1998 Publies par le
IEEE-SA Standards Board
Rsum : Le prsent document constitue un guide pour l'laboration de l'ensemble des exigences, la spcification dexigences de systme (SES), dans le but de satisfaire un besoin exprim. L'laboration d'une SES comprend la dtermination, la structuration, la prsentation et la modification des exigences. Ce guide traite galement des conditions d'intgration, dans la spcification, des concepts oprationnels, des contraintes de conception et des exigences de configuration technique. Enfin, il couvre les caractristiques et qualits ncessaires de chaque exigence et de l'ensemble des exigences. Mots cls : exigence, SES, systme, spcification dexigences de systme
The Institute of Electrical and Electronics Engineers, Inc. 345 East 47th Street, New York, NY 10017-2394, USA Copyright Institute of Electrical and Electronics Engineers, Inc. Tous droits rservs. Publi le 22 dcembre 1998. Imprim aux tats-Unis. Version imprime : Version PDF : ISBN 0-7381-0337-3 ISBN 0-7381-1515-0 SH94659 SS94659
Toute reproduction dun extrait quelconque de cette publication par quelque procd que ce soit, et notamment par un systme dextraction lectronique, est strictement interdite sans autorisation crite de lditeur.
Les normes de l'IEEE sont labores par les socits de l'IEEE et par les comits de coordination des normes de l'IEEE Standards Association (IEEE-SA). Bnvoles, les membres des comits ne touchent aucune compensation, et ne doivent pas obligatoirement tre membres de lInstitut. Ces normes sont le produit d'un consensus obtenu entre les membres de lIEEE, qui dtiennent de vastes comptences, et les intervenants extrieurs, qui ont souhait participer llaboration de la norme. Lutilisation des normes de l'IEEE est absolument facultative. Lexistence dune norme IEEE ne signifie pas l'absence d'autres faons de produire, de tester, de mesurer, dacheter, de mettre en march ou de fournir les biens et services englobs dans cette norme. De plus, l'opinion exprime lors de lapprobation et de la publication dune norme est susceptible de changer la suite de lavancement des connaissances, et partir des commentaires formuls par ses utilisateurs. Chaque norme IEEE est rvise ou reconduite au moins tous les cinq ans. Lorsquun document date de plus de cinq ans et na pas t reconduit, il est raisonnable de conclure que son contenu, mme sil possde encore une certaine valeur, ne reflte pas les toutes dernires connaissances. Les utilisateurs devraient donc vrifier sils ont en main la version la plus rcente de la norme. LInstitut invite toutes les parties intresses, qu'elles soient affilies ou non a l'IEEE, lui faire part de leurs commentaires, en vue d'une ventuelle rvision. Les suggestions de modification d'un document doivent prendre la forme dune proposition de texte modifi, accompagne des commentaires. Interprtations : loccasion, le sens de certaines parties dune norme peut ncessiter une interprtation, par rapport une application spcifique. Ds que l'IEEE reoit une demande dinterprtation, il lance le processus de prparation de la rponse. Comme les normes IEEE sont le rsultat dun consensus entre toutes les parties intresses, il faut sassurer que les interprtations recueillent galement leur adhsion. Cest pourquoi lInstitut et les membres de ses socits et comits de coordination des normes ne sont pas en mesure de rpondre immdiatement de telles demandes, sauf dans les cas o la question a dj fait lobjet dun examen formel. Envoyer tout commentaire ou demande dinterprtation ladresse suivante : Secretary, IEEE Standards Board 443 Hoew Lane P.O. Box 1331 Piscataway, NJ 08855-1331 USA
Remarque : La mise en application de cette norme peut ncessiter lutilisation de technologies brevetes. Leur approbation par lInstitute of Electrical and Electronics Engineers ne signifie pas que lutilisation dune technologie en vue de se conformer une norme est autorise par le dtenteur du brevet. Il incombe lutilisateur dobtenir toutes les permissions ncessaires son utilisation. L'Institute of Electrical and Electronics Engineers, Inc. autorise la photocopie d'extraits de ses normes des fins internes ou personnelles, la condition que les droits correspondants soient verss au Copyright Clearance Center. Pour effectuer le paiement des droits de licence, communiquer avec le Copyright Clearance Center, Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA ; (978) 750-8400. La permission de photocopier des extraits de normes aux fins de formation doit galement tre demande au Copyright Clearance Center.
Copyright IEEE. Tous droits rservs
ii
Introduction
(Cette introduction ne fait pas partie de la norme IEEE 1233, dition 1998 Guide de l'IEEE pour l'laboration de spcifications dexigences de systme.)
Ce guide a pour objectif de proposer un cadre pour le recueil des exigences de systme. Destin l'analyste, il fournit une mthode prcise pour dterminer des exigences bien formes et offre des moyens de les structurer. Ce guide aidera l'analyste amorcer la phase de recueil des exigences de systme. Il lui servira clarifier les caractristiques d'une bonne exigence, et dterminer les diverses sources d'exigences. Le lecteur trouvera en annexe C les lignes directrices relatives l'utilisation de ce guide, dans le but de respecter les exigences tablies dans le document IEEE/EIA 12207.1-1997, IEEE/EIA Guide for Information TechnologySoftware life cycle processesLife cycle data [Guide de l'IEEE/EIA pour la technologie de l'information Processus du cycle de vie du logiciel Donnes du cycle de vie, NDT].
Participants
La norme IEEE 1233-1996 a t rdige par un groupe de travail reconnu par le Software Engineering Standards Committee [Comit des normes de gnie logiciel, NDT] de l'IEEE Computer Society [Socit d'informatique de l'IEEE, NDT]. Au moment l'approbation de cette norme, le groupe de travail tait form des membres suivants : Louis E. Miller, prsident
Bakul Banerjee David Byrch Kim A. Cady Larry Diehr Charles A. Droz Larry C. Forrest
William N. Sabor, secrtaire

P. Michael Guba James R. Hughes Joe Iaquinto Marybeth A. Jupina Thomas M. Kurihara Richard C. Lee Jim Longbucco Donald F. Parsons Eric Peterson John Sheckler Jess Thompson Eva D. Williams
Autres participants :
Geoff Cozens Paul Davis Kristin Dittmann Christof Ebert Don McCash Virginia Nuckolls Anne ONeill
Ont particip au vote sur la norme IEEE 1233-1996 :

H. Ronald Berlack Mark Bilger William J. Boll Fletcher Buckley Edward R. Byrne Franois Coallier Christopher Cooke Geoff Cozens Alan M. Davis Robert E. Dwyer Sherman Eagles Leo G. Egan Caroline L. Evans Richard L. Evans John W. Fendrich Peter Fillery Larry Forrest Eugene P. Friedman Eitan Froumine Yair Gershkovitch Adel N. Ghannam Julio Gonzalez-Sanz Patrick J. Griffin David A. Gustavson John Harauz Derek J. Hatley William Hefley Umesh P. Hiriyannaiah Jody Howard Eiichi Kaneko Jerry Kickenson Janet Kintner Thomas M. Kurihara Renee Lamb John B. Lane Boniface Lau J. Dennis Lawrence Ben Livson Harold Mains Roger Martin James W. McClean Sue McGrath Louis E. Miller Dennis E. Nickle Indradeb P. Pal Joseph A. Palermo Stephen R. Schach Norman Schneidewind
iii
Wolf A. Schnoege Gregory D. Schumacher Carl S. Seddio David M. Siefert Richard S. Sky Alfred R. Sorkowitz
Robert N. Sulgrove Tanehiro Tatsuta Richard H. Thayer George D. Tice Leonard L. Tripp Tom Vaiskunas
Thomas E. Vollman Ronald L. Wade Dolores Wallace William M. Walsh Paul R. Work Janusz Zalewski
La norme IEEE 1233a-1998 a t rdige par le Life Cycle Data Harmonization Working Group [Groupe de travail sur l'harmonisation des donnes sur le cycle de vie, NDT] du Software Engineering Standards Committee de l'IEEE Computer Society. Au moment de l'approbation de cette norme, le groupe de travail tait form des membres suivants : Leonard L. Tripp, prsident
Edward Byrne Paul R. Croll Perry DeWeese Robin Fralick Marilyn Ginsberg-Finner John Harauz Mark Henley Dennis Lawrence David Maibor Ray Milovanovic James Moore Timothy Niesen Dennis Rilling Terry Rout Richard Schmidt Norman F. Schneidewind David Schultz Basil Sherlund Peter Voldner Ronald Wade
Ont particip au vote sur la norme IEEE 1233a-1998:

Syed Ali Robert E. Barry Leo Beltracchi H. Ronald Berlack Richard E. Biehl Michael A. Blackledge Sandro Bologna Kathleen L. Briggs M. Scott Buck Michael Caldwell James E. Cardow Enrico A. Carrara Antonio M. Cicu Theo Clarke Sylvain Clermont Rosemary Coleman Virgil Lee Cooper W. W. Geoff Cozens Paul R. Croll Gregory T. Daich Geoffrey Darnton Taz Daughtrey Bostjan K. Derganc Perry R. DeWeese Evelyn S. Dow Carl Einar Dragstedt Sherman Eagles Christof Ebert Leo Egan Richard E. Fairley John W. Fendrich Jay Forster Kirby Fortenberry Eva Freund Barry L. Garner Marilyn Ginsberg-Finner John Garth Glynn Julio Gonzalez-Sanz L. M. Gunther David A. Gustafson Jon D. Hagar John Harauz Herbert Hecht William Hefley Mark Heinrich Debra Herrmann John W. Horch Jerry Huller Peter L. Hung George Jackelen Frank V. Jorgensen Vladan V. Jovanovic William S. Junk George X. Kambic Ron S. Kenett Judith S. Kerner Robert J. Kierzyk Thomas M. Kurihara John B. Lane J. Dennis Lawrence Randal Leavitt Fang Ching Lim John Lord Stan Magee Harold Mains Robert A. Martin Tomoo Matsubara Patrick D. McCray Bret Michael Alan Miller James W. Moore Pavol Navrat Alex Polack Peter T. Poon Lawrence S. Przybylski Kenneth R. Ptack Annette D. Reilly Dennis Rilling Helmut Sandmayr Stephen R. Schach Norman Schneidewind David J. Schultz Lisa A. Selmon Robert W. Shillato David M. Siefert Carl A. Singer Richard S. Sky Alfred R. Sorkowitz Donald W. Sova Luca Spotorno Julia Stesney Fred J. Strauss Toru Takeshita Richard H. Thayer Booker Thomas Patricia Trellue Leonard L. Tripp Theodore J. Urbanowicz Glenn D. Venables Udo Voges David D. Walden Dolores Wallace William M. Walsh John W. Walz Scott A. Whitmire P. A. Wolfgang Paul R. Work Natalie C. Yopconka Janusz Zalewski Geraldine Zimmerman Peter F. Zoll
iv
Lorsque l'IEEE-SA Standards Board [Comit des normes de l'IEEE-SA, NDT] a approuv la norme IEEE 1233a-1998, le 8 dcembre 1998, il tait form des membres suivants : Richard J. Holleman, prsident Donald N. Heirman, vice-prsident Judith Gorman, secrtaire
Satish K. Aggarwal Clyde R. Camp James T. Carlo Gary R. Engmann Harold E. Epstein Jay Forster* Thomas F. Garrity Ruben D. Garzon James H. Gurney Jim D. Isaak Lowell G. Johnson Robert Kennelly E. G. Al Kiener Joseph L. Koepfinger* Stephen R. Lambert Jim Logothetis Donald C. Loughry L. Bruce McClung Louis-Franois Pau Ronald C. Petersen Gerald H. Peterson John B. Posey Gary S. Robinson Hans E. Weinrich Donald W. Zipse
*Membre mrite Valerie E. Zelenty Rdactrice en chef des projets de normes de l'IEEE
Table des matires

1. Prsentation ................................................................................................................................................ 1 1.1 Porte.................................................................................................................................................... 1 2. Rfrences .................................................................................................................................................. 1 3. Dfinitions .................................................................................................................................................. 2 4. Spcification dexigences de systme ........................................................................................................ 4 4.1 Dfinition.............................................................................................................................................. 4 4.2 Proprits.............................................................................................................................................. 4 4.3 Objectif................................................................................................................................................. 5 4.4 Utilisation prvue ................................................................................................................................. 6 4.5 Avantages ............................................................................................................................................. 6 4.6 Dynamique des exigences de systme .................................................................................................. 7 5. Prsentation du processus d'laboration de la SES..................................................................................... 7 5.1 Client .................................................................................................................................................... 7 5.2 Environnement ..................................................................................................................................... 8 5.3 Communaut technique ...................................................................................................................... 10 6. Exigences bien formes ............................................................................................................................ 11 6.1 Dfinition d'une exigence bien forme ............................................................................................... 11 6.2 Proprits d'une exigence ................................................................................................................... 12 6.3 Catgorisation..................................................................................................................................... 13 6.4 Piges.................................................................................................................................................. 14 7. laboration de la SES............................................................................................................................... 15 7.1 Dfinir les exigences .......................................................................................................................... 15 7.2 Constuire une exigence bien forme................................................................................................... 17 7.3 Structurer les exigences ...................................................................................................................... 18 7.4 Prsenter les exigences ....................................................................................................................... 19 Annexe A (informative) Sommaire de la spcification dexigences de systme.......................................... 20 Annexe B (informative) Bibliographie......................................................................................................... 24 Annexe C (informative) Lignes directrices concernant la conformit avec la norme IEEE/EIA 12207.11997.............................................................................................................................................................. 25
vi
Guide de l'IEEE pour la Spcification dExigences de Systme
1. Prsentation
1.1 Porte
Ce guide propose un cadre pour l'laboration d'un ensemble d'exigences, afin de satisfaire un besoin exprim. Dans ce document, cet ensemble d'exigences est dnomm Spcification dexigences de systme (SES). La mise sur pied d'une SES comprend la dtermination, la structuration, la prsentation et la modification des exigences. Ce guide traite galement des conditions d'intgration, dans la spcification, des concepts oprationnels, des contraintes de conception et des exigences de configuration technique. Enfin, il couvre les caractristiques et qualits que doivent possder chaque exigence et l'ensemble de celles-ci. Ce guide ne prcise aucune norme de spcification de systme l'chelle industrielle et ne fixe aucune spcification dexigences de systme obligatoire. Sa rdaction se fonde sur le principe que l'tat actuel des connaissances en matire de conception de systmes ne justifie ou n'appuie aucun document de normes formel.
2. Rfrences
Ce guide devrait tre utilis paralllement aux publications suivantes : IEEE Std 100-1996, IEEE Standard Dictionary of Electrical and Electronics Terms.1 IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology. IEEE Std 730-1998, IEEE Standard for Software Quality Assurance Plans. IEEE Std 828-1998, IEEE Standard for Software Configuration Management Plans. IEEE Std 830-1998, IEEE Recommended Practice for Software Exigences Spcifications. IEEE Std 1074-1997, IEEE Standard for Developing Software Life Cycle Processes.
Les publications de l'IEEE sont disponibles auprs de l'Institute of Electrical and Electronics Engineers, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ 08855-1331, USA (http://www.standards.ieee.org/). Copyright IEEE. Tous droits rservs
Guide IEEE pour la spcification dexigences de systme
IEEE Std 1220-1998, IEEE Standard for Application and Management of the Systmes Engineering Process. ISO 9000-1: 1994, Quality management and quality assurance standards Part 1: Guidelines for selection and use.2 ISO 9126: 1991, Information technology Software product evaluation Quality characteristics and guidelines for their use. MIL-STD-490A, Spcification Practices.3 MIL-STD-498, Software Development and Documentation.
3. Dfinitions
Les dfinitions indiques ci-dessous n'ont de signification que dans le contexte de ce guide. Les termes non dfinis dans ce document sont inclus dans la norme IEEE 610.12-1990.4 3.1 Analyste : Membre de la communaut technique (ingnieur-systme ou analyste des systmes de gestion, charg de l'laboration des exigences de systme), dont les comptences et la formation lui permettent de dfinir des problmes et d'analyser, de crer et d'exprimer des algorithmes. 3.2 Annotation : Documentation complmentaire qui accompagne une exigence, comme de l'information historique ou des documents descriptifs. 3.3 Base de rfrence : Spcification ou systme qui, aprs avoir t valu et accept, sert de base aux dveloppements ultrieurs. Elle ne peut tre modifie qu'en vertu de procdures strictes de contrle des modifications. (Norme IEEE 610.12-1990) 3.4 Client : Entit pour laquelle il est ncessaire de satisfaire aux exigences relatives au systme dfinir et dvelopper. Il peut s'agir du client final du systme achev, d'une organisation appartenant la mme socit que l'organisation charge du dveloppement (ex. : la gestion des systmes), d'une socit ou d'une entit externe ou d'une combinaison des trois. C'est cette entit que le dveloppeur doit fournir la preuve que le systme satisfait aux exigences fixes. 3.5 Contrainte : nonc qui fixe des limites mesurables un lment ou une fonction du systme. Une contrainte constitue donc un paramtre impos, de force ou par compulsion, la solution et qui peut en restreindre ou en modifier l'volution. 3.6 lment : Composant d'un systme. Il peut s'agir d'un quipement, d'un programme informatique ou d'un humain. 3.7 Environnement : Circonstances, objets et conditions qui influenceront le systme achev. Il s'agit des facteurs politiques, commerciaux, culturels, organisationnels et physiques, ainsi que des normes et politiques qui rgissent ce que le systme doit faire ou comment il doit le faire. 3.8 Exigence : (A) Condition ou capacit requise par un utilisateur pour rsoudre un problme ou raliser un objectif. (B) Condition ou capacit qui doit tre remplie ou possde par un systme ou un de ses composants pour satisfaire un contrat, une norme, une spcification ou tout document impos de faon formelle. (C) Reprsentation documente d'une condition ou d'une capacit, telle que celle dfinie en (A) ou en (B). (Norme IEEE 610.12-1990)
Les publications de l'ISO sont disponibles auprs du Secrtariat central de l'ISO, Case postale 56, 1 rue de Varemb., CH-1211, Genve 20, Suisse (http://www.iso.ch/). Elles sont galement disponibles aux tats-Unis, auprs du Sales Department, American National Standards Institute, 11 West 42nd Street, 13th Floor, New York, NY 10036, USA (http://www.ansi.org/). 3 Les publications MIL sont disponibles auprs du Customer Service, Defense Printing Service, 700 Robbins Ave., Bldg. 4D, Philadelphia, PA 19111-5094, USA. 4 L'information sur les rfrences se trouve la section 2. Copyright IEEE. Tous droits rservs
2
3.9 Exigence bien forme : nonc de la fonctionnalit (capacit) d'un systme, qui peut tre valide, et qui doit tre remplie ou possde par un systme pour rsoudre le problme d'un client ou pour raliser l'un de ses objectifs. Cette exigence doit tre caractrise par des conditions mesurables et limite par des contraintes. 3.10 Exigence brute : Exigence fixe par l'environnement ou par l'humain, qui n'a pas t analyse et formule comme une exigence bien forme. 3.11 Exigence drive : Exigence dduite ou prsume partir du recueil et de la structuration des exigences dans une configuration et une solution particulires. 3.12 Fonction : Tche, action ou activit qui doit tre excute pour parvenir un rsultat recherch. 3.13 Modle : Reprsentation d'un processus, dispositif ou concept rel. 3.14 Prototype : Modle exprimental, fonctionnel ou non fonctionnel, du systme ou d'une partie du systme. Les prototypes servent susciter une rtroaction de la part des utilisateurs, dans le but d'amliorer et de spcifier une interface humaine complexe, dans le cadre d'tudes de faisabilit ou pour dterminer des exigences. 3.15 Reprsentation : Ressemblance, photo, dessin, schma fonctionnel, description ou symbole, qui reprsente logiquement une image ou une situation physique, oprationnelle ou conceptuelle. 3.16 Spcification dexigences de systme (SES) : Recueil structur d'informations, qui donne corps aux exigences de systme. 3.17 Systme : Groupe de personnes, d'objets et de processus interdpendants, constitu dans le but de raliser des objectifs dfinis ou de remplir un certain rle oprationnel, par l'excution de fonctions prcises. Un systme complet comprend tous les quipements, installations, matriels, programmes informatiques, micrologiciels, documentations techniques, services et personnels associs, exigs pour son fonctionnement et son soutien, dans le cadre d'une utilisation autonome dans son environnement prvu. 3.18 Testabilit : Niveau auquel une exigence est nonce, dans des termes qui permettent d'tablir des critres de test, puis l'excution de ces tests afin de dterminer si les critres sont remplis. (Norme IEEE 610.12-1990) 3.19 Traabilit : Niveau auquel il est possible d'tablir une relation entre plusieurs produits du processus de dveloppement, en particulier une relation de type prdcesseur-successeur ou principal-subordonn (ex. : le degr de correspondance entre les exigences et la conception d'un lment de systme donn). (Norme IEEE 610.12-1990) 3.20 Utilisateur final : Personne ou personnes qui utiliseront ultimement le systme aux fins prvues. 3.21 Validation : Processus d'valuation d'un systme ou d'un composant pendant ou au terme du dveloppement, qui permet de dterminer si ce systme ou ce composant satisfait aux exigences spcifies. (Norme IEEE 610.12-1990) 3.22 Vrification : Processus d'valuation d'un systme ou d'un composant, qui permet de dterminer si, une phase donne de son dveloppement, ce systme satisfait aux conditions imposes au dbut de cette phase. (Norme IEEE 610.12-1990)
4. Spcification dexigences de systme

Une spcification dexigences de systme (SES) est gnralement considre comme un document dans lequel sont nonces les exigences fixes par le client, l'intention de la communaut technique charge de la conception et de la ralisation d'un systme. Le recueil d'exigences qui forme la spcification et sa reprsentation sert de passerelle entre les deux parties ; il doit donc pouvoir tre compris par chacune d'elles. Lors de la cration d'un systme, l'une des tches les plus dlicates est d'ailleurs de communiquer ces exigences, en un seul document, tous les sous-ensembles de ces deux groupes. Cette opration requiert gnralement l'utilisation de divers formalismes et langages.
4.1 Dfinition
La SES prsente la dfinition des besoins, le concept oprationnel et les tches d'analyse du systme. Il s'agit donc de la description de ce que le client du systme attend de celui-ci, de son environnement prvu, de son profil d'utilisation, de ses paramtres de rendement, et de ses qualits et efficacit attendues. Ce document expose donc galement les conclusions du processus d'laboration de la SES dcrit la section 5. Ce guide suggre une distinction entre ce recueil structur de renseignements et la manire dont il est prsent ses diffrents destinataires. La forme de la prsentation de la SES doit tre adapte l'utilisation qu'on veut en faire. Il peut s'agir d'un document, de modles ou de prototypes sur papier, de documents sous un format autre, ou d'une combinaison de ceux-ci. Une mme SES permet de produire diverses reprsentations, dans le but de rpondre aux besoins d'un public particulier. Il faut cependant s'assurer que chacune d'entre elles puisse tre rattache une source commune d'information sur les exigences de systme. Le public doit tre sensibilis au fait que ce recueil structur d'informations demeure toutefois l'unique source de rfrence, en cas d'ambiguts dans la prsentation choisie. Ce guide tablit une nette distinction entre les exigences de systme (ce que le systme doit faire), contenues dans la SES, et les exigences du processus (comment construire le systme), qui doivent tre nonces dans un document rattach au contrat, tel qu'un cahier des charges.
4.2 Proprits
Le recueil des exigences doit possder les proprits suivantes : a) Ensemble unique. Chaque exigence doit n'tre nonce qu'une seule fois ;
b) Normalis. Les exigences ne doivent pas se chevaucher (c.--d. elles ne doivent pas renvoyer d'autres exigences ou aux capacits d'autres exigences) ; c) Ensemble li. Les exigences doivent tre lies entre elles par des relations explicitement dfinies, qui tablissent la manire dont elles sont rattaches pour constituer un systme complet ;
d) Complet. Une SES doit regrouper toutes les exigences fixes par le client, ainsi que celles ncessaires la dfinition du systme ; e) f) Homogne. Le contenu de la SES doit tre homogne et ne pas tre contradictoire, en ce qui concerne les dtails, le style d'nonc des exigences et la prsentation du matriel ; Limit. Les limites, la porte et le contexte de l'ensemble des exigences doivent tre dfinis ;
g) Modifiable. La SES doit pouvoir tre modifie. Des exigences claires et qui ne se chevauchent pas facilitent la ralisation de cet objectif ; h) Configurable. Il doit tre possible d'en crer des versions, dans le temps et en fonction de l'volution de la SES ; i) Granulaire. Correspond au niveau d'abstraction du systme dfini.
4.3 Objectif
L'objectif de la SES est de fournir une description boite noire de ce que le systme doit faire, en matire d'interactions ou d'interfaces avec son environnement externe. La SES doit dcrire intgralement toutes les entres, sorties, et relations obligatoires entre ces entres et sorties. La SES structure et communique les exigences au client et la communaut technique. 4.3.1 Structuration des exigences Une SES sera d'autant plus efficace qu'elle organisera mieux les exigences de systme en catgories conceptuelles. En pratique, il est difficile de dterminer et de sparer les exigences des autres aspects de la perception que le client a du systme, et qui sont souvent inclus dans des documents dfinissant des exigences. En effet, la dclaration des besoins fondamentaux est bien souvent occulte par les procdures d'utilisateur classiques, ou par les hypothses quant l'implmentation formules par l'utilisateur ou par la communaut technique. L'analyste doit donc recueillir et noncer les besoins fondamentaux du client et de la communaut technique, formuler convenablement les exigences et structurer ou regrouper ces besoins et exigences en catgories explicites. Tout en rassemblant les exigences non structures de l'utilisateur en un ensemble organis, l'analyste doit dterminer les exigences techniques, sans s'garer dans un nonc d'approche de mise en uvre. S'engager dans les questions d'implmentation avant de bien comprendre les exigences peut conduire un nonc inadquat de ces exigences et une mise en uvre dfectueuse. Faire la distinction entre les exigences techniques et les mises en uvre techniques reprsente un dfi permanent pour l'analyste. La description du systme doit tre nonce en termes oprationnels et logistiques. Les questions traites doivent comprendre les capacits oprationnelles du systme souhaites, ses caractristiques physiques, les paramtres de rendement et leurs valeurs prvues, les interfaces et interactions avec l'environnement, et les exigences relatives la documentation, la fiabilit, la logistique et au personnel. Ces exigences doivent tre communiques de faon structure. Ainsi, le client et la communaut technique seront capables : a) c) e) f) de dterminer les exigences issues d'autres exigences ; de vrifier l'exhaustivit de l'ensemble d'exigences ; de dterminer de faon claire les capacits, conditions et contraintes de chaque exigence ; de atteindre une comprhension commune des objectifs de l'ensemble des exigences ;
b) de classer les exigences par niveau de dtail ; d) de dceler les incohrences entre les exigences ;
g) de dterminer les exigences qui complteront la SES. Il est important que l'analyste inclue la structure l'ensemble d'exigences, et que les reprsentations de la SES communiquent ces exigences de faon organise. Des lignes directrices pour la dfinition explicite des exigences sont fournies la section 6. 4.3.2 Communication aux deux destinataires La SES a principalement deux destinataires, et son rle est essentiellement de documenter le contrat pass entre le client et la communaut technique.
4.3.2.1 Client Client est un terme collectif qui peut inclure le client du systme propos, l'organisme de financement, la personne responsable de l'acceptation du systme, et qui signera la livraison, et les responsables de la supervision de la mise en uvre, du fonctionnement et de la maintenance du systme. La SES doit rpondre aux intrts et aux proccupations directs des clients. Certains clients peuvent ne pas comprendre les processus d'tablissement d'exigences ou de cration de systmes. En effet, quoique comptents dans leur domaine de responsabilit et dans l'application pour laquelle le systme est dfini, ils ne sont gnralement pas familiariss avec le vocabulaire et la reprsentation techniques, qui sont souvent employs pour spcifier les exigences. L'un des objectifs principaux de l'analyse des exigences de systme tant de garantir que la SES est bien comprise, cette dernire doit tre prsente au client dans un langage qu'il est susceptible de comprendre, et qui est complet, concis et clair. 4.3.2.2 Communaut technique Le SES doit galement transmettre les exigences du client la communaut technique. Celle-ci est compose des analystes, estimateurs, concepteurs, agents d'assurance-qualit, certificateurs, testeurs, agents de maintenance et fabricants. La reprsentation de la SES qui s'adresse ces destinataires doit tre techniquement prcise et construite dans un formalisme qui leur donnera la possibilit de concevoir, construire et tester le systme recherch.
4.4 Utilisation prvue

L'utilisation recommande de la SES, qui peut varier en cours d'laboration, est la suivante : a) Lors de la conception du systme, les exigences sont attribues aux sous-systmes, matriels, logiciels, fonctionnements et autres composants essentiels du systme ;
b) La SES sert btir le systme rsultant. Elle est galement utilise pour la rdaction des plans de vrification correspondant au systme. Si le systme comporte du matriel et des logiciels, les plans de test matriel et logiciel doivent galement tre labors partir des exigences de systme ; c) Pendant la phase de mise en uvre, les procdures de test sont dfinies partir de la SES ; d) Durant le processus de validation, les procdures de validation tires de la SES sont utilises par le client comme base pour l'acceptation du systme. Toute modification apporte la base de rfrence de la SES doit tre contrle au moyen d'un processus formel de gestion. Ce processus doit comprendre la ngociation entre les parties concernes par la modification et dclencher l'valuation du risque correspondante (p. ex. sur les chanciers ou sur les cots).
4.5 Avantages
Une SES convenablement rdige profite toutes les phases suivantes du cycle de vie. La SES documente l'ensemble des capacits du systme et procure les avantages suivants : a) Assure le client que la communaut technique comprend ses besoins et cherche y rpondre ;
b) Offre une premire possibilit de rtroaction bidirectionnelle entre le client et la communaut technique ; c) Procure une mthode permettant au client et la communaut technique de dceler les problmes et les incomprhensions, et de les rsoudre relativement peu de frais ;
d) Sert de base pour dterminer si le systme rpond ou non aux besoins du client ;
e) f)
Protge la communaut technique, en fournissant une base de rfrence pour les capacits du systme et une rfrence pour dterminer l'achvement du systme ; Soutient le dveloppeur dans la planification et la conception de son programme, ainsi que dans ses efforts d'laboration ;
g) Facilite l'valuation des effets des invitables modifications apportes aux exigences ; h) Assure une protection accrue contre les problmes de comprhension entre le client et la communaut technique, au cours du dveloppement.
4.6 Dynamique des exigences de systme

Les exigences sont rarement statiques, et bien qu'il soit souhaitable d'en fixer un ensemble de faon permanente, c'est rarement possible. On peut, par contre, figer un sous-ensemble d'exigences principales. Il est, par consquent, ncessaire de dterminer les exigences dont les probabilits d'volution sont importantes, et de les communiquer ensuite au client et la communaut technique. Il est ncessaire d'valuer l'impact des nouvelles exigences proposes, afin de s'assurer que le but original de la base de rfrence des exigences est conserv, ou que les changements apports l'objectif sont compris et accepts par le client.
5. Prsentation du processus d'laboration de la SES

Cette section offre un aperu des tapes de l'laboration de la SES. En gnral, le processus d'tablissement des exigences de systme est reli trois facteurs externes : le client, l'environnement et la communaut technique. Chacun d'eux est dcrit plus bas. La figure 1 illustre leurs interactions.
EXIGENCE BRUTE CLIENT RTROACTION CLIENT LABORER LE RECUEIL DES EXIGENCES DE SYSTME RTROACTION TECHNIQUE
REPRSENTATION CLIENT
CONTRAINTE/INFLUENCE ENVIRONNEMENT
REPRSENTATION TECHNIQUE
COMMUNAUT TECHNIQUE
Figure 1 Contexte d'laboration d'une SES
5.1 Client
Le client est la cl de vote contextuelle de la SES. C'est lui qui donne l'impulsion initiale au systme en fournissant les objectifs, besoins et problmes au processus d'laboration de la SES. Les changes entre les clients et les dveloppeurs de la SES sont dcrits ci-dessous. 5.1.1 Exigences brutes Avant l'laboration de la SES, le client dispose dj d'une ide de systme, d'amlioration apporter un processus ou de problmes rsoudre. Le concept du systme n'est peut-tre pas encore trs prcis et structur ; les exigences sont, ce stade-ci souvent enchevtres avec les ides et les suggestions relatives aux conceptions possibles. Ces exigences brutes sont souvent exprimes dans des documents introductifs tels que :
a)
Concept de fonctionnement. Se concentre sur les objectifs et les capacits gnrales souhaites du systme, sans prciser le type de mise en uvre qui permettra d'atteindre ces buts ;
b) Concept de systme. Comprend l'information sur le concept de fonctionnement, mais galement la conception d'une interface prliminaire pour le systme, ainsi que d'autres exigences explicites ; c) Spcification commerciale. Se compose d'une liste de caractristiques (souvent sous forme d'une liste puces) pour le nouveau systme, et dfinit la porte de ces caractristiques et leur priorit (obligatoire ou hautement souhaitables), qui permettront de positionner le systme de faon concurrentielle. Il inclut galement un contexte ou des limites, qui dterminent la manire dont le nouveau systme devra interagir avec les systmes existants. La spcification commerciale peut tre complte par une analyse cots-avantages et un chancier de livraison ;
d) Appel d'offres. Un appel d'offres est parfois ncessaire. Il peut comprendre un ou plusieurs des documents introductifs mentionns ci-dessus. Il a pour objet de solliciter des soumissions, qui seront ensuite tudies sous divers aspects de la construction du systme. Il peut aussi, tout simplement, constituer une demande d'aide pour la production des documents introductifs du systme ; e) Interfaces externes du systme. La dfinition, de faon stricte ou par rfrence, des interfaces externes au systme est l'une des tapes les plus importantes (quoique souvent nglige) a excuter avant la rdaction de la SES. Une dfinition approuve du milieu externe du systme permet de limiter raisonnablement ce qu'on en attend l'interne. Il est ncessaire de dcrire tous les lments connus de chacune des interfaces. Cette information peut tre incluse dans la SES, si elle est trop volumineuse. Cependant, dans la plupart des cas, il vaut mieux laborer un document de contrle des interfaces externes au systme (DCI). Il existe de nombreux types d'interfaces externes, et un mme systme peut en possder plusieurs. En voici quelques exemples : Oprationnelle Ordinateur-ordinateur lectrique Transmission de donnes et protocoles Lignes de tlcommunications Dispositif-systme, systme-dispositif Ordinateur-systme, systme-ordinateur Contrle et dtection de l'environnement
5.1.2 Reprsentation du client La rtroaction destine au client comprend les reprsentations de la SES, et les changes ou communications techniques, qui permettent de clarifier ou de confirmer les exigences. 5.1.3 Rtroaction du client La rtroaction du client est compose de l'information de mise jour de ses objectifs, problmes ou besoins, des renseignements de modification des exigences relatives aux communications et aux changes techniques, et des donnes pour la dtermination de nouvelles exigences.
5.2 Environnement
En plus de l'analyste et du client, l'environnement peut implicitement ou explicitement influencer les exigences de systme ou crer des contraintes. L'analyste doit tre conscient de cette influence sur les capacits du systme. Dans les cas de systmes sensibles aux facteurs environnementaux, le client et l'analyste prciseront ceux qui touchent les exigences de systme. Les facteurs environnementaux se classent en plusieurs catgories, qui peuvent se chevaucher : a) Facteurs politiques ;
b) Facteurs commerciaux ;
c) e) f)
Normes et politiques techniques ; Facteurs organisationnels ; Acteurs physiques.
d) Facteurs culturels ;
Ces catgories, dont il est essentiel de tenir compte, sont dcrites ci-dessous. Cette liste n'est cependant pas exhaustive. 5.2.1 Facteurs politiques Les divers organismes gouvernementaux internationaux, fdraux, provinciaux et locaux ont promulgu des lois qui peuvent influencer les exigences de systme. Certains d'entre eux disposent d'agences responsables de la mise en application des lois et rglements et charges de vrifier que les systmes les respectent. Parmi les lois fdrales, citons la Loi sur le droit d'auteur, la Loi sur les brevets et la Loi sur les marques de commerce. Quant aux rglements, il en existe notamment sur le zonage, sur les risques environnementaux, sur les dchets, sur le recyclage, sur la scurit des systmes et sur la sant. Les facteurs politiques varient selon le pays. Les paramtres qui influent sur les exigences de systme dans un environnement peuvent tre compltement diffrents dans un autre. Par consquent, il est important d'effectuer des tudes dans le cadre politique dans lequel le systme sera construit et utilis, afin de s'assurer que celui-ci est conforme aux lois et rglements en vigueur. 5.2.2 Facteurs commerciaux L'laboration de la spcification de systmes peut tre influence par trois types de conditions du march. La premire fait correspondre le systme aux besoins de la clientle, l'aide d'tudes de march ou par le dveloppement de marchs adapts la recherche technique. Adapter un systme aux besoins du client touche les exigences de systme en premier lieu et entre dans les exigences de ce client. La deuxime condition est la rponse la demande. Comme l'illustre la figure 1, ce facteur fait partie des paramtres environnementaux. Il est ncessaire de tenir compte de la rponse la demande, car elle touche la distribution et l'accessibilit du systme, qui constituent d'autres exigences de systme (ex. : Le systme doit tre lger pour rduire les cots d'expdition, le systme doit tre de dimensions rduites pour entrer dans les distributeurs automatiques, etc.). Les exigences de distribution et d'accessibilit doivent tre dfinies lors de l'laboration du systme, avant sa fabrication ou son intgration, afin qu'elles puissent y tre incorpores. Un systme dont l'accs est malais ne connatra qu'un succs limit. Par consquent, il est important de tenir compte des segments de march auxquels il s'adresse, et de considrer la manire dont l'information de marketing peut tre utilise pour dterminer les exigences de systme. Le troisime facteur d'influence est la concurrence. La connaissance des systmes concurrents facilite la dfinition des exigences. Rester comptitif ncessite de tenir compte des lments suivants : a) c) e) f) fonctionnalit ; fiabilit ; rendement ; maintenabilit ;
b) prix ; d) durabilit ;
g) scurit. L'analyse du march concurrentiel est un processus permanent, et concerne les exigences des systmes nouveaux comme les exigences des dispositifs existants. Ses rsultats peuvent faire voluer un systme un point tel qu'il ne ressemble que de trs loin au concept original du client.
5.2.3 Normes et politiques techniques Les exigences de systme sont directement influences par les clients, qui cherchent se conformer aux normes et aux politiques techniques fixes par les gouvernements ou les industries. Les politiques techniques, et les normes et lignes directrices associes aident garantir : a) c) l'homognit d'un systme ; sa fiabilit et sa maintenabilit.
b) sa scurit ;
En fournissant des dtails sur la manire de mettre en uvre un systme donn, les normes et les lignes directrices relatives l'homognit crent des exigences particulires. L'objectif des normes de scurit industrielle est gnralement de limiter les risques d'accident et d'viter les problmes juridiques ventuels. Les exigences de scurit doivent tre clairement dfinies dans un document prcis (ex. : exigences de scurit pour l'industrie du jouet, homologations UL, exigences du Code lectrique national, etc.). Le client et la communaut technique peuvent galement exiger que le systme respecte certains critres de fiabilit tablis dans des normes techniques. Les exigences de fiabilit et de maintenabilit doivent tre dtermines dans la SES. Elles sont de natures diverses. Elles peuvent, par exemple, tre directement orientes systme et ncessiter la spcification du temps d'indisponibilit maximal ou du dlai moyen minimal entre deux pannes, ou bien encore du temps de rparation moyen minimal. 5.2.4 Facteurs culturels La culture est l'ensemble des modles de comportement humains intgrs, transmis de gnration en gnration. Il s'agit d'une exprience acquise, relie aux croyances religieuses, au pays d'origine, au groupe ethnique, au niveau socioconomique, la langue, au milieu, au lieu d'emploi et aux caractristiques de la famille immdiate. Pour bien comprendre la culture d'une rgion ou d'un segment de march, il faut en connatre les valeurs et les croyances. Lors de l'laboration d'un systme, il est essentiel de tenir compte des influences culturelles, car elles touchent les exigences de systme. 5.2.5 Facteurs organisationnels Les exigences de systme sont galement soumises l'influence de l'organisation au sein de laquelle elles sont labores. Les facteurs organisationnels introduits par la socit peuvent provenir du marketing, de la politique interne, des politiques techniques ou des normes internes. L'influence exerce sur les exigences de systme par une socit est semblable celle exerce par les autres milieux, mais ses caractristiques sont uniques (c.--d. chaque socit a sa propre culture, ses propres objectifs et ses propres valeurs, qui influencent le systme qu'elle conoit, fabrique ou livre). 5.2.6 Facteurs physiques Les influences physiques comprennent les facteurs d'origine naturelle et humaine, tels que la temprature, le rayonnement, l'humidit, la pression et la prsence de produits chimiques.
5.3 Communaut technique

La communaut technique, illustre la figure 1, est compose des personnes concernes par les oprations visant le systme : conception, mise en uvre, intgration, test, fabrication, dploiement, exploitation et maintenance. Tous les membres de la communaut technique devraient tre associs l'laboration de la SES, et le plus tt possible. Cette intgration prcoce de la communaut technique rduit le risque, pour les responsables de la mise au point de la SES, de ne s'apercevoir de nouvelles exigences ou de modifications apportes aux exigences tablies que tard dans le cycle de vie.
10
5.3.1 Reprsentation technique La reprsentation du recueil d'exigences destin la communaut technique devrait inclure les changes ou communications techniques permettant de clarifier ou de confirmer les exigences. 5.3.2 Rtroaction technique La communaut technique produit une rtroaction lors de toutes les oprations susceptibles d'entraner la modification, l'ajout ou la suppression d'exigences. La SES est alors raffine de manire prendre en charge les phases suivantes du cycle de vie du systme. Par exemple, la suite de la phase d'laboration des exigences, un plan de test du systme peut tre mis sur pied, et chaque exigence rattache un test bien prcis. Ce processus peut rvler que certaines exigences ne sont pas testables ; la SES est alors modifie en consquence. D'autres rtroactions provenant de la communaut technique peuvent permettre au client de connatre les caractristiques les plus rcentes du systme et les technologies venir, et lui offrir un aperu des mthodes de mise en uvre avances.
6. Exigences bien formes

La prsente section explique les proprits d'une exigence bien forme, fournit un exemple d'exigence bien forme et souligne les piges dans lesquels les exigences ne doivent pas tomber.
6.1 Dfinition d'une exigence bien forme

Comme dfini prcdemment, une exigence bien forme nonce la fonctionnalit (capacit) d'un systme. Elle doit pouvoir tre valide et tre remplie ou possde par ce systme pour rsoudre le problme du client ou pour raliser l'un de ses objectifs. Cette exigence doit tre caractrise par des conditions mesurables et limite par des contraintes. Cette dfinition facilite la classification des exigences gnrales du client, qui peuvent provenir des besoins exprims par ce mme client ou rsulter de l'analyse technique. Elle constitue un moyen de distinguer les exigences en tant que capacits, de leurs attributs (conditions et contraintes). Les contraintes sont d'ordre fonctionnel ou non fonctionnel. Une contrainte non fonctionnelle peut, par exemple, demander que le systme soit peint dans un ton particulier de bleu, uniquement dans un but dcoratif (non obligatoire). Ce guide recommande ne ne pas inclure dans la SES les exigences de mise en uvre, telles que l'obligation de recourir une mthodologie de conception particulire. Celles-ci seront contenues dans d'autres documents techniques de contrle du systme, comme le plan de qualit, le contrat ou le cahier des charges. 6.1.1 Capacits Les capacits sont les exigences fondamentales du systme. Elles reprsentent les caractristiques ou les fonctions requises ou souhaites par le client. Une capacit doit gnralement tre nonce d'une faon telle qu'elle dcrit ce que le systme doit faire. Elle doit galement tre prcise de faon tre indpendante de la solution, afin de permettre l'tude de diffrents moyens de rpondre au besoin ou de fournir la caractristique ou la fonction. Par exemple, les capacits d'un train grande vitesse reliant Los Angeles New York peuvent inclure l'aptitude dmarrer, acclrer, circuler vitesse de croisire, dclrer, s'arrter, et faire embarquer et dbarquer des passagers. Cependant, la marque du systme d'exploitation informatis ne sera pas considre comme une capacit. 6.1.2 Conditions Les conditions sont des attributs et des caractristiques qualitatifs ou quantitatifs mesurables, stipuls pour une capacit. Elles caractrisent de faon plus dtaille la capacit requise, et permettent de formuler et 11
d'noncer cette capacit sous une forme validable et vrifiable. Par exemple, dans le cas du train grande de vitesse mentionn ci-dessus, une condition de la capacit de circuler vitesse de croisire peut tre une vitesse de croisire comprise entre 0 et 300 km/h ou une vitesse de croisire optimale de 200 km/h. Bien videmment, les conditions (attributs mesurables) ne peuvent correspondre qu' un lment mesurable, comme une capacit. Il serait inutile, par exemple, de fixer une exigence stipulant une vitesse de 0 200 km/h de faon abstraite. En effet, si cette plage peut caractriser la vitesse de croisire d'un train grande vitesse, elle ne correspond pas la vitesse de monte d'un ascenseur. Les conditions peuvent limiter les choix dont dispose le concepteur. Il est donc important de dfinir les conditions en tant qu'attributs de capacits, et non comme capacits principales, afin de s'assurer que les exigences dfinissent clairement les besoins, sans imposer de limites au champ de la solution. 6.1.3 Contraintes Les contraintes sont des exigences imposes la solution par les circonstances, la force ou la compulsion. Elles restreignent absolument les choix dont dispose le concepteur de la solution, en tablissant des limites inflexibles. Par exemple, le train grande vitesse mentionn plus haut est limit par le besoin d'amener les passagers destination, vivants (une contrainte de scurit pourrait tre l'obligation d'installer des ceintures de scurit). Il pourrait galement tre restreint par la technologie (le client peut exiger que la logique de contrle du train soit entirement crite en Ada). La liste des contraintes peut comprendre des interfaces non modifiables avec des systmes existants (format, protocole, contenu, etc.), des limitations de dimensions physiques (ex. : Un contrleur doit pouvoir prendre place dans un espace rduit de l'aile d'un avion), les lois de la nature, les lois d'un pays particulier, le temps ou le budget disponible, la priorit (p. ex. obligatoire ou facultative) ou l'utilisation d'une plateforme de technologie prexistante. Les contraintes peuvent s'appliquer toutes les exigences, ou tre spcifies par rapport une capacit ou un ensemble de capacits prcis. Les contraintes peuvent tre autonomes (c.--d. ne limiter aucune capacit en particulier) ou relies une capacit prcise. De nombreuses contraintes, comme le choix de la technologie (ex. : le type de systme d'exploitation), s'appliquent l'ensemble des capacits. D'autres ne s'appliquent qu' une seule ou certaines d'entre elles. Par exemple, plusieurs contraintes de scurit relatives l'acclration du train grande vitesse ne s'appliqueront pas aux fonctions d'embarquement des passagers. 6.1.4 Exemple Cet exemple a pour but d'noncer une exigence bien forme, ainsi que les conditions et capacits associes. Exigence : Dplacer des gens de New York la Californie une vitesse maximale de 5300 km/h. Capacit : Transporter des gens entre Los Angeles et New York Condition : Vitesse de croisire de 2500 km/h Contrainte : Vitesse maximale de 5300 km/h
6.2 Proprits d'une exigence

Chaque exigence doit possder les proprits suivantes : a) Abstraite. Elle doit tre indpendante de la mthode de mise en uvre ;
b) Non ambigu. Elle doit tre nonce de manire n'te interprtable que d'une seule manire ;
12
c)
Traable. Il doit tre possible d'tablir une relation entre la dclaration prcise des besoins du client documente et les noncs spcifiques de la dfinition du systme inclus dans la SES. Cette relation indique ainsi la source de l'exigence ;
d) Validable. Elle doit offrir un moyen de prouver que le systme satisfait son nonc.
6.3 Catgorisation
Pour permettre leur analyse, les exigences doivent tre catgorises selon leurs identification, priorit, criticit, faisabilit, risque, source et type. Chacune de ces catgories est dtaille ci-dessous. a) Identification. Chaque exigence doit tre identifie de faon unique (numro, tiquette nominative, mnmonique, boutons, lien hypertexte, etc.). Si ncessaire, l'identification peut reflter des liens ou des relations ;
b) Priorit. Le client doit dfinir la priorit de chaque exigence, l'aide, par exemple, d'un processus dtermin par l'ensemble des clients potentiels. Il peut pour cela utiliser une chelle numrique (ex. : de 1 10) ou une gradation simple, comme Haute, Moyenne, Basse, Aucune ; c) Criticit. L'analyste, en collaboration avec le client, doit dfinir la criticit de chaque exigence. Certaines exigences peuvent avoir une priorit basse, du point de vue de l'utilisateur, mais tre tout de mme essentielles au succs du systme. Par exemple, une exigence commandant de mesurer la temprature ambiante extrieure peut tre indispensable une autre exigence, comme le maintien de la temprature intrieure de la cabine. Cette relation doit tre dtermine de telle faon que si l'exigence principale est supprime par le client, l'exigence de soutien peut galement tre limine ;
d) Faisabilit. Le client et l'analyste doivent collaborer pour dterminer la faisabilit de chaque exigence de systme, et classifier les exigences selon le type de faisabilit correspondant au domaine du systme. La faisabilit s'appuie sur la comprhension d'lments tels que l'tat actuel de la technologie (c.--d. les composants disponibles dans le commerce par rapport la recherche initiale), l'environnement du client (c.--d. sa bonne volont ou sa capacit accepter des modifications) et le risque ou les cots associs une exigence particulire ; e) Risque. Il est possible de recourir des techniques d'analyse du risque pour dterminer un classement des exigences de systme. Les principaux risques concernent les pertes financires, l'impact environnemental, la scurit et la sant, et les normes ou lois nationales ; Source. Chaque exigence doit tre, de plus, classifie selon une tiquette qui en indique l'origine. Une exigence peut provenir de plusieurs sources ou crateurs. Il est particulirement utile d'identifier les crateurs de chaque exigence. Ainsi, si l'exigence n'est pas claire, si elle est conflictuelle ou ncessite d'tre modifie ou supprime, il sera possible de dterminer les personnes ou les organisations consulter ; Entre (ex. : Recevoir des donnes d'EDI), Sortie (ex. : Exporter un format particulier), Fiabilit (ex. : Temps moyen avant une panne), Disponibilit (ex. : Nombre d'heures de fonctionnement prvu), Maintenabilit (ex. : Facilit de remplacement des composants), Rendement (Performance, ex. : Temps de rponse), Accessibilit (ex. : Diffrents chemins de navigation pour les utilisateurs novices et les utilisateurs expriments), Conditions ambiantes (Environnement, ex. : Niveau de poussires devant tre tolr), Ergonomie (ex. : Utilisation de couleurs particulires pour rduire la fatigue oculaire), Scurit (ex. : Rayonnement lectromagntique maximal), Sret (ex. : Limites d'accs physique, fonctionnel ou de donnes, pour utilisateurs autoriss ou non autoriss),
f)
g) Type. Il est galement possible de catgoriser les exigences selon l'un des facteurs suivants :
13
Exigences relatives l'installation (ex. : Utilisation du courant lectrique domestique), Transportabilit (ex. : Limites de poids pour la portabilit). Formation (ex. : Comprend des tutoriels ou une formation par informatique), Documentation (ex. : Aide en ligne), Interfaces externes (ex. : Compatible avec la norme industrielle relative au mode ou au format de communication), Test (ex. : Permet le tldiagnostic), Dispositions relatives la qualit (ex. : Intervalles d'talonnage minimum requis), Politique et rglementaire (ex. : Politiques des organismes de protection de l'environnement), Compatibilit avec les systmes existants (ex. : Utilise les systmes tlphoniques analogiques comme mode par dfaut), Normes et politiques techniques (ex. : Les produits doivent tre compatibles avec les codes ASME), Conversion (ex. : Accepte les donnes provenant des versions prcdentes du systme), Capacit de croissance (ex. : Pourra prendre en charge l'augmentation du nombre des utilisateurs), Installation (ex. : Capacit mettre un nouveau systme en service),
6.4 Piges
Piges viter lors de l'laboration d'exigences bien formes : a) Conception et mise en uvre. Les analystes et les clients ont tendance, lorsqu'ils dfinissent les exigences, inclure leur nonc des dcisions touchant la conception et la mise en uvre. Cette information peut tre trs importante, mais elle doit dans ce cas tre documente et diffuse dans un document d'une autre forme, afin d'aider la conception et la mise en uvre ;
b) Surspcification 1) Exigences qui dcrivent un systme prcis propos dans le commerce, et qui peut donc tre achet plutt que fabriqu (elles ne sont pas l'expression de ce que le systme doit faire), 2) Exigences qui fixent des tolrances pour des lments faisant spcifiquement partie du concept (souvent dnommes exigences errones de trs bas niveau), 3) Exigences qui mettent des solutions en application (les exigences dcrivent un besoin) ; c) Surcontrainte. Exigences comportant des contraintes inutiles. Par exemple, si un systme doit pouvoir fonctionner avec des accumulateurs rechargeables, une exigence drive peut tre que le temps de recharge doit tre infrieur 3 heures. Si ce dlai est trop restrictif et qu'un temps de recharge de 12 heures est suffisant, des solutions potentielles seront limines ;
d) Non limites. 1) Exigences avec nonc relatif. Ces exigences ne peuvent pas tre vrifies et peuvent ne ncessiter qu'une reformulation de leur nonc. Par exemple, l'exigence stipulant de minimiser le bruit peut tre reformule en le niveau de bruit ne doit pas dpasser , 2) Exigences ouvertes (souvent nonces sous la forme incluant, mais non limite ou listes qui se terminent par etc.), 3) Exigences dont l'nonc est vague ou subjectif (contiennent souvent des termes tels que convivial, temps de rponse court ou conomique) ; e) Hypothses. 1) Exigences bases sur des hypothses non documentes. (L'hypothse doit tre documente, tout comme l'exigence), 2) Exigences bases sur l'hypothse selon laquelle une norme ou un systme en cours d'laboration sera achev. (Il est ncessaire de documenter l'hypothse, ainsi qu'une exigence de remplacement.)
14
7. laboration de la SES
L'laboration de la spcification dexigences de systme, illustre la figure 1, est un processus itratif. Elle est subdivise en quatre sous-processus, exposs la figure 2 : a) Dtermination des exigences partir des demandes du client, de l'environnement et de l'exprience de la communaut technique ; Structuration des exigences en une SES ;
b) Construction d'exigences bien formes ; c) d) Reprsentation de la SES sous diverses formes, pour divers destinataires. Dcomposer l'laboration de la spcification dexigences de systme en sous-processus facilite l'tablissement d'une SES complte et prcise. Bien que les sous-processus soient prsents ci-dessous comme se produisant en squence, il arrive en fait frquemment qu'ils se chevauchent et se rptent. En raison de l'excution rpte de ce processus, la SES est constamment modifie. Ces modifications concernent gnralement la base de rfrence et sont gres au moyen de procdures de contrle. (Voir la norme IEEE 1220-1998 pour les procdures de contrle des modifications.)
EXIGENCE BRUTE CLIENT CONTRAINTE/ INFLUENCE DFINIR LES EXIGENCES EXIGENCES RECUEIL DES EXIGENCE S NONCER DES EXIGENCES BIEN FORMES
ENVIRONNEMENT
CLIENT
RTROACTION CLIENT
COMMUNAUT TECHINQUE
RTROACTION TECHNIQUE
DONNES DES EXIGENCES BIEN FORMES EXIGENCES STRUCTURES PRSENTER LA SES
STRUCTURER LES EXIGENCES
CLIENT
COMMUNAUT TECHINQUE
Figure 2 laboration de la SES
7.1 Dfinir les exigences

En association avec le client, l'analyste filtre les diverses informations dfinies la figure 2. Il en extrait un ensemble d'exigences, formule les exigences drives ncessaires et cre les exigences manquantes. Les exigences peuvent provenir des documents introductifs ou tre le fruit d'exercices analytiques mens conjointement avec le client. Le but de ce processus itratif est de solliciter toutes les exigences de systme, de s'assurer que chaque exigence n'est nonce qu'une seule fois et qu'aucune n'est oublie. La dfinition des exigences du client peut suivre plusieurs approches diffrentes. En pratique, chaque organisation dispose de sa propre dmarche pour dterminer les exigences et amorcer le processus de
15
cration de la solution. Dans certaines socits, le client ralise la totalit du processus l'interne. Dans ce cas, la dfinition et la spcification des exigences sont diriges par le client. Dans d'autres organisations, le client dfinit un ensemble prliminaire d'exigences et demande l'aide d'un analyste interne, ou d'un consultant ou d'un intgrateur de systme externe. L'analyste, qu'il soit interne ou externe, collabore avec le client pour dfinir et structurer les exigences. Dans certaines organisations, l'analyste travaille directement avec le client. Dans d'autres socits, il n'a pas directement accs au client et doit passer par un ou plusieurs intermdiaires (technique, juridique, administratif, ), qui reprsentent le client. En raison de la dynamique propre la dfinition d'exigences, il est important que le client et l'analyste s'entendent sur le processus. L'analyste tablit le plan qui guidera le processus, dfinit les reprsentations de la SES qui seront produites l'intention des divers destinataires et dtermine les outils et mthodes utiliser. Le processus doit voluer vers l'laboration de la base de donnes de la SES et la fourniture au client d'un systme rpondant ses besoins. L'analyste doit s'assurer d'utiliser toutes les mthodes appropries pour dterminer les exigences. Il est essentiel de recourir un processus de gestion des exigences, afin de garantir que : a) c) le processus est orient vers un objectif et est ax vers l'tablissement d'un ensemble d'exigences ; toutes les exigences sont sollicites et values de manire juste, et documentes ;
b) les limites du systme sont dfinies ; d) les exigences sont spcifies en tant que capacits, et que les conditions d'admission et les contraintes sont dfinies de manire distincte des capacits ; e) f) les exigences sont valides, ou sont supprimes de l'ensemble des exigences si elles ne sont pas valides ; l'homognit est recherche, lorsque plusieurs personnes (auteurs) contribuent l'laboration de l'ensemble d'exigences ;
g) l'ensemble d'exigences labor est compris, un niveau adquat de dtail, par tous les intervenants. 7.1.1 Mthodes de dfinition des exigences l'origine d'une exigence se trouve une ide ou un concept, qui est la rponse la perception d'une menace la scurit ou la part de march, l'entre en vigueur d'une loi ou d'un rglement, un dsir de crer un systme ou processus nouveau ou un souci d'amlioration, au besoin de remplacer un systme existant, ou un autre besoin rel ou peru. Bien que cette ide ou ce concept puisse maner d'un seul individu, l'ensemble d'exigences sera bien meilleur s'il rsulte de la mise en commun et du dveloppement d'ides au sein d'un groupe. Il existe de nombreuses mthodes qui permettent de dterminer des exigences. Parmi celles-ci : a) les ateliers structurs ; b) les sances de remue-mninges (brainstorming) ou de rsolution de problme ; c) les entrevues ; d) les sondages et questionnaires ; e) l'observation des rgimes de travail (ex. : tude des temps et mouvements) ; f) l'observation de l'environnement organisationnel et politique du systme (ex. : Sociogramme) ; g) l'examen de la documentation technique ; h) l'analyse du march ; i) l'valuation de systmes concurrents ; j) la rtroingnierie ; k) les simulations ; l) le prototypage ; m) la rfrenciation des processus et systmes.
16
7.1.2 Interaction entre le client et l'analyste Lorsqu'un analyste est engag pour travailler avec le client, il est essentiel d'tablir un processus efficace d'interaction entre les deux parties. cette fin, chaque intervenant doit comprendre qu'il a une responsabilit pdagogique vis--vis de l'autre, et que les exigences doivent tre le fruit de leur collaboration. 7.1.2.1 Formation mutuelle Il est impratif que la formation soit bidirectionnelle. L'analyste doit tout d'abord apprendre connatre l'environnement, les systmes existants (le cas chant) et les exigences du client. Chacune des parties doit consacrer le temps et l'nergie ncessaire pour faciliter cet apprentissage. De son ct, le client peut ncessiter une certaine formation de la part de l'analyste, lors de la dfinition et de la spcification des exigences. En outre, l'analyste peut avoir instruire le client sur les exigences en tant que telles, et faire profiter les exigences de son exprience. 7.1.2.2 Dfinition conjointe des exigences Le client et l'analyste peuvent interagir de plusieurs manires dans la dfinition des exigences. Par exemple, l'analyste peut simplement raliser des entrevues dans le but de solliciter des suggestions, puis organiser et prsenter les exigences au client pour que celui-ci les tudie. L'exprience de l'analyste est un facteur majeur, mais elle ne doit en aucune manire biaiser ou attnuer la porte des interventions du client. Durant la collaboration, les principaux objectifs de l'analyste doivent tre de solliciter et d'organiser les exigences dduites des besoins du client. Il ne doit ajouter des exigences partir de sa propre exprience ou de solutions prcdemment dfinies que lorsque ces exigences ont t oublies par le client, quand elles ajoutent nettement de la valeur pour celui-ci et si elles ont t approuves par ce mme client. Il est galement possible que du personnel du client ait participer des ateliers avec l'analyste. Ces ateliers, gnralement dirigs par l'analyste, peuvent donner lieu de nombreuses sances de remuemninges et de dfinition interactive d'exigences. Leurs rsultats sont ensuite documents par ce mme analyste. Pour une coopration plus troite, le client peut avoir intervenir encore plus directement dans la dfinition des exigences. Le personnel du client peut alors participer cette opration un point tel qu'il devient aussi auteur de la SES. Quelle que soit la mthode utilise, l'objectif du client et de l'analyste est de dfinir les exigences, aprs tre parvenus un consensus et une comprhension commune de celles-ci. Les exigences doivent pouvoir tre reprsentes de manire homogne sous la forme d'une SES, la satisfaction du client.
7.2 Constuire une exigence bien forme

Au cours de cette sous-tape, l'analyste est charg : a) de s'assurer que chaque exigence est une dclaration des besoins (capacit, contraintes) ncessaire, courte et dfinitive ;
b) de dfinir les conditions adquates (mesures quantitatives ou qualitatives) pour chaque exigence et viter les termes tels que rsistant ou l'chelle de l'industrie ; c) d'viter les piges relatifs aux exigences (voir sous-section 6.4) ;
17
d) de s'assurer de la lisibilit des exigences, c'est--dire qu'elles respectent les principes suivants : 1) mots, phrases et concepts simples, 2) structure et relations uniformes, 3) dfinition de mots, symboles et notations uniques, 4) utilisation d'un langage et d'une symbologie grammaticalement correctes ; e) de s'assurer de la testabilit de l'exigence ;
Voici un exemple de construction d'une exigence bien forme partir de l'nonc initial du client. Cet nonc, Transporter des gens entre Los Angeles et New York , exprime une exigence brute et servira de base l'exigence bien forme. Le client fournit galement un autre renseignement : la vitesse ne doit pas dpasser 300 km/h et la vitesse de croisire doit tre de 200 km/h . Ces conditions et contraintes peuvent ensuite tre appliques l'exigence brute dont les attributs sont : Capacit : Transporter des gens entre Los Angeles et New York Condition : Vitesse de croisire de 200 km/h Contrainte : Vitesse maximale de 300 km/h Exigence bien forme : Ce systme doit transporter des gens entre Los Angeles et New York, une vitesse de croisire optimale de 200 km/h et une vitesse maximale de 300 km/h. Une capacit peut tre associe plusieurs conditions et contraintes. Cependant, l'ajout de conditions ou de contraintes une capacit peut ncessiter la dfinition de nouvelles exigences bien formes.
7.3 Structurer les exigences

Au cours de ce sous-processus, l'analyste ajoute une structure l'ensemble d'exigences en les reliant les unes aux autres, selon une certaine mthode de dfinition comparative. Il est possible d'automatiser certaines tches de ce processus. Cette tape se caractrise par les activits suivantes : recherche de modles autour desquels regrouper les exigences ; utilisation de l'exprience et du jugement comme approches techniques adquates ; utilisation de la crativit et de l'intuition pour gnrer des approches de rechange, et pour tablir un ordre de priorit des exigences, selon les renseignements fournis par le client ; dfinition des proprits des exigences ; dfinition des attributs des exigences.
Il est possible d'allouer un attribut chaque exigence bien forme. Par exemple : <identification> = 2.1.3.6 <priorit> = haute <criticit> = basse <faisabilit> = haute <risque> = moyen <source> = client <type> = rendement
L'organisation des spcifications peut suivre divers plans. La structure la plus souvent utilise est le regroupement hirarchique des exigences selon la capacit, dans lequel les capacits plus gnrales sont dcomposes en exigences subordonnes. Il est galement possible d'utiliser des liens de rseau (ex. : Liens hypertextes), qui montrent la relation entre les exigences du niveau infrieur. Quel que soit le plan utilis,
18
la SES doit toujours faire tat des relations entre les exigences. Le type de la relation dpend des mthodes, techniques et outils utiliss pour recueillir, enregistrer et stocker les exigences. Parmi les relations qui peuvent tre indiques dans une SES, se trouvent les dpendances hirarchiques suivantes : a) c) vnements ; objets physiques ou abstraits ;
b) information/donnes ; d) fonctions.
7.4 Prsenter les exigences

Au cours de ce sous-processus, l'analyste dtermine, en collaboration avec le client, les meilleurs moyens de communiquer les exigences aux personnes devant comprendre, tudier, accepter ou utiliser la SES. Une reprsentation unique de la SES ne convient pas toujours, car a) les culture et langage du client tant souvent diffrents de ceux de la communaut technique, il est parfois ncessaire de prsenter diffremment les exigences selon le destinataire ; certaines mthodes de reprsentation ne facilitent pas la prsentation des interactions ;
b) certaines reprsentations rendent difficile l'extraction d'une information particulire ; c) d) certaines reprsentations permettent difficilement de relier une information situe un endroit une information situe ailleurs dans le document. Par consquent, il est important que l'analyste dtermine, toujours en association avec le client, les meilleurs moyens de communiquer les exigences aux personnes devant comprendre, tudier, accepter ou utiliser la SES. cette fin, il doit concevoir diverses reprsentations de la SES. Ces reprsentations ne doivent pas tre tenues jour sparment ; elles doivent tre drives et gnres partir de la SES. Par exemple, il peut tre ncessaire de produire un document de prsentation l'intention de la direction du client, qui contienne un commentaire rdactionnel, ainsi qu'une slection d'exigences du niveau suprieur. Le responsable de l'acceptation des exigences pour le client se verra, lui, remettre un document davantage dtaill, comprenant des modles formels. Un jeu complet de modles formels sera, quant lui, mieux adapt aux quipes de conception. Le recours des outils automatiss pour la tenue jour de la SES et la production des diverses reprsentations en amliorera l'efficacit. 7.4.1 Modes de reprsentation Il est possible d'obtenir l'expos des exigences correspondant le mieux aux besoins des destinataires grce l'un des modes de reprsentation suivants ou d'une combinaison d'entre eux : Textuel 1) Papier 2) lectronique b) Modle 1) Physique 2) Symbolique 3) Graphique 4) Prototype La rdaction des exigences se poursuit gnralement au-del de l'approbation de la SES. Dans le cas de systmes volumineux et complexes, les probabilits sont fortes pour que la version de SES initialement approuve contienne des omissions ou des distorsions. De plus, de nombreux systmes voluent en raison de l'ajout de nouvelles caractristiques. Il faut alors reprendre le processus, afin de corriger les erreurs de dpart ou d'insrer de nouvelles exigences, dans le but d'amliorer le systme. Il est essentiel de contrler de manire formelle la SES pour grer les modifications qui y sont apportes. a)
19
Annexe A
(informative)
Sommaire de la spcification dexigences de systme

Ce guide reconnat et soutient une large varit de mthodes et de mdias de communication des exigences, dont le texte et les modles. Ce sommaire a pour objectif d'aider le lecteur se concentrer sur le contenu technique de la SES (voir la norme IEEE 1220-1998 pour les exigences relatives l'laboration d'une SES). Il est possible d'largir ou de rduire le contenu destin au client ou la communaut technique. Les reprsentations d'une SES sont par consquent nombreuses et celle qui suit n'en est qu'un exemple.
Sommaire d'une SES Table des matires Liste des figures Liste des tableaux 1. Introduction 1.1. 1.2. 1.3. 1.4. 1.5. 2. Objectif Porte Dfinitions, acronymes et abrviations Rfrences Prsentation du systme
Description gnrale 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8. Contexte Modes et tats Principales capacits Principales conditions Principales contraintes Caractristiques des utilisateurs Hypothses et dpendances Scnarios d'exploitation
3.
Capacits, conditions et contraintes REMARQUE : Chaque capacit, condition et contrainte doit contenir des dispositions relatives au comportement, au traitement des exceptions, la fabricabilit et au dploiement du systme. 3.1. Physiques 3.1.1. Construction 3.1.2. Durabilit 3.1.3. Adaptabilit 3.1.4. Conditions ambiantes Caractristiques de rendement Scurit Gestion de l'information Exploitation 3.5.1. Ergonomie 3.5.2. Maintenabilit 3.5.3. Fiabilit Politiques et rglementation Maintien du cycle de vie
3.2. 3.3. 3.4. 3.5.
3.6. 3.7. 4.
Interfaces
20
Explications Explication des lments qui pourraient ne pas tre suffisamment explicites : 1.2 Porte Cette sous-section permet : a) b) c) d'identifier le nom du systme produire ; de se rfrer et prsenter les rsultats de l'analyse pralable des besoins, sous la forme d'un nonc court et structur des problmes du client. Expliquer ce que le systme fera et ne fera pas pour rpondre ces besoins ; de dcrire l'application du systme dfini. En particulier, dcrire le plus prcisment possible les principaux avantages et objectifs associs.
2.1 Contexte Cette sous-section comporte les schmas et descriptions qui permettent de prsenter le contexte dans lequel se retrouvera le systme, et de dfinir les interfaces significatives avec les systmes extrieurs. 2.2 Modes et tats Si le systme peut exister sous plusieurs modes et tats, cette sous-section doit en prsenter une description et, le cas chant, l'appuyer par des schmas. 2.3 Principales capacits Cette sous-section prsente des schmas et un expos qui illustrent les regroupements des principales capacits des exigences. 2.6 Caractristiques des utilisateurs Cette sous-section dfinit tous les types d'utilisateurs du systme (selon la fonction, l'emplacement et le type de dispositif), le nombre d'utilisateurs de chaque groupe et les caractristiques de l'utilisation qu'ils font du systme. 2.8 Scnarios d'exploitation Cette sous-section comporte des exemples descriptifs de la manire dont le systme sera utilis. 3. Capacits, conditions et contraintes 3.1 Physiques 3.1.1 Construction Les caractristiques de l'environnement (mcanique, lectrique, chimique) dans lequel le systme sera install sont indiques dans cet article. Peuvent, par exemple, tre spcifis : les limites de poids, les moments d'inertie, les limitations de dimensions et de volume, l'espace rserv l'quipage, la disposition du poste de commande, le mode d'entre, le mode de sortie et l'accs pour l'entretien. Il est galement ncessaire d'noncer les exigences relatives aux matriaux utiliser pour l'article ou le service couvert par cette spcification. Tout comme les exigences relies aux plaques signaltiques et marquages, l'interchangeabilit de l'quipement, et l'excution du travail. 3.1.3 Adaptabilit Cet article doit mentionner la croissance, l'expansion, la capacit et la contraction. Par exemple, s'il est impratif que le systme soit prvu pour l'augmentation de la largeur de bande ncessaire au rseau, il doit tre spcifi que la baie comprendra des fentes supplmentaires, destines recevoir les cartes de rseau qui seront ajoutes au fur et mesure de l'accroissement de la demande.
21
3.1.4 Conditions ambiantes Cet article dcrit les conditions ambiantes que le systme rencontrera. En particulier, le milieu naturel (vent, pluie, temprature), le milieu induit (mouvement, chocs, bruits) et l'environnement lectromagntique. 3.2 Caractristiques de rendement Cet article sert mettre en vidence les conditions essentielles de rendement et les capacits associes. De faon gnrale, il s'agit de : a) b) Actions ou modifications dynamiques (taux, vitesses, mouvements, niveaux de bruit, etc.) ; Critres quantitatifs relatifs la capacit d'endurance de l'quipement, qui rpond aux besoins de l'utilisateur, dans les conditions environnementales et autres stipules. Ces critres (ex. : la dure de vie minimum prvue) indiquent la dure de session oprationnelle requise et le taux d'utilisation planifi ; Exigences de rendement des phases et modes oprationnels.
c)
3.3 Scurit Les exigences de scurit, qui concernent l'installation hbergeant le systme, et les exigences de scurit oprationnelle apparaissent dans cette sous-section. Il peut s'agir, par exemple, de la spcification des exigences de scurit et de confidentialit, dont les limitations d'accs au systme (procdures de connexion et mot de passe), et les mthodes de protection et de rcupration des donnes. Ces exigences peuvent inclure les dispositifs qui permettraient de protger le systme en cas d'accs, d'utilisation, de modification, de destruction ou de divulgation accidentel ou malveillant. Elles devraient comprendre, particulirement dans le cas d'un systme intgr dont la scurit est un lment essentiel, un journal ou un historique des donnes distribu, l'attribution de certaines fonctions diffrents sous-systmes ou la restriction des communications entre certaines zones du systme. 3.5.1 Ergonomie Cet article indique les documents associs et spcifie les exigences spciales et uniques (contraintes relatives l'attribution de fonctions aux membres du personnel et aux communications, interactions personnel-quipement, etc.). Elle devrait galement inclure les zones, postes et quipements spcifiques, pour lesquels une attention trs particulire doit tre porte l'ergonomie, en raison de la sensibilit de l'opration ou de la criticit de la tche (c.--d. les zones o l'effet d'une erreur humaine serait particulirement nfaste). 3.5.2 Maintenabilit Cet article spcifie les exigences quantitatives en matire de facilit de maintenance. Ces exigences s'appliquent aux oprations d'entretien excutes dans l'environnement de maintenance et de soutien prvu. Elles doivent tre nonces en termes quantitatifs, par exemple : a) b) c) d) Temps (temps d'indisponibilit moyen et maximal, temps de raction, temps de maintenance, temps de rparation moyen et maximal, temps moyen entre deux oprations de maintenance, etc.) ; Taux (heures-personnel d'entretien par opration de maintenance spcifique, taux de disponibilit, temps de maintenance par heure de fonctionnement, frquence de la maintenance prventive, etc.) ; Complexit de maintenance (nombre de personnes et niveau de comptence, diversit d'quipements de soutien, etc.) ; Indices d'oprations de maintenance (cots de maintenance par heure de fonctionnement, heures-personnel par rvision, etc.).
3.5.3 Fiabilit Cet article spcifie les exigences de fiabilit en termes quantitatifs, et dfinit les conditions pour lesquelles ces exigences doivent tre respectes. Il peut galement contenir le modle de rpartition des valeurs de fiabilit attribues aux fonctions du systme, afin qu'elles contribuent atteindre le niveau de fiabilit souhait.
22
3.6 Politiques et rglementation C'est ici que se trouvent dtailles les politiques organisationnelles qui touchent le fonctionnement ou le rendement du systme, ainsi que toute exigence rglementaire ou contrainte impose par les pratiques commerciales normales. Parmi ces exigences, le soutien multilingue, les politiques en matire de travail, la protection des renseignements personnels et la subordination un organisme de rglementation. Les critres de sant et scurit, dont les critres lmentaires de conception du systme et ceux relatifs aux caractristiques de l'quipement, les modes de fonctionnement et les facteurs environnementaux devraient apparatre ici. Cette sous-section devrait galement contenir les exigences relatives aux produits toxiques et au rayonnement lectromagntique. 3.7 Maintien du cycle de vie Cette sous-section prsente les oprations qui permettent la ralisation d'un systme de qualit, telles que l'tude, et la prise de mesures et leur analyse. 4. Interfaces Cette section contient la spcification des exigences en matire d'interfaces reliant les divers composants leurs capacits externes, dont les utilisateurs, et les systmes humains et autres. Les caractristiques des interfaces avec les systmes en dveloppement ou venir doivent galement tre incluses. Il est aussi ncessaire de prciser les interdpendances ou contraintes associes aux interfaces (protocoles de communication, dispositifs spciaux, normes, formats fixes, etc.), qui peuvent assurer un flux bidirectionnel d'information. Par souci de clart, il est conseill d'employer une reprsentation graphique des interfaces lorsque cela est ncessaire. REMARQUE : Ce sommaire n'inclut pas les catgories de capacits correspondant tous les domaines. Par exemple, il ne couvre pas les communications, le stockage, la distribution, les capteurs et l'instrumentation. En outre, le lecteur pourra, sa convenance, organiser diffremment les sections, sous-section et articles dcrits ci-dessus.
23
Annexe B
(informative)
Bibliographe
[B1] BLANCHARD, Benjamin S. System Engineering Management. Wiley-Interscience, 1991. [B2] BLANCHARD, Benjamin S. et Walter J. FABRYCSKY. Systems Engineering & Analysis. International Series and Industrial & Systmes Engineering, Prentice Hall, 1990. [B3] GAUSE, Donald C. et Gerald M. WEINBERG. Exploring Exigences: Quality Before Design. New York, Dorset House Publishing, 1989.
24
Annexe C
(informative)
Lignes directrices concernant la conformit avec la norme IEEE/EIA 12207.1-1997
C.1 Prsentation
Le Software Engineering Standards Committee (SESC) de l'IEEE Software Society a avalis une politique d'adoption des normes internationales. La norme internationale ISO/IEC 12207 Technologie de l'information - Processus du cycle de vie du logiciel a t publie en 1995. Cette norme tablit un cadre commun aux processus du cycle de vie des logiciels, avec une terminologie bien dfinie, auquel peut se reporter l'industrie du logiciel. En 1995, le SESC a valu la norme ISO/IEC 12207 et a dcid de l'adopter, afin qu'elle serve de base pour les processus du cycle de vie du Software Engineering Collection [Recueil de gnie logiciel, NDT] de l'IEEE. L'adaptation de cette norme ralise par l'IEEE s'intitule IEEE/EIA 12207.0-1996. Elle contient la norme ISO/IEC 12207 et les ajouts suivants : approche amliore de la conformit, objectifs des processus du cycle de vie, objectifs des donnes du cycle de vie et errata. La mise en application de la norme ISO/IEC 12207 dans l'IEEE inclut galement les documents suivants : IEEE/EIA 12207.1-1997 IEEE/EIA Guide for information technology - Software life cycle processes Life cycle data ; IEEE/EIA 12207.2-1997 IEEE/EIA Guide for information technology - Software life cycle processes Implementation considerations ; Ajouts 11 normes du SESC (c.--d. normes IEEE 730, 828, 829, 830, 1012, 1016, 1058, 1062, 1219, 1233 et 1362), pour tablir la corrlation entre les renseignements provenant des normes actuelles du SESC et les donnes issues de l'application de la norme IEEE/EIA 12207.1-1997.
REMARQUE : Bien que le document IEEE/EIA 12207.1-1997 soit en fait un guide, il contient galement des dispositions concernant son utilisation en tant que norme, avec des exigences de conformit particulires. Cette annexe considre le document 12207.1-1997 comme une norme.
Pour se conformer au prsent guide et au document IEEE/EIA 12207.1-1997, il est essentiel que l'utilisateur tudie et satisfasse aux exigences de donnes de ces deux normes. Lorsque le prsent guide est directement utilis comme rfrence, la conformit doit tre value en priorit par rapport cette norme uniquement. Lorsqu'il est utilis conjointement aux normes IEEE/EIA 12207.x, la rfrence de la conformit prioritaire est la norme IEEE/EIA 12207.x indique, sauf mention contraire.
C.1.1 Porte et objectif Le prsent guide et la norme IEEE/EIA 12207.1-1997 insrent tous deux les exigences dans le cadre d'une spcification dexigences de systme. Cette annexe explique donc la relation entre ces deux ensembles d'exigences, dans le but de permettre l'utilisateur charg de produire des documents conformes ces normes de mener bien sa mission.
25
C.2 Corrlation
Cette sous-section montre la relation entre le prsent guide et la norme IEEE/EIA 12207.0-1996, en ce qui a trait la terminologie, aux processus et aux donnes du cycle de vie. C.2.1 Corrlation en matire de terminologie Les termes cls du systme, des exigences et de la spcification sont formuls de manires similaires dans ce guide et dans la norme IEEE/EIA 12207.0-1996. La norme IEEE 1233-1998 apporte cependant un supplment de clarification de la smantique des exigences, grce au concept d'exigence bien forme. C.2.2 Corrlation en matire de processus Ce guide et la norme IEEE/EIA 12207.0-1996 emploient tous deux une approche oriente processus pour la dfinition de l'ensemble des exigences relatives un systme. La diffrence rside dans le fait que le prsent document se concentre sur l'laboration des exigences, alors que l'IEEE/EIA 12207.0-1996 propose une vue globale du cycle de vie. De plus, la norme 1233-1998 n'emploie pas pour les processus le modle d'activit et de tche de la norme IEEE/EIA 12207.0-1996. Elle prcise, par contre, les divers acteurs qui interviennent dans la dfinition et la mise en uvre d'une spcification dexigences de systme. Enfin, elle propose une description plus dtaille des lments qui entrent dans la prparation d'une spcification dexigences de systme. C.2.3 Corrlation en matire de donnes du cycle de vie d'une spcification dexigences de systme L'information relative une spcification dexigences de systme requise par ce guide et celle rclame par la norme IEEE/EIA 12207.1-1997 sont semblables. Il est donc raisonnable de penser qu'un mme document puisse respecter les deux normes. Enfin, ces deux guides utilisent une approche oriente processus pour dcrire le contenu d'une spcification dexigences de systme. C.2.4 Corrlation des autres donnes du cycle de vie entre les normes IEEE/EIA 12207.1-1997 et IEEE 1233-1998 Le tableau C.1 illustre la corrlation entre la norme IEEE/EIA 12207.1-1997 et ce guide, en ce qui a trait aux donnes du cycle de vie autres que la spcification dexigences de systme. L'information qu'il prsente intressera les utilisateurs des deux normes. Tableau C. 1 Corrlation des autres donnes du cycle de vie entre les normes IEEE/EIA 12207.11997 et IEEE 1233-1998
lment d'information Architecture du systme et description de l'allocation des exigences Dossier d'valuation des exigences de systme Paragraphe de la norme IEEE/EIA 12207.0-1996 5.3.3.1, 5.3.3.2 Type de documentation Description Sous-section de la norme IEEE/EIA 12207.1-1997 6.25 Sous-section de la norme IEEE 12331998 7.3
5.3.2.2
Dossier
6.6
6.0
C.3 Conformit d'un document

Les renseignements contenus dans cette sous-section partent du postulat qu'une spcification dexigences de systme conforme ce guide peut galement respecter la notion de conformit d'un document avec une
26
spcification dexigences de systme, prcise dans la norme IEEE/EIA 12207.1-1997, la condition qu'elle contienne l'information supplmentaire mentionne dans la troisime colonne des tableaux C.3 et C.4 de ce guide. Les exigences relatives la conformit d'un document sont rsumes en une seule ligne, dans le tableau 1 de la norme IEEE/EIA 12207.1-1997. Cette ligne est reprise dans le tableau C.2 du prsent guide. Tableau C.2 Sommaire des exigences relatives une spcification dexigences de systme, extrait du tableau 1 de la norme IEEE/EIA 12207.1-1997
lment d'information Spcification dexigences de systme Paragraphe de la norme IEEE/EIA 12207.0-1996 5.1.1.2, 5.3.2.1, 5.3.2.2 Type de documentation Spcification Sous-section de la norme IEEE/EIA 12207.1-1997 6.26
Rfrences Norme IEEE 1220-1998 Norme IEEE 1233- 1998 Norme EIA/IEEE J-016-1995, F.2.2 Norme MIL-961D Voir galement les normes ISO/IEC 5806, 5807, 6593, 8631, 8790 et 11411 pour les lignes directrices sur l'utilisation des notations.
Les exigences de conformit d'un document sont dcrites dans les articles suivants : L'article C.3.1 examine la conformit avec les exigences d'information indiques la colonne 2 du tableau C.2, tel que prcis aux paragraphes 5.1.1.2, 5.3.2.1 et 5.3.2.2 de la norme IEEE/EIA 12207.01996. L'article C.3.2 dcrit la conformit avec les lignes directrices en matire de contenu gnrique (le type de document), indiques la colonne 3 du tableau C.2, sous l'appellation spcification. Les lignes directrices en matire de contenu gnrique d'une spcification sont dcrites la sous-section 5.7 de la norme IEEE/EIA 12207.1-1997. L'article C.3.3 examine la conformit avec les exigences particulires relatives une spcification dexigences de systme, indiques la colonne 4 du tableau C.2, tel que prcis la sous-section 6.26 de la norme IEEE/EIA 12207.1-1997. L'article C.3.4 prsente la conformit avec les objectifs des donnes du cycle de vie mentionns l'annexe H de la norme IEEE/EIA 12207.0-1996, tel que dcrit la sous-section 4.2 de la norme IEEE/EIA 12207.1-1997.
C.3.1 Conformit avec les exigences d'information de la norme IEEE/EIA 12207.0-1996 Les exigences d'information pour une spcification dexigences de systme sont prcises aux paragraphes 5.1.1.2, 5.3.2.1 et 5.3.2.2 de la norme IEEE/EIA 12207.0-1996. La plupart d'entre elles sont tires de l'article 6.26.3 de l'IEEE/EIA 12207.1-1997, et sont galement traites l'article C.3.3. Les seules exceptions concernent les exigences de test, les normes de conformit, les procdures (requises au paragraphe 5.1.1.2 de l'IEEE/EIA 12207.0-1996) et les capacits (requises au paragraphe 5.3.2.1 de l'IEEE/EIA 12207.0-1996). Le prsent guide traite de faon extensive des capacits, permettant ainsi le respect de la norme IEEE/EIA 12207.0-1996. Bien que la spcification d'exigences de test, de normes de conformit et de procdures ne soit pas couverte dans la prsente cette norme, ces dernires constituent certainement des exigences supplmentaires auxquelles un document qui respecte ce guide doit satisfaire pour se conformer galement la norme IEEE/EIA 12207.0-1996. C.3.2 Conformit avec les lignes directrices gnrales en matire de contenu de la norme IEEE/EIA 12207.1-1997 Les lignes directrices gnrales en matire de contenu d'une spcification, tablies dans le document IEEE/EIA 12207.1-1997, sont prcises la sous-section 5.7. Pour tre dclare conforme, une spcification doit raliser l'objectif nonc l'article 5.7.1 et comprendre l'information indique l'article 5.7.2 de cette mme norme. Une spcification a pour objectif :
27
IEEE/EIA 12207.1-1997, article 5.7.1 : Objectif : Spcifier une fonction, un rendement ou un processus recherch (ex. : spcification d'exigences). Une spcification dexigences de systme qui respecte ce guide ralise cet objectif. Toute spcification conforme la norme IEEE/EIA 12207.1-1997 doit satisfaire aux exigences de contenu gnrique prcises l'article 5.7.2 de cette mme norme. Le tableau C.3 du prsent guide dresse la liste des lments de contenu gnrique et, le cas chant, indique la section de la norme IEEE 1233-1998 qui exige la mme information.
Tableau C.3 Couverture des exigences de spcification gnrique de la norme IEEE 1233-1998
Contenu gnrique de la norme IEEE/EIA 12207.1-1997 a) Date de publication et statut b) Porte c) Organisation responsable de la publication d) Rfrences e) Responsable de l'approbation Parties correspondantes de la norme IEEE 1233-1998, annexe A 1.2 Porte 1.4 Rfrences Ajouts aux exigences de la norme 1233-1998, annexe A La date de publication et le statut doivent tre indiqus. L'organisation responsable de la publication doit tre identifie. Le responsable de l'autorisation doit tre identifi.
f) Corps
2. 3.
4.
g) Consignes de livraison h) Exigences relatives l'assurance
Description gnrale Capacits, conditions et contraintes Interfaces
i) Conditions contrainte et caractristiques i) Glossaire j) Historique des modifications
2.4 Principales conditions 2.5 Principales contraintes 2.6 Caractristiques des utilisateurs 1.3 Dfinitions, acronymes et abrviations
Les consignes de livraison du client doivent tre indiques. Les exigences relatives l'assurance, fixes par le client, doivent tre indiques. Un historique des modifications apportes la spcification dexigences de systme doit tre fourni ou indiqu en rfrence.
C.3.3 Conformit avec les exigences de contenu spcifique de la norme IEEE/EIA 12207.1-1997 Les exigences de contenu spcifique pour une spcification dexigences de systme stipules dans la norme IEEE/EIA 12207.1-1997 sont prcises la sous-section 6.26. Pour qu'une spcification dexigences de systme soit dclare conforme, elle doit raliser l'objectif fix l'article 6.26.1 et comprendre l'information indique l'article 6.26.3 de cette mme norme. La spcification dexigences de systme a pour objectif : IEEE/EIA 12207.1-1997, article 6.26.1: Objectif : Prciser les exigences d'un systme ou soussystme et les mthodes employer pour s'assurer que chaque exigence a t respecte. La
28
spcification dexigences de systme sert de base la conception et au test d'admission d'un systme ou sous-systme. Une spcification dexigences de systme qui respecte ce guide, ainsi que les exigences supplmentaires mentionnes aux tableaux C.3 et C.4 de cette norme, ralise galement l'objectif fix. Une spcification dexigences de systme qui respecte la norme IEEE/EIA 12207.1-1997 doit satisfaire aux exigences de contenu spcifique prcises l'article 6.26.3 de cette mme norme. Le tableau C.4 de ce guide dresse la liste des lments de contenu spcifique et, le cas chant, indique la section de la norme IEEE 1233-1998 qui exige la mme information. Tableau C.4 Couverture des exigences de spcification spcifiques de la norme IEEE 1233-1998
Contenu spcifique de la norme IEEE/EIA 12207.1-1997 a) Information de spcification gnrique b) Identification et prsentation du systme c) tats et modes requis d) Exigences relatives aux fonctions et rendement. e) Exigences commerciales, ... exigences organisationnelles, ... et exigences de l'utilisateur f) Exigences relatives la sret exigences relatives la scurit, exigences relatives la confidentialit g) Exigences relatives l'ergonomie h) Exigences relatives l'exploitation exigences relatives la maintenance i) Exigences relatives aux interfaces externes j) Exigences relatives l'environnement k) Contraintes de conception et exigences relatives l'admissibilit l) Exigences relatives aux ressources informatiques l) (i) Exigences relatives au matriel informatique l) (ii) Exigences relatives au matriel informatique, y compris les exigences relatives l'utilisation l) (iii) Exigences relatives aux logiciels informatiques
Parties correspondantes de la norme IEEE 1233-1998, annexe A Voir tableau C.3 1.2 Porte 1.5 Prsentation du systme 2.2 Modes et tats 2.8 Scnarios oprationnels 3.2 Caractristiques de rendement 3.6 Politiques et rglementation 3.6 Politiques et rglementation 3.5.1 Ergonomie 3.6 Politiques et rglementation 3.3 Scurit 3.6 Politiques et rglementation 3.6 Politiques et rglementation 3.5.1 Ergonomie 3.5 Exploitation 3.7 Maintien du cycle de vie 4. Interfaces 3.1.4 Conditions ambiantes 3.6 Politiques et rglementation 2.5 Principales contraintes 3.6 Politiques et rglementation
Ajouts aux exigences de la norme 1233-1998, annexe A Les exigences relatives aux fonctions du systme doivent tre indiques. Les exigences relatives l'admissibilit du systme, fixes par le client, doivent tre indiques. Les exigences relatives au matriel informatique doivent tre indiques. Les exigences relatives aux ressources matrielles informatiques, y compris les exigences relatives l'utilisation, doivent tre indiques. Les exigences relatives aux logiciels informatiques doivent tre indiques.
3.2 Caractristiques de rendement
29
Contenu spcifique de la norme IEEE/EIA 12207.1-1997 1) (iv) Exigences relatives aux communications informatiques m) Caractristiques de qualit n) Exigences relatives aux donnes internes o) Exigences relatives aux donnes dpendantes de l'installation p) Exigences physiques q) Exigences relatives au personnel, exigences relatives la formation, et exigences logistiques r) Exigences relatives l'emballage
Parties correspondantes de la norme IEEE 1233-1998, annexe A
3.1 Physiques 3.5.1 Ergonomie 3.5.2 Maintenabilit
s) Priorit et criticit des exigences t) Motifs
Ajouts aux exigences de la norme 1233-1998, annexe A Les exigences relatives aux communications informatiques doivent tre indiques. Les caractristiques de qualit doivent tre indiques. Les exigences relatives aux donnes internes doivent tre indiques. Les exigences relatives aux donnes dpendantes de l'installation doivent tre indiques. Les exigences relatives la formation doivent tre indiques. Les exigences relatives l'emballage, fixes par le client, doivent tre indique. La priorit et la criticit des exigences doivent tre stipules. Le motif des exigences de systme doit tre prcis.
C.3.4 Conformit avec les objectifs des donnes du cycle de vie S'ajoutant aux exigences de contenu, les donnes du cycle de vie doivent tre gres conformment aux objectifs noncs l'annexe H de la norme IEEE/EIA 12207.0-1996.
REMARQUE : Les lments d'information couverts par ce guide comprennent les plans et dispositions pour la cration de donnes de cycle de vie de logiciel rattaches au type de base donnes d'exigences (requirements data), la sous-section H.4 de la norme IEEE/EIA 12207.0-1996. Cette section fournit les donnes d'exigences suivantes : fonctionnalit prvue, contexte oprationnel, contraintes et attentes de rendement, base de test de qualification et justification des principales dcisions.
C.4 Conclusion
L'analyse dveloppe dans cette annexe suggre que toute spcification dexigences de systme rdige l'aide du prsent guide, et qui respecte les exigences de contenu prcises aux tableaux C.3 et C.4, est galement conforme aux exigences d'une spcification dexigences de systme nonces dans le document IEEE/EIA 12207.1-1997. En outre, dans un but de conformit cette mme norme IEEE/EIA 12207.11997, une spcification dexigences de systme doit permettre de raliser les objectifs de donnes de cycle de vie stipuls l'annexe H de la norme IEEE/EIA 12207.0-1996.
30

Guide IEEE Pour La Specification

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Guide IEEE Pour La Specification

Загружено:

Авторское право:

Доступные форматы

Norme IEEE 1233, dition 1998

(comprend la norme IEEE 1233-1996 et la norme IEEE 1233a-1998)

Guide de l'IEEE pour la Spcification dExigences de Systme

Software Engineering Standards Committee de l'IEEE Computer Society

IEEE-SA Standards Board

Copyright IEEE. Tous droits rservs

William N. Sabor, secrtaire

Ont particip au vote sur la norme IEEE 1233-1996 :

Copyright IEEE. Tous droits rservs

Ont particip au vote sur la norme IEEE 1233a-1998:

Copyright IEEE. Tous droits rservs

Copyright IEEE. Tous droits rservs

Table des matires

Guide de l'IEEE pour la Spcification dExigences de Systme

Norme IEEE 1233, dition 1998

Guide IEEE pour la spcification dexigences de systme

Norme IEEE 1233, dition 1998

Guide IEEE pour la spcification dexigences de systme

Copyright IEEE. Tous droits rservs

Norme IEEE 1233, dition 1998

Guide IEEE pour la spcification dexigences de systme

4. Spcification dexigences de systme

Copyright IEEE. Tous droits rservs

Norme IEEE 1233, dition 1998

Guide IEEE pour la spcification dexigences de systme

Copyright IEEE. Tous droits rservs

Norme IEEE 1233, dition 1998

Guide IEEE pour la spcification dexigences de systme

4.4 Utilisation prvue

Copyright IEEE. Tous droits rservs

Norme IEEE 1233, dition 1998

Guide IEEE pour la spcification dexigences de systme

4.6 Dynamique des exigences de systme

5. Prsentation du processus d'laboration de la SES

Figure 1 Contexte d'laboration d'une SES

Copyright IEEE. Tous droits rservs

Norme IEEE 1233, dition 1998

Guide IEEE pour la spcification dexigences de systme

Copyright IEEE. Tous droits rservs

Norme IEEE 1233, dition 1998

Guide IEEE pour la spcification dexigences de systme

Normes et politiques techniques ; Facteurs organisationnels ; Acteurs physiques.

Copyright IEEE. Tous droits rservs

Norme IEEE 1233, dition 1998

Guide IEEE pour la spcification dexigences de systme

5.3 Communaut technique

Norme IEEE 1233, dition 1998

Guide IEEE pour la spcification dexigences de systme

6. Exigences bien formes

6.1 Dfinition d'une exigence bien forme

Copyright IEEE. Tous droits rservs

Norme IEEE 1233, dition 1998

Guide IEEE pour la spcification dexigences de systme

6.2 Proprits d'une exigence

Copyright IEEE. Tous droits rservs

Norme IEEE 1233, dition 1998

Guide IEEE pour la spcification dexigences de systme

Copyright IEEE. Tous droits rservs

Norme IEEE 1233, dition 1998

Guide IEEE pour la spcification dexigences de systme

Copyright IEEE. Tous droits rservs

Norme IEEE 1233, dition 1998

Guide IEEE pour la spcification dexigences de systme

DONNES DES EXIGENCES BIEN FORMES EXIGENCES STRUCTURES PRSENTER LA SES