Modèles gratuits de spécifications fonctionnelles : la feuille de route pour une expérience de développement plus fluide

Agile se concentre sur la recherche du moyen le plus efficace de fournir un produit utile à un utilisateur. Dans le cadre du développement Agile, les documents et processus traditionnels sur les exigences fonctionnelles sont parfois considérés comme prohibitifs sur le plan financier. Néanmoins, la capture de plans et de croquis plus détaillés peut améliorer la clarté.

L’un des outils de gestion des exigences Agile les plus courants est le « récit utilisateur ». Les récits utilisateurs mettent les fonctionnalités dans le contexte de ce que l’utilisateur doit accomplir. Vous pouvez regrouper des récits utilisateurs similaires pour créer des épics Agile. Comme pour les spécifications des exigences fonctionnelles traditionnelles, les récits utilisateurs décrivent la tâche ou la fonction, mais pas la façon dont les développeurs doivent la mettre en œuvre.

Les récits utilisateurs utilisent la syntaxe suivante : « En tant qu’utilisateur, je veux avoir quelque chose pour en tirer des avantages. » Voici quelques exemples :

• En tant que conducteur, je veux savoir quand ma batterie doit être remplacée.
• En tant que cuisinier, je veux qu’un écran de tablette reste allumé tout au long de la réalisation de ma recette.
• En tant que chat, je veux que ma portion de nourriture soit servie dans mon bol à 16 h tous les jours.

Pour vérifier si l’histoire d’un utilisateur est bien formée, appliquez l’acronyme INVEST.

• Indépendant : Le récit peut-il fonctionner seul ?
• Négociable : Pouvez-vous modifier ou supprimer ce récit sans avoir d’impact sur le reste du projet ?
• Valeur : Ce récit a-t-il une valeur pour l’utilisateur final ?
• Estimable : Pouvez-vous estimer la taille du récit ?
• Suffisamment petit : Le récit de l’utilisateur est-il assez petit ?
• Testable : Pouvez-vous tester ce récit ?

À des fins de gestion de projet, dans l’outil de suivi, vous pouvez donner aux récits utilisateurs un nom et un ID numérotés. En outre, vous pouvez marquer la priorité de développement, le sprint et le statut de l’histoire. Les récits vont dans le backlog produit Agile.

Les modèles de récits utilisateurs sont généralement assez simples : Ils se concentrent sur l’identification du rôle de l’utilisateur, de sa tâche et de ce que la tâche doit accomplir. De plus, le modèle suivant comprend de l’espace pour identifier les informations sur le récit et le cycle de développement.

Télécharger un modèle simple de récit utilisateur Agile

Excel | Word

La planification d’un site web exige une compréhension de haut niveau de la technologie nécessaire et une compréhension détaillée des utilisateurs du site et de ce que vous (en tant que propriétaire du site) souhaitez que les utilisateurs accomplissent. Les récits utilisateurs utilisées dans le développement Agile peuvent vous aider à vous concentrer sur les besoins des utilisateurs. D’autres questions aident également à contextualiser le site web.

Le modèle de spécification du site web suivant pose une série de questions pour vous aider à définir l’objectif du site web, à qui il est destiné, les activités qui seront effectuées dessus, et toute considération particulière, comme les normes de sécurité telles que PCI pour les transactions financières.

Télécharger le modèle d’exigences fonctionnelles du site web

Word

Télécharger le modèle de spécifications techniques du site web

Excel

Lorsque vous développez des logiciels et d’autres technologies avec la méthode Waterfall, vous pouvez souvent utiliser un modèle d’exigences ou de spécifications fonctionnelles traditionnelles. Les exigences fonctionnelles répertorient les fonctionnalités et les fonctions que le produit « devrait » utiliser. Par exemple, « l'aspirateur doit ramasser des particules de moins de cinq mm ».

‌ Télécharger le modèle de spécifications fonctionnelles - Word

Vous pouvez également préférer un modèle qui se concentre davantage sur les exigences de l’entreprise. Ce modèle minimaliste vous permet de détailler le but de votre produit ou de le mettre à niveau dans le contexte des objectifs de votre entreprise, en plus des considérations de conception de plus haut niveau.

