• 10 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 21/12/2023

Débutez la phase de conception détaillée

Découvrez les principes clés des spécifications détaillées fonctionnelles

Après avoir réalisé les spécifications techniques avec l’aide de votre équipe, vous devez maintenant entrer plus en profondeur dans votre documentation. Il s’agit d’aider les développeurs à réaliser l’application avec le plus de précision possible. Cela tombe bien, puisque cette étape s’intitule “les spécifications détaillées”.

Vous êtes à la dernière étape, soit la phase n°4 du cycle en V qui précède celle du codage (phase n°5). Vous devrez créer un document qu’on appelle “cahier des spécifications détaillées”.

La quatrième étape du cycle en V : les spécifications détaillées
La quatrième étape du cycle en V : les spécifications détaillées

Le cahier des spécifications détaillées (CSD) est un document qui sert de guide détaillé pendant la phase de développement d'un projet pour les développeurs. Il comprend :

  1. La description précise des fonctionnalités : Il fournit des détails sur chaque fonctionnalité que le produit ou le système doit avoir, y compris comment elle doit fonctionner et interagir avec d'autres parties du système.

  2. Les informations sur l'interface utilisateur : Il comprend également des détails sur l'interface utilisateur, tels que la disposition des boutons, la navigation, les champs de saisie de données, etc.

  3. Les exigences techniques : Il peut aussi inclure des informations sur les exigences techniques, y compris le matériel et le logiciel nécessaires, les protocoles à utiliser, les exigences de performance, etc.

  4. Les flux de données et diagrammes : Le CSD comprend souvent des flux de données et des diagrammes qui décrivent en détail comment les données se déplacent à travers le système et comment les différentes parties du système interagissent entre elles.

Pourquoi créer un document à part ? Je pourrais joindre en un seul document les spécifications fonctionnelles et techniques, tout simplement…

Très bonne question ! Et je vous propose d’y répondre en 3 points pour expliquer pourquoi ce document est indispensable !

  1. Le niveau de détail : Le CSD comprend généralement un niveau de détail beaucoup plus élevé que les spécifications fonctionnelles ou techniques. Alors que les spécifications fonctionnelles et techniques peuvent donner une vue d'ensemble de ce que le système doit faire et comment il doit le faire, le CSD détaille exactement comment chaque fonctionnalité sera mise en œuvre.

  2. Le public cible : Alors que les spécifications fonctionnelles sont généralement rédigées pour les clients et les utilisateurs finaux, et les spécifications techniques pour les architectes système et les développeurs, le CSD est spécifiquement destiné aux développeurs qui travailleront sur le projet. Il sert de guide pour l'implémentation du projet.

  3. Le focus : Les spécifications fonctionnelles se concentrent sur "quoi", les spécifications techniques sur "comment", tandis que le CSD se concentre sur "comment exactement". Il donne un niveau de précision qui n'est pas présent dans les deux autres types de spécifications.

Assurez la qualité des spécifications détaillées fonctionnelles

En tant que chef de projet, vous allez coordonner la rédaction des spécifications détaillées comme pour les précédents documents (spécifications fonctionnelles et techniques). Vous aurez la responsabilité de définir un plan de documentation suffisamment précis afin que chaque corédacteur puisse y ajouter la partie qui concerne son domaine d’expertise.
Afin d’assurer la qualité de votre document, vous devez intégrer des notions et thématiques importantes qui faciliteront le travail des développeurs.
Pour cela, je vous propose 5 thématiques pertinentes qui doivent apparaître sur le cahier de spécifications détaillées, si vous voulez produire un document de qualité. Un mini tableau décrira le titre de la section, les informations qui sont attendues ainsi que le profil de rédacteur qui est généralement impliqué dans cette partie.

  • L’introduction et le glossaire.

Section

Description

Profil de rédaction

Introduction

Cette section devra donner une vue d'ensemble du projet, du contexte, des objectifs, et une brève description de l'application.

Chef de projet / Business Analyst

Portée

Cette section décrit précisément ce qui est inclus dans le projet, ainsi que ce qui n'est pas inclus. Elle définit les limites du projet.

Chef de projet

Glossaire

Cette section fournit les définitions des termes techniques et des sigles utilisés tout au long du document.

Business Analyst

 / Développeurs

  • Fonctionnalités et interfaces utilisateur.

Section

Description

Profil de rédaction

Fonctionnalités détaillées

Chaque fonctionnalité du système est détaillée ici, y compris comment elle fonctionne, son interaction avec d'autres fonctionnalités, et toute condition ou exception.

Business Analyst

/ Développeurs

Interface utilisateur

Cette section décrit en détail la conception de l'interface utilisateur, y compris la navigation, la disposition, les couleurs, les polices, etc. Elle peut inclure des maquettes ou des croquis.

Designer UX/UI 

  • Exigences techniques et intégration.

Section

Description

Profil de rédaction

Exigences de performance

Cette section décrit les exigences de performance du système, telles que la vitesse, la capacité, la disponibilité, etc.

