3- Spécifications

Lors de cette phase, vous allez travailler sur la réalisation de livrables du projet. Vous vous appuierez sur les documents transmis de la phase d’analyse tel que le cahier des charges, le dossier technique, l’analyse fonctionnelle et les uses cases…

Une étape d’étude doit permettre de produire les spécifications fonctionnelles et techniques du projet. Les spécifications fonctionnelles vont consister à transformer la note de cadrage, le cahier des charges en description détaillées.
Comme lors de la phase d’analyse, il faut s’assure de la disponibilité des différents interlocuteurs. Sur des projets assez importants, le CP peut s’appuyer sur l’avis et la compétence de “Business analyst”. Lors de ces réunions, il faut faire parler un maximum les experts métiers. Attention à ne pas s’appuyer uniquement sur “Monsieur je sais tout” coté client. En effet certains responsables de service ou chef de projet ont tendance à vouloir se substituer aux utilisateurs finaux et à exprimer le besoin à leurs place! Il faut absolument faire comprendre au client qu’il faut faire participer des utilisateurs “clé” qui ont une très bonne connaissance du besoin. Il faut pendant les ateliers de spécification faire parler les utilisateurs dans le but de savoir:

  • Pourquoi une fonctionnalité doit être développée
  • Quelle est sa finalité?
  • Quelle est sa valeur ajoutée dans le métier ou service rendu?
  • Est-ce que cette fonctionnalité est essentielle?
  • Le besoin n’est-il pas couvert par une autre fonctionnalité?
  • Quelle est la priorité pour le client? Un niveau de prioristé doit être donné pour chaque fonctionnalité. Ceci permettra de faire des arbitrages notamment si une dérive est détectée.
  • Quelles sont les données en entrée? Quel est le résultat attendu?
  • Qui sont les différents intervenants en écriture, modification, suppression et lecture? Qui fait quoi?
  • Quel est le niveau de sécurité souhaité? Comment sécurisé l’application (texte, documents, images, médias …) ?

Il faut aussi commencer à se poser des questions sur l’ergonomie et le design de l’application. Selon les projets, il est biensure conseillé de faire intervenir des spécialistes en la matière. Parfois, l’ergonomie et le design général ont déjà été définis par une agence de design. Il faut faire attention à ce que le design reste dans le cadre des spécifications définies et du niveau de complexité décidé. Il n’est pas rare que la partie design viennent ajouter de la complexité non prévue aux développements. Le chef de projet MOE doit s’assurer que le design livré correspond au niveau de qualité / complexité prévu. Il doit pouvoir communiquer à la MOA les limitations et négocier le cas échéant une revue du design ou un supplément de jour de développement pour pouvoir prendre en compte des nouveaux points. Le CP MOE doit donc aussi valider ce design.

Personnellement j’aime bien réaliser ces spécifications sous forme de user story (histoire utilisateur ou scénario client). Les users stories doivent décrire de manière précise le fonctionnement d’un point de vue utilisateur. Idéalement il faut illustrer la user story (US) par exemple: décrire ce que fait l’utilisateur et le résultat attendu. Des US techniques peuvent aussi être décrites pour par exemple gérer les cas d’erreurs. L’ensemble des US peuvent être regroupés dans un document de spécifications appelé Story Board. La technique des US est inspirée des méthodologies agiles, mais peut être adaptée et parfaitement convenir dans le cadre des projets plus classiques.

La cinématique d’utilisation doit aussi être décrite. Le but est que la logique de l’application soit aussi bien comprise de la part du client, du chef de projet ou de l’équipe.

Exemple de user story

Comme un exemple vaut toujours mieux qu’un long discours, voici une illustration de ce que peut être une User Story :

User Story en tant que lecteur, je veux pouvoir noter un article que je lis.
Condition d’acceptation
  1. l’utilisateur doit pouvoir cliquer sur évaluation sous forme de 5 étoiles.
  2. L’utilisateur doit pouvoir sélectionner une demi-étoile.
  3. La note donnée doit être additionnée aux notes déjà données pour l’article.
  4. La moyenne des notes doit être visible sur la page de l’article.

Plusieurs scénarios alternatifs peuvent être décrits. Chacun de ces scénarios constituant une US indépendante.

Je préfère la méthode des users stories aux spécifications se limitant à décrire ce que doit faire le système. Il est à mon sens beaucoup plus facile de partager la compréhension des fonctionnalités entre les différents intervenants (client, CP, développeurs…) lorsque c’est rédigé de cette manière.

Pour les projets comportant un risque technique, technologique ou une incertainité, il faut penser à réaliser un POC (Proof Of Concept), une maquette fonctionnelle permettant de valider et de s’assurer de la faisabilité ou défricher certaines problématique techniques. Il est aussi utile de s’appuyer sur des experts techniques et des architectes pour vous aider à élucider certaines problématiques. Là aussi il faut faire attention à limiter l’imagination fertile de certains intervenants. Il s’agit de trouver une solution au problème posé tout en restant réaliste. Il faut donc respecter les exigences projets que sont le coût, la qualité (souhaitée) et le temps. Certains architectes, qui ne sont pas cadrés, n’hésiteront pas à décrire une fusée alors que le client souhaite une deux cheveaux. L’intervention des experts doit servir à valider certains choix ou à les redéfinir pour rester dans le triangle magique du projet (Qualité, temps, prix). Lors des spécifications fonctionnelles, il ne faut pas hésiter, lorsqu’il y a un doute à dire au client que tel ou tel point sera validé par un architecte avant d’acter sa réalisation.

Certains processus peuvent être décrits dans un diagramme permettant de mieux visualiser les différentes actions.

 Diagramme

Les spécifications doivent être à fur et à mesure validées. Le comité de pilotage devra de son côté “tamponné” ces spécifications.

Une relecture des documents et validation doit être faite afin de s’assurer que les doutes sont levés. La compréhension doit être partagée entre la MOE et la MOA. Encore une fois, attention aux validations vite fait, bien fait. Certains clients ont tendance à décrire leur besoin à fur et à mesure des développements ou une fois l’applicaiton terminée ! Au chef de projet aussi de s’assurer et de poser les questions en cas de doute.

À la fin de la phase de spécifications le chef de projet doit s’assurer que les documents suivants sont disponibles et validés:

  • Les spécifications fonctionnelles.
  • La liste des US priorisées: Une valeur métier peut être donnée par US
  • Les spécifications techniques
  • Dossier de gestion des risques
  • Plan de test et préparation des cas de tests
  • Plan de déploiement finalisé
  • Le contrat de service finalisé
  • Le dossier sécurité finalisé
  • L’estimation des charges par lots et fonctionnalités
  • Le planning réactualisé

Dans le cadre d’un projet Agile, les spécifications prendront la forme de user stories (récits utilisateur). Ces spécifications peuvent être réalisées par phase. On peut démarrer le premier sprint sans que les user stories du deuxième sprint ne soint déjà détaillées.