Spécification des exigences à l’aide des normes IEEE 830 et IEEE 29148 SEG3501 (Automne 2017) Spécification des exigences à l’aide des normes IEEE 830 et IEEE 29148 Daniel Amyot, Université d’Ottawa Avec du matériel des normes: IEEE 830-1998, ISO/IEC 12207, ISE/IEC/IEEE 29148:2011
Aperçu de la présentation Document de spécification d’exigences Norme IEEE 830-1998 Relation entre IEEE 830 et ISO/IEC 12207 Norme ISO/IEC/IEEE 29148:2011
Document de spécification (1) Décrit clairement et précisément les exigences essentielles (fonctions, performance, contraintes de conception, attributs de qualité) du système/logiciel et de ses interfaces externes. Et ainsi les limites du système/logiciel Chaque exigence ainsi décrite doit être réalisable et vérifiable objectivement (par inspection, démonstration, analyse, ou test) Base pour entente contractuelle entre fournisseurs et clients. Élaborée à partir des notes d’élicitation
Document de spécification (2) Les spécifications visent des auditoires variés: Clients et utilisateurs pour contrats, négociation, validation… Analystes en systèmes/exigences Développeurs et programmeurs pour l’implantation Testeurs pour s’assurer de la qualité Gestionnaires de projets pour mesurer et contrôler le projet Divers niveaux de détail et de formalité sont requis pour chaque auditoire Différentes lignes directrices pour gabarits de spécification d’exigences existent Par exemple, IEEE 830 et ISO/IEC/IEEE 29148:2011
À propos des normes (standards)… A standard is a “Set of mandatory requirements established by consensus and maintained by a recognized body to prescribe a disciplined uniform approach or specify a product, that is, mandatory conventions and practices” [ISO/IEC/IEEE 24765]
Norme IEEE 830-1998 830: « IEEE Recommended Practice for Software Requirements Specifications » Approches recommandées pour la spécification d’exigences pour logiciels SEL, ou SRS en anglais Plusieurs exemples de gabarits pour SEL
Norme IEEE 830-1998: Objectifs Aider à définir ce que les clients du logiciel cherchent à obtenir. Aider les fournisseurs du logiciel à comprendre exactement ce que les clients demandent. Aider les participants à: Développer un gabarit (format et le contenu) pour la spécification des exigences logicielles (SRS) dans leurs propres organisations. Développer des documents additionnels tels que liste de vérification et manuels de rédaction.
Norme IEEE 830: Bénéfices attendus Établir une base pour entente entre clients et fournisseurs sur ce que le logiciel doit accomplir Réduire le temps de développement En forçant à considérer rigoureusement les exigences tôt dans le processus (moins de recodage/re-testage) Donner une base pour estimés des coûts et du temps requis Donner une base pour la validation et la vérification Faciliter le transfert du logiciel Vers de nouveaux utilisateurs ou de nouvelles machines Servir de base aux demandes d’améliorations
Considérations pour SRS: section 4 de IEEE 830 Nature (buts) du SRS Fonctionnalités, interfaces, performance, qualités, contraintes Environnement du SRS Caractéristiques d’un bon SRS Généralisation des bonnes caractéristiques individuelles des exigences déjà vues à un niveau du document d’exigences Évolution du SRS Implique un processus de gestion du changement Prototypage Inclusion d’aspects de design dans un SRS À éviter, se concentrer sur le comportement externe Inclusion d’aspects de gestion de projet dans un SRS À éviter, se concentrer sur le produit et non le processus de production (un autre document sur le projet doit traiter de ce dernier aspect)
SRS: section 5 de IEEE 830 Introduction Description générale du produit logiciel Exigences spécifiques (description détaillée) Informations additionnelles, au besoin Version française d’un gabarit IEEE 830: http://www.site.uottawa.ca/~damyot/seg3501/notes/IEEE830.html L’annexe A de IEEE 830 présente différentes façons de structurer les exigences spécifiques: Par modes, classes d’utilisateurs, concepts, services, stimuli et organisations.
ISO/IEC 12207:2008 Software Life Cycle Processes
Relation entre IEEE 830 et ISO/IEC 12207 12207: « Software life cycle processes » Aussi identifié IEEE/EIA 12207 Définit un cadre commun pour les processus de cycle de vie du logiciel IEEE 830-1998 et IEEE/EIA 12207.1-2008 placent tous deux des exigences sur les documents décrivant les exigences logicielles L’annexe B de IEEE 830 explique la relation entre les deux ensembles d’exigences afin que ceux qui le désirent puissent produire des documents qui se conforment aux deux normes en même temps. Ce type de conformité peut être requis par le client lors d’un appel d’offres.
Correspondance au niveau générique Note: Le tableau B.3, plus détaillé, montre la correspondance au niveau des types d’exigences
ISO/IEC/IEEE 29148:2011 ISO/IEC/IEEE 29148:2011: Ingénierie des systèmes et du logiciel — Processus du cycle de vie — Ingénierie des exigences http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6146379 Cette norme internationale fournit un traitement unifié des processus et produits concernés par l’ingénierie des exigences tout au long du cycle de vie des systèmes et des logiciels. Harmonise IEEE 830, SWEBOK, et 7 autres normes. Met davantage l'accent sur les caractéristiques des bonnes exigences, les activités et les processus d’I.E., les opérations (et les contextes de fonctionnement), et les éléments d'information (y compris leurs structures) tels que la spécification des exigences pour les parties prenantes, les systèmes et les logiciels. Se conforme à ISO/IEC 15288 et ISO/IEC 12207
Stakeholder Requirements Specification (StRS)
System Requirements Specification (SyRS)
Software Requirements Specification (SRS) Verification: Cette section présente les approches de vérification et les méthodes prévues pour qualifier le logiciel. Les éléments d'information pour la vérification sont en général fournis de manière parallèle aux éléments d'information de la section 3.
Formulations (patterns)… en français! D’Hydro-Québec (mes remerciements à René Bujold) Fichier Excel avec des centaines d’exemples basés sur la structure IEEE 830, incluant les exigences non-fonctionnelles
Quelques outils pour vous aider… Requirements Authoring Tool (RAT) Requirements Quality Analyzer (RQA) QVscribe Specification Analysis Tool (SAT) RAVEN Article intéressant: A. Smit, R. Halligan: An evaluation of requirements writing templates and tools. 12th INCOSE SA Systems Engineering Conference, 2016.
Quiz Est-ce que les normes IEEE 830 et IEEE 29148 offrent des gabarits standards pour spécifications d’exigences? À qui sont destinés les documents de spécification d’exigences? Pouvez-vous nommer deux types de spécifications d’exigences? Pouvez-vous nommer trois bénéfices de l’utilisation d’une norme telle que ISO/IEC/IEEE 29148:2011? Pouvez-vous penser à des problèmes potentiels concernant l’utilisation de telles normes?
ISO JTC1-SC7 Standards and Technical Reports http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_tc_browse.htm?commid=45086
Pourquoi les VSEs n’utilisent-elles pas de normes? VSE = very small entities: enterprise, government, or not-for-profit organizations; departments; or projects with up to people who develop systems with hardware and software components and/or software products. * Difficult, Bureaucratic, not enough guidance. C.Y. Laporte and R.V. O'Connor: Software Engineering Standards for Very Small Entities: Accomplishments and Overview. IEEE Computer, August 2016, 84-87