Architecte système / Développeurs

Exigences de sécurité

Cette section décrit les exigences de sécurité, comme les protocoles de cryptage, la gestion des utilisateurs et des droits, la protection des données, etc.

Architecte système / Développeurs

Intégrations

Si l'application doit être intégrée à d'autres systèmes, cette section décrit ces intégrations en détail, y compris les protocoles d'interface, les formats de données, etc.

Architecte système / Développeurs

Flux de données et diagrammes

Cette section contient des diagrammes décrivant le flux de données à travers le système, et comment les différentes parties du système interagissent entre elles.

Architecte système / Développeurs

  • Exigences des tests.

Section

Description

Profil de rédaction

Exigences de test

Cette section décrit les critères que le système doit satisfaire pour être considéré comme ayant réussi les tests. Elle peut inclure des cas de test spécifiques.

Ingénieur QA / Développeurs

  • Gestion des changements.

Section

Description

Profil de rédaction

Changements et mises à jour

Cette section fournit des informations sur comment les changements seront gérés et comment le document sera mis à jour.

Chef de projet

Après avoir défini les spécifications détaillées, vous devrez penser à l’étape du développement et des tests. Voyons comment optimiser votre travail sur ces phases.

Faciliter le processus de développement et de test

En tant que chef de projet, vous devez apporter votre contribution pour améliorer et faciliter les étapes de développement et de tests. Il y a deux mots-clés à garder à l'esprit : la testabilité et la traçabilité

Ces deux concepts sont essentiels pour assurer la qualité du logiciel développé.

La testabilité décrit à quel point il est facile de vérifier qu'un système fonctionne correctement. Un logiciel est considéré comme testable si les tests peuvent être réalisés de manière récurrente, prévisible et efficace. Pour cela, vous devez veiller à :

  • Écrire des spécifications testables : Lors de la rédaction des spécifications détaillées, vous devez veiller à ce qu'elles soient clairement testables. Cela signifie que chaque spécification doit être claire, sans ambiguïté et vérifiable. Par exemple, au lieu de dire "Le logiciel doit être rapide", précisez "Le logiciel doit charger la page d'accueil en moins de 2 secondes".

  • Coordonner les tests : Vous devez coordonner l'ensemble des tests à effectuer sur le logiciel. Cela peut comprendre les tests unitaires, les tests d'intégration, les tests de système et les tests d'acceptation. 

Je suis perdu… Vous parlez de tests unitaires, d'intégration, de système, d'acceptation… De quoi s’agit-il ?

  • Les tests unitaires permettront de tester un bout de code de manière isolée. 

  • Les tests d’intégration permettront de tester si plusieurs éléments de code fonctionnent correctement ensemble. 

  • Le test de système permettra de tester l’ensemble des fonctionnalités créées.

  • Les tests d'acceptation permettront aux véritables utilisateurs de tester le programme dans son entièreté et de valider si le fonctionnement répond à toutes leurs attentes.

Voici quelques exemples d'un logiciel de pilotage automatique pour avion que j’utilise afin de vous expliquer en quoi consistent ces différents tests :

Type de test

Description

Tests unitaires

Vérifiez si chaque bouton d'un tableau de bord fonctionne individuellement. Par exemple, le bouton d'allumage du moteur allume bien le moteur.

Tests d'intégration

Vérifiez comment ces boutons fonctionnent ensemble. Par exemple, lorsque vous allumez le moteur et augmentez la puissance, l'avion accélère-t-il correctement ?

Tests système

Testez le fonctionnement global de l'avion. Est-ce que l'avion décolle, vole et atterrit correctement quand vous utilisez le pilote automatique ?

Tests d'acceptation

Les pilotes (utilisateurs) testent le logiciel de pilotage automatique. Est-ce qu'ils trouvent le système facile à utiliser ? Est-ce que le système leur permet de piloter l'avion en toute sécurité et efficacement ?

Chacun de ces tests vous aide à vous assurer que le logiciel de pilotage automatique fonctionne correctement et en toute sécurité.

Si les tests échouent, que dois-je faire ?

Si les tests échouent, vous devez travailler avec votre équipe pour identifier la cause du problème, puis faire les modifications nécessaires pour le résoudre. Une fois ces modifications apportées, vous effectuez de nouveaux tests pour vérifier que le problème a bien été corrigé.

Maintenant, chaque fois qu'un test échoue et qu'une réparation est effectuée, il est important de garder une trace de ces modifications. Cela nous amène à l'importance d'assurer la traçabilité.

La traçabilité est la capacité à retracer l'histoire, l'utilisation ou l'emplacement de quelque chose. Dans le cadre d'un projet de développement de logiciel, cela signifie la capacité à suivre les exigences depuis leur origine, à travers leur développement, jusqu'à leur livraison finale. 