‌ Télécharger le modèle d’exigences fonctionnelles - Word

 

Vous pouvez créer des cas d’utilisation pour de nombreux types de produits, y compris des sites web et des logiciels. Les cas d’utilisation se concentrent sur les tâches qu’un utilisateur doit effectuer avec le produit, afin que les documents de cas d’utilisation puissent aider les développeurs à créer des produits axés sur les utilisateurs. Ces documents empêchent également les parties prenantes de mal interpréter la conception des produits. Utilisez ce modèle de cas d’utilisation pour définir les acteurs, les étapes et les branches propres à une tâche.

Télécharger le modèle de cas d’utilisation

Word

Les Spécifications Fonctionnelles Détaillées (SFD), également connues sous le nom de document d’exigences fonctionnelles,sont considérées par de nombreux experts en gestion de projet et en développement de logiciels comme l’outil essentiel pour limiter la confusion et les erreurs d’orientation sur un projet.

Bien que les SFD soient fréquemment associées au développement de logiciels et de sites web, elles ont un rôle à jouer dans tout projet, qu’il s’agisse du lancement d’un nouveau produit, d’une mise à niveau, du développement d’un produit logiciel ou d’un élément tangible, ou de l’établissement de changements de processus ou d’organisation. Les spécifications fonctionnelles détaillées présentent à la fois les attentes commerciales et celles en matière d’ingénierie. Toutes les parties prenantes doivent examiner et approuver le document. Le résultat est un document de référence pour le produit proposé qui s’adresse à toutes les parties de l’organisation, des codeurs aux concepteurs en passant par le personnel des ventes.

Vous pouvez utiliser un modèle de spécifications fonctionnelles détaillées pour vous assurer d’inclure toutes les informations de développement essentielles dans un document. De plus, les modèles garantissent qu’à chaque nouvelle initiative, les équipes se concentrent sur les exigences du produit au lieu de perdre du temps à déterminer la conception des SFD. Les modèles doivent être personnalisés pour répondre aux besoins uniques de chaque équipe ou entreprise.

Les SFD ont tendance à être longues, sans relief et souvent techniques. Mais ces documents peuvent ne pas être nécessaires, voire utiles. Les spécifications fonctionnelles détaillées ayant pour but d'élargir le projet à toutes les parties prenantes, elles évitent de longues discussions techniques. S'il est possible d'inclure de nombreux types d’exigences et d’informations à l’appui (voir la liste ci-dessous), la meilleure pratique consiste à décrire uniquement les intentions de base des SFD. Elles doivent décrire le contexte ainsi que les fonctionnalités et fonctions à développer. Un document de conception technique est créé en fonction des exigences fonctionnelles acceptées. Les SFD ne doivent pas faire double emploi avec d'autres exigences ou documents de processus.

Les spécifications fonctionnelles détaillées suivent un processus d’approbation : Les utilisateurs professionnels vérifient que la solution répond à leurs préoccupations, et les examinateurs techniques vérifient que la solution décrite peut être mise en œuvre. Souvent, les réviseurs clés sont les testeurs, les utilisateurs finaux, les rédacteurs techniques et les propriétaires des produits ou des systèmes. Vous pouvez déclarer le document comme terminé lorsque tout le monde est d’accord sur le contenu. Certaines organisations procèdent ensuite à la création du document d’architecture des systèmes.

Les spécifications fonctionnelles détaillées servent de document de référence pour l’ensemble de l’équipe. Elles montrent ce que les développeurs de produits devraient développer, ce que les testeurs devraient tester, ce que les rédacteurs devraient documenter, et ce que les commerciaux vendront. Des SFD écrites indiquent que la conception et l’intention ont été soigneusement prises en compte avant le début du développement. Elles montrent également qu’après l’approbation des spécifications, toutes les parties prenantes sont sur la même longueur d’onde. Il ne faut pas réécrire les spécifications une fois que le produit a été codé.

Certains analystes commerciaux et développeurs distinguent les spécifications fonctionnelles des exigences fonctionnelles ainsi : les exigences décrivent ce que le logiciel doit faire et les spécifications décrivent comment le logiciel doit le faire. En pratique, vous combinez généralement ces deux rôles.

