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

… avant tout un outil de communication et un brin de 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;
… un travail produit 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 » (=« Requirements » );
… des exigences au cœur des projets, qu’elle soient fonctionnelles (ce que le système doit faire, constituant par exemple un backlog de produit agile) 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 ?

Au final, c’est ensemble est aujourd’hui intégré en phase de cadrage de projet

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. Définir puis partager la Vision du produit est donc cruciale.
La vision synthétique est un excellent point de départ :

POUR (public concerné par le produit)

QUI SOUHAITENT (formulation du besoin des cibles)

NOTRE PRODUIT EST (ce qu’est le produit)

QUI (le bénéfice majeur, l’utilité de la solution)

A LA DIFFERENCE DE (pratique actuelle, concurrence)

PERMET DE (éléments différentiateurs majeurs)

Elle peut se prolonger dans de petits docs. à la structure souvent similaire :

Plan d’un Cahier Des Charges de Site Web

Plan de Vision Document (Wiegers)

L’entretien et l’observation sont  les sources d’informations principales mais d’autres techniques peuvent aussi être utilisées : questionnaires, focus group, observation, tests utilisateurs exploratoires, benchmarking, étude de l’existant, de la 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 organiserclassifying the voice of the customer », selon Karl Wiegers ), discours qui peut prendre différentes formes : l’input des utilisateurs (« 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.
Même si ce n’est pas forcément leur objectif initial, les user stories et les éléments de conversation les accompagnant (conditions de satisfaction, exemple, wireframes…) constituent un moyen particulièrement efficace de spécifier le besoin de manière collaborative.

Les formats de spécification plus anciens se recoupent (IEEE, RUP, Volere …). Ils  intègrent généralement en leur sein une partie Exigences fonctionnelles. Cette intégration qui se concrétise souvent sous forme de renvois vers d’autres formats ou document  permet à cette documentation générale de rester synthétique, ouverte et abordable.

Exemple SRS Volere

Exemple SRS IEEE 830

« Use cases et user stories », livrables d’ergonomie, diagrammes divers et variés … sont dans tous les cas de précieuses techniques pour spécifier les besoins.
Sur le plan fonctionnel et opérationnel, l’utilisation de ces user stories ou la construction progressive de Cas d’utilisation (« use cases »), (Acteur -> But -> Déclencheur et scénario nominal -> Extensions), le tout combiné aux spécifications IHM (wireframes ),  sont désormais des standards, et des avancées majeures dans une vision toujours plus utilisateur et toujours plus orientée BUT.

Il s’agit avant tout ici d’un travail d’Equipe même si les spécialistes de l’Experience Utilisateur, de l’Analyse et des Tests apportent une vraie plus value.

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 ou User Story, 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. Au final, ils sont plus complexes que véritablement utiles, car 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 ou tout simplement le BACKLOG de PRODUIT qu’ils soient manuels ou automatisés vont 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 et surtout prioriser, suivre les exigences sont des tâches inhérentes à cette activité : il s’agit d’une grosse part du travail de l’analyste ou plus globalement du Product Owner.

Retrouvez des références bibliographiques sur ces questions dans la rubrique « Quelques livres« .

Si vous désirez en savoir plus sur notre approche du cadrage agile avec Eveil Agile® Projet, n’hésitez pas à nous contacter par mail à l’adresse suivante : jcgrosjean@gmail.com ou par téléphone au 06 20 98 58 40.