Pour assurer la traçabilité, vous devez :

  • Suivre les exigences : Vous devez avoir un système en place pour suivre les exigences tout au long du projet. Cela peut nécessiter l'utilisation d'un outil de gestion de projet (Jira, Monday, Wrike) ou d'un tableur pour faire le suivi. Chaque exigence doit être clairement identifiée (par exemple, avec un identifiant unique), et son statut doit être mis à jour régulièrement.

  • Documenter les modifications : Chaque changement apporté à une exigence doit être enregistré. Cela devrait inclure qui a fait le changement, pourquoi le changement a été fait et quand il a été fait. Pour les développeurs qui modifient leur code, cela peut être fait en utilisant des outils de gestion de version, tels que Git, qui enregistrent chaque modification du code source, ainsi que les raisons de ces modifications.

En somme, vous jouez un rôle clé dans le processus de développement et de test du logiciel. En assurant la testabilité et la traçabilité, vous pouvez non seulement améliorer la qualité du logiciel, mais aussi faciliter le travail de l'ensemble de l'équipe de développement.

Maximisez la gestion et la communication avec les spécifications détaillées

Votre rôle est de veiller à ce que les spécifications de votre projet soient en parfaite adéquation avec les besoins et les contraintes identifiés. Cela peut sembler une tâche difficile, mais en suivant quelques principes clés, vous pouvez vous assurer que votre cahier des spécifications détaillées est aligné et répond aux exigences.

Coordonner les besoins

Assurez-vous que les besoins des utilisateurs et les spécifications du logiciel correspondent. Si un besoin change, mettez à jour les spécifications en conséquence.

OK, mais si je modifie les spécifications, cela peut impacter le budget et le timing, non ?

Effectivement, vous devez être conscient de combien coûtent ces changements et de combien de temps cela prendrait pour créer chaque élément du système. Vous devez identifier ce dont vos utilisateurs ont vraiment besoin et comment ils vont utiliser ce que vous créez. Puis vous devez estimer combien de temps et d'argent il faudra pour réaliser chaque tâche, afin de vous assurer que vous pouvez tout faire sans dépasser votre budget ou votre échéance.

Gérer les contraintes

Chaque projet a ses propres contraintes, comme le temps, l'argent, les ressources ou la technologie. Vous devez identifier et gérer ces limites, savoir lesquelles sont les plus importantes et trouver des solutions quand cela est nécessaire.

Comment puis-je trouver des solutions ?

Une fois votre liste de fonctionnalités et leur coût/délai estimés, il faut les classer par importance. Déterminez ce qui est indispensable pour le projet et ce qui peut attendre. Si une fonctionnalité est trop chère ou longue à développer, envisagez des alternatives, comme utiliser un outil existant ou modifier une fonctionnalité déjà en place.

Coordonner et communiquer

Vos spécifications doivent correspondre aux besoins de l'entreprise et être clairement expliquées à tous. Il faut montrer comment chaque fonction s'intègre au système global.

Assurez-vous que vos spécifications correspondent aux besoins de l'entreprise et s'intègrent bien aux systèmes existants. Communiquez clairement ces détails à toutes les parties prenantes – utilisateurs, développeurs, testeurs, gestionnaires – afin que tout le monde soit d’accord sur le fonctionnement prévu du système.

En suivant ces principes, vous pouvez vous assurer que vos spécifications sont alignées sur les besoins et les contraintes de votre projet.

À vous de jouer

Contexte

En tant que chef de projet MOE chez AirGalaxy, votre rôle est de comprendre les détails techniques écrits par l'équipe technique et de les relier aux spécifications fonctionnelles du projet. C’est-à-dire que vous devez savoir à quelle fonctionnalité chaque composant technique proposé sera utile.

Pour cela, vous allez utiliser les informations fournies par l'équipe technique sur l'utilité de chaque partie du logiciel.

Consignes

Sur le modèle de Notion spécialement créé pour le projet d'AirGalaxy, vous devez ajouter tous les composants techniques liés à chaque fonctionnalité spécifiée dans la colonne correspondante.

Cela vous permettra de voir comment chaque composant contribue à la réalisation des fonctionnalités de l'application.

En résumé

  • Le cahier de spécifications détaillées (CSD) est un guide précis aidant les développeurs à construire un logiciel avec des détails sur les fonctionnalités, l'interface utilisateur, les exigences techniques et les flux de données.

  • Le CSD est différent des spécifications fonctionnelles et techniques : il est plus détaillé, destiné spécifiquement aux développeurs et se concentre sur "comment exactement" réaliser les choses.  

  • Un bon CSD facilite les tests et assure la traçabilité du logiciel. Les tests vérifient que le logiciel fonctionne bien et la traçabilité permet de suivre l'histoire de chaque modification.

  • En tant que chef de projet, vous devez veiller à ce que le CSD soit aligné avec les besoins et les contraintes du projet.

En élaborant des spécifications détaillées, il est bénéfique d'utiliser des schémas pour clarifier les fonctionnalités à développer. Explorons cela avec la création de diagrammes !

Exemple de certificat de réussite
Exemple de certificat de réussite