Les spécifications (ou exigences) fonctionnelles détaillées peuvent également prendre diverses formes. Le format que vous choisissez dépend de ce qui fonctionne le mieux pour votre organisation.

• Exigences fonctionnelles : Elles conviennent généralement aux logiciels et autres technologies qui utilisent la méthode de développement Waterfall. Les exigences fonctionnelles répertorient les fonctionnalités et les fonctions que le produit « devrait » utiliser. Par exemple, « l'aspirateur doit ramasser des particules de moins de cinq mm ».
• Cas d’utilisation : Les cas d’utilisation sont souvent indépendants les uns des autres. Toutefois, les organisations pour qui l’expérience utilisateur est importante intègrent généralement des cas d’utilisation dans les exigences fonctionnelles. Les cas d’utilisation permettent de définir des fonctions et des fonctionnalités dans le contexte des actions des utilisateurs. Par exemple, « L’utilisateur appuie deux fois sur l’écran du téléphone. L’écran s'allume. L’utilisateur balaye l’écran vers la droite pour déverrouiller le téléphone et ses fonctionnalités. »
• Récits utilisateurs : Les récits utilisateurs constituent le cœur du développement Agile, car ils décrivent la conception des produits comme étant ce que l'utilisateur doit faire. Cette approche succincte aide les équipes à fournir de la valeur aux utilisateurs de la manière la plus efficace. Les récits utilisateurs prennent la forme « En tant qu’utilisateur, je veux faire quelque chose pour en tirer des avantages. »

Généralement, les analystes commerciaux et les responsables techniques créent des modèles et des spécifications fonctionnelles qu’ils partagent avec les parties prenantes commerciales et techniques. Ces dernières procèdent alors à des examens afin de s’assurer que le livrable attendu est conforme à la cible.

Vous pouvez utiliser des spécifications fonctionnelles pour développer de nouveaux logiciels et des mises à niveau. Vous pouvez également les utiliser pour les changements techniques de l’organisation et des systèmes, le développement web, etc. Les utilisateurs des spécifications comprennent les groupes suivants :

• Les développeurs, qui codent le produit
• Les concepteurs, qui créent l’interface utilisateur (UI) du logiciel, de l’appareil ou du site web
• Les testeurs, qui s’assurent que le code fonctionne correctement et selon les spécifications
• Les spécialistes du marketing, qui préparent des documents générateurs de demandes autour de la nouvelle fonctionnalité
• Les équipes de vente, qui vendent la fonctionnalité et le produit
• Les rédacteurs d’assistance technique ou d’assistance aux utilisateurs, qui documentent le fonctionnement du produit pour les administrateurs, les utilisateurs finaux et d’autres rôles

Bien qu’il existe de nombreuses combinaisons et permutations de documents, les spécifications fonctionnelles détaillées (SFD) et les documents sur les exigences commerciales (BRD) sont parfois distincts.

Les BRD décrivent les exigences commerciales de niveau supérieur pour un produit (ce qu’un produit fait). Les BRD évitent les détails techniques au profit d’une justification détaillée du produit. Une compréhension claire de ce que le produit offre et des raisons pour lesquelles il est nécessaire peut souvent aider à guider le développement lors de divergences sur l'orientation du produit. Les SFD se concentrent sur la description des fonctions et fonctionnalités du produit dont vous avez besoin pour atteindre votre objectif final.

La création d’un produit, qu’il soit tangible ou transactionnel, peut nécessiter la génération de nombreux documents. Les modèles de spécifications fonctionnelles peuvent être utilisés conjointement avec chacun des éléments suivants :

