Spécifications, Exigences et Cahier des charges : Quoi, Comment ?

Posté par jc-Qualitystreet le 2 juillet 2007

… de la documentation (juste ce qu’il faut pour rester Agile) visant à rendre compte de l’adéquation de ce qui est livré avec ce qui est attendu, voulu par le Client et les Utilisateurs finaux;
… une documentation produite dans le cadre du Recueil & Expression, de la Spécification et de la Gestion du besoin, composantes principales de ce qu’on appelle « l’Ingénierie des exigences » (= la discipline « Requirements » du Processus Unifié);
… des exigences au cœur des projets, qu’elle soient fonctionnelles (ce que le système doit faire) ou non fonctionnelles (qualité du produit, principalement les attributs issus de la norme ISO 9126), présentes au travers de ces trois activités essentielles.
… et de nouveaux champs d’intervention pour l’Ergonome Agile comme je le décris dans le précédent billet de cette série: Spécifications, Exigences et Cahier des charges: Qui ? Quand ?

Recueillir & Exprimer les besoins

L’objectif est de fournir une vision claire du système à concevoir, d’offrir la définition et les limites du système, les fonctionnalités clés, les autres exigences et contraintes.
Les dénominations sont variées mais la structure de ces docs. est souvent similaire (le type d’application fera la différence):

Plan d’un Cahier Des Charges de Site Web

Plan de Vision Document (Wiegers)

L’entretien est la source d’informations principale mais d’autres techniques peuvent aussi être utilisées : questionnaires, focus group, observation, tests utilisateurs exploratoires, benchmarking, étude de la doc. (existant et concurrence), présentation de maquettes…
Le savoir-faire de l’ergonome dans la conduite de chacune de ces techniques est un véritable atout, notamment pour trier et organiser l’input des utilisateurs (« classifying the voice of the customer », selon Karl Wiegers ), discours qui peut prendre différentes formes : exigences Business, scénarios d’usage, règles de gestion, exigences fonctionnelles, attributs de qualité, contraintes, données, idées et solutions.
Ce premier tri nous servira à établir notre base d’exigences.

Spécifier les besoins

L’objectif est de détailler et de clarifier les besoins exprimés en analysant le fonctionnement du système de manière formelle et exploitable par les équipes de développement.
Encore une fois les formats se recoupent (IEEE, RUP, Volere …), et cherchent tous à intégrer en leur sein (partie Exigences fonctionnelles), les cas d’utilisation (”Use cases”) pour décrire la dimension fonctionnelle des applications.

Exemple SRS Volere

Exemple SRS IEEE 830

« Use cases et user stories », livrables d’ergonomie, diagrammes UML … sont de précieuses techniques pour spécifier les besoins.
Sur le plan fonctionnel, la construction progressive des Cas d’utilisation (« use cases »), (Acteur -> But -> Déclencheur et scénario nominal -> Extensions), l’un des principes du processus Unifié, ou l’utilisation des Histoires d’Utilisateurs (« user stories ») , le tout combiné aux spécifications IHM (Visio et les wireframes ; Une interface conviviale) sont désormais des standards, et des avancées majeures dans une vision toujours plus utilisateur et toujours plus orientée BUT.
L’ergonome est à ce stade INDISPENSABLE.

Gérer les exigences

Les objectifs de cette activité transversale sont de faciliter la reconnaissance et la compréhension du lien entre les exigences, de permettre leur priorisation, et surtout de tracer leur prise en charge dans le projet (tel composant est le fruit de tel UC, lui même issu de tel besoin, le tout testé dans tel cas de test); en somme, la vie d’une exigence aussi bien en amont qu’en aval de sa spécification.

Exemple d’une base d’exigences (RequisitePro)

Des outils spécialisés (Doors, Caliber-RM, Requisite Pro…) existent mais c’est surtout la prise de conscience de l’importance de cette activité qui est cruciale.
La gestion doit s’opérer de manière continue très tôt dans le projet : la base d’exigences qu’elle soit manuelle ou automatisée va servir de fil rouge au projet et de référence à l’ensemble des acteurs.
Lister & vérifier (selon ces huit critères : caractère correct, clair, sans ambiguïté, cohérent, complet, réaliste, pertinent, vérifiable et traçable), qualifier, valoriser & prioriser, suivre les exigences sont des tâches inhérentes à cette activité : il s’agit d’une grosse part du travail de l’analyste.
Pour terminer, quelques références sur le sujet:

• « Effective requirements practices » Ralph Young 2001
• « Mastering the requirements process » Suzanne Robertson, James Robertson 1999
• « Software requirements » Karl Wiegers 1999

Retrouvez d’autres références sur l’Ergonomie, le Processus Unifié et le Test Logiciel dans la rubrique “Quelques livres“.

Commentaires

Une réponse à “Spécifications, Exigences et Cahier des charges : Quoi, Comment ?”

1. Bujold dit :

   10 juin 2009 à 16 h 34 min

   Bonjour,

   Partage:

   Pour vos enseignants et étudiants, vous trouverez “une version française” des normes 830 et 1233 de IEEE sur le site web de l’École Polytechnique de Montréal (http://www.cours.polymtl.ca/log3410/liens/LIENS.php):

   - IEEE Std 830 (Pratique recommandée par IEEE pour la préparation de spécifications d’exigences de logiciel):
   http://www.cours.polymtl.ca/log3410/bibliographie/IEEE/Pratique_Recommandee_Par_IEEE_pour_la%20_Specification.pdf

   - IEEE Std 1233 (Guide de l’IEEE pour la Spécification d’Exigences de Système): http://www.cours.polymtl.ca/log3410/bibliographie/IEEE/Guide_IEEE_Pour_la_Specification.pdf

   Cordialement,

   René Bujold