• Exigences utilisateur : Ce document représente ce que l’utilisateur attend du produit. Certains considèrent les exigences utilisateur comme faisant partie des exigences fonctionnelles détaillées. Si ce document existe, il doit être inclus dans votre processus de développement global. Dans le développement Agile, les exigences utilisateurs (exprimées sous forme de récits utilisateurs) sont considérées comme le cœur des exigences fonctionnelles.
• Exigences produit : Utilisées de manière interchangeable avec un document sur les exigences du marché, ce document détaille l’objectif d’un produit.
• Document sur les processus opérationnels : Ce document décrit en détail un processus métier.
• Évaluations des besoins de l’entreprise : Ce document décrit les écarts entre les conditions commerciales actuelles et souhaitées.
• Spécifications techniques : Ce document décrit (dans les moindres détails) les éléments de programmation requis pour la conception proposée.
• Documents de validation : Les documents de validation peuvent inclure une matrice de traçabilité (qui suit les fonctionnalités tout au long du processus de développement), des plans de test et des exigences d’opération.
• Exigences du système : Ce document décrit des attentes de haut niveau pour un système ou un produit.
• Exigences de l’entreprise : Ce document décrit les raisons de haut niveau pour créer un produit ou une mise à jour.
• Cas d’utilisation : Ce document offre des détails fonctionnels et le contexte des fonctionnalités du point de vue de l’utilisateur.
• Récits utilisateurs : Ce document est principalement utilisé pour le développement Agile. Il communique l’intention du produit en détaillant ce que l’utilisateur en fera.

Les exigences peuvent être catégorisées en tant que spécifications fonctionnelles et non fonctionnelles (le quoi et le comment).

• Exigence fonctionnelle : Cela décrit un comportement, une activité ou un résultat attendu de la part d’un produit ou d’un système. Par exemple, « Filtrer les particules de l’eau » ou « Imprimer une page ». Les exigences fonctionnelles courantes comprennent les fonctions d’administration, l’autorisation et l’authentification, le suivi et la création de rapports d’audit, ainsi que les règles commerciales.
• Exigence non fonctionnelle : Cela décrit le fonctionnement de quelque chose, qui peut également être considéré comme une contrainte, un attribut ou un paramètre. Si le mot anglais décrivant le processus se termine en « ity », il n’est pas fonctionnel. Parmi les exemples, on peut citer la facilité d’utilisation (usability), la maintenabilité (maintainability) et la sécurité (security), en plus des exigences en matière de performance et de réglementation.

Dans SAP, les spécifications fonctionnelles détaillées sont une description du produit du point de vue des parties prenantes, avec des attentes précises quant à la façon dont la fonction se rapporte à SAP. Vous créez des spécifications fonctionnelles après avoir combiné les SFD et les exigences logicielles en un seul document.

Au minimum, les SFD doivent inclure les éléments suivants :

• À qui le produit est destiné
• Qui est autorisé à utiliser le produit
• Entrées dans le système
• Ce que chaque écran doit faire
• Flux de travail système
• Sorties
• Exigences réglementaires traitées par le produit
• Exigences commerciales spécifiques de votre entreprise

Une description écrite des fonctions souhaitées est un élément essentiel du développement du produit, mais la forme que prend le modèle d’exigences fonctionnelles doit également être régie par ce qui fonctionne pour votre équipe.

Lors du développement d’un modèle, ou même lorsque vous envisagez d’apporter des améliorations à un processus de développement existant, demandez à tous ceux qui ont un intérêt particulier dans le résultat du produit ce qu’ils attendent d'un modèle. Chaque format offre des avantages et des inconvénients :

• Les énoncés sur ce que le produit « devrait » faire dans les exigences fonctionnelles traditionnelles ont tendance à manquer de contexte et sont plus sujets à l’interprétation des développeurs.
• Les cas d’utilisation offrent du contexte et des détails, mais le diable peut se cacher dans ces détails. La portée peut s'étendre à mesure que les exigences réelles des utilisateurs deviennent claires. Des exigences plus faibles peuvent se perdre dans les cas d’utilisation.
• Les récits utilisateurs offrent l’avantage de décrire les besoins des utilisateurs dans le contexte des exigences de l’entreprise. Toutefois, ils peuvent nécessiter des efforts supplémentaires (c.-à-d., la recherche d’une mise en œuvre adéquate). Les développeurs et d’autres personnes peuvent aussi se concentrer sur des histoires individuelles au point d’exclure le contexte plus large du produit.

Encore une fois, lorsque vous envisagez l’outil à utiliser pour créer des documents d’exigences logicielles, les besoins de votre organisation sont primordiaux. Ce qui fonctionne pour d’autres entreprises peut ne pas fonctionner pour vous.

• Gestion de la documentation : C'est l’un des outils les plus faciles et les plus omniprésents pour créer des modèles et produire des documents. De nombreux documents sur les exigences fonctionnelles sont disponibles sous forme de modèles de documents.
• Logiciel de feuilles de calcul : Les feuilles de calcul vous permettent d’ajouter des colonnes au besoin. Elles suppriment également la pression quant à la création de phrases parfaites, car il vous suffit de capturer les détails essentiels dont un lecteur a besoin pour créer le bon produit.
• Plate-forme de gestion de projets Agiles : De nombreuses plates-formes conçues sur mesure offrent des fonctionnalités permettant de saisir les détails des exigences ou des récits utilisateurs et de suivre le développement des fonctionnalités.

Si certaines exigences sont basiques et essentielles pour transmettre l’intention de votre produit, d’autres peuvent être utiles ou non au développement de votre produit. Le format que vous choisissez peut aussi être motivé par ce que vous développez. Voici une liste que vous pouvez utiliser comme guide lors de la préparation des exigences fonctionnelles :

• Section avant

  • Page de métadonnées : Cela résume tout ce qui concerne le document.
  • Instructions à destination des auteurs : Cela explique les informations particulières requises par votre organisation dans un document de spécifications. Ces instructions peuvent apparaître dans l’introduction ou tout au long du modèle.
  • Numéro de version
  • Modifier la page d’enregistrement/de révision : Dans le modèle et le document d’exigences publié, vous devez inclure toutes les modifications, les détails, les dates et les initiales de l’approbateur.
  • Bloc d’approbation : Il s’agit de signer chaque révision et d’approuver chaque exigence par une signature.
  • Liste de distribution : Certains membres de l’équipe peuvent être amenés à réviser le document. Il est également possible de limiter la visualisation à quelques membres de l'équipe.

• Présentation

  • Description du produit
  • Présentation des exigences de l’entreprise
  • Portée du travail (ce qui sera couvert ou non)
  • Description du système actuel
  • Conventions relatives aux documents
  • Terminologie (y compris les acronymes)
  • Références
  • Contraintes et hypothèses générales
     

• Fonctionnalités

  • Processus commercial
  • Méthodes proposées
  • Rôles utilisateurs/communauté d’utilisateurs
  • Cas d’utilisation
  • Récits utilisateurs
  • Flux de travail au sein du système
  • Prototypes de conception
  • Wireframes ou storyboards
  • Liste de fonctionnalités ou descriptions des fonctions
  • Exigences en matière de données
  • Fonctionnalité d’administration
  • Gestion de la configuration
  • Plate-forme
  • Installation
  • Portabilité
  • Évolutivité
  • Personnalisation
  • Impression
  • Gestion des erreurs
  • Assistance et maintenance
  • Internationalisation
  • Aide et documentation
     

• Autres logiciels

  • Entrées, sorties et traitement
  • Interfaces externes
  • Interfaces utilisateur
  • Interfaces matérielles
  • Interfaces logicielles
  • Interfaces de communication
  • Prise en charge des bases de données
     

• Attributs

  • Sécurité
  • Fiabilité, disponibilité, maintenabilité, facilité d’utilisation, compatibilité
  • Exigences réglementaires
     

• Annexe

  • Modèles d’analyse

Donnez à vos employés les moyens de se dépasser grâce à une plateforme flexible conçue pour répondre aux besoins de votre équipe, et capable de s'adapter quand ces besoins changent. La plateforme Smartsheet facilite la planification, la capture, la gestion et la création de rapports sur le travail depuis n'importe où, ce qui permet à votre équipe d'être plus efficace et d'accomplir plus. Créez des rapports sur les métriques clés et obtenez de la visibilité en temps réel quant au travail grâce aux rapports de synthèse, aux tableaux de bord et aux flux de travail automatisés conçus afin d'aider votre équipe à rester connectée et informée. Quand les équipes bénéficient de clarté quant au travail en cours, elles peuvent accomplir bien plus dans le même temps. Essayez Smartsheet gratuitement, dès aujourd'hui.