Pourquoi créer un document d’exigences techniques ?
Rachel S. Smith, author of Writing a Requirements Document, explains that a technical requirement document, “Presents why a product is needed, puts the product in context, and describes what the finished product will be like.” For software projects, a technical requirements document generally refers to how the software will be built including the operating system it is being programmed for and other standards.
Si vous ne créez pas de document d’exigences techniques, de vrais problèmes peuvent se développer, selon Mme Smith. Ces problèmes peuvent inclure :
- Création d'un produit qui ne répond pas à un réel besoin.
- Développement d'une « dérive des fonctionnalités ».
- Le fait de se retrouver avec un groupe au sein de l’équipe qui pense construire une fourmi, tandis que l’autre pense construire un éléphant.
Renee Fellman, a Portland, Oregon-based business expert who specializes in turning around businesses on the brink of failure, has found that failure to adequately document technical requirements can cause serious problems for a company that impact their bottom line.
Problems that arise from not having technical requirements documentation can range from simple to complex. “In one company I consulted for,” Fellman said, “Vital FDA compliance issues weren’t being addressed because human resources had failed to do something as simple as assign the duty of taking care of regulatory affairs.”
Project Management Guide
Your one-stop shop for everything project management
Ready to get more out of your project management efforts? Visit our comprehensive project management guide for tips, best practices, and free resources to manage your work more effectively.
La valeur des documents d’exigences techniques
Un document d’exigences techniques donne à votre équipe la possibilité de parvenir à une compréhension commune de ce qui est requis, techniquement, pour réussir le projet ou le produit. Parmi les cinq phases de la gestion de projet, les documents d’exigences techniques doivent être créés au cours de la phase 2 du cycle de vie du projet. Au cours de cette phase, la portée de votre projet est définie, ainsi que les objectifs. Les documents d’exigences techniques vous fourniront également des informations qui vous aideront à :
- Déterminer votre budget.
- Créer votre calendrier de répartition du travail.
- Développer le diagramme de Gantt du projet.
- Initier un plan de communication.
- Définir les aspects de la gestion des risques.
Attentes vis-à-vis des préparateurs de documents d'exigences techniques
Toute personne préparant un document d’exigences techniques doit comprendre ce qui constitue une « bonne » exigence de système et la manière de communiquer ces informations de façon claire.
- Gardez à l’esprit les points suivants :
- Faites preuve de créativité quant aux sources que vous choisissez d’étudier lorsque vous analysez vos exigences techniques et utilisez toujours le besoin de votre entreprise comme point de référence
- Aidez les autres à comprendre vos résultats en utilisant un langage facile à comprendre
- Utilisez des prototypes pour déterminer ce qui vous manque
- Assurez-vous de comprendre les interdépendances, les priorités, les coûts, la mise en œuvre et les conséquences environnementales lorsque vous décidez de ce qu’il faut inclure
- Définissez les limites du système
Autres types de documents d’exigences couramment trouvés dans les affaires
Pour déterminer votre liste initiale d’exigences techniques, sachez qu’il existe d’autres documents préparés par d’autres équipes de l'entreprise. Ces documents portent sur le même projet, mais sont destinés à des publics différents. Il est tout à fait possible que certains de ces documents contiennent des informations redondantes. Vous pouvez pressentir que certains éléments concernent votre document d’exigences techniques et non le document d’exigences métier ou d’exigences du marché, mais ne vous inquiétez pas, ils peuvent être présents dans les deux à la fois. C’est à vous de créer un document d’exigences techniques qui convienne le mieux à vos objectifs. Assurez-vous de recueillir les informations les plus utiles pour vous.
Michael Shrivathsan, Vice-président de la gestion de produit chez Accompa, est un expert des types de documents d’exigences et de leurs fonctions.
“There can be some overlap between business, market, and technical requirement documents,” said Shrivathsan. “Depending on the organization, they may or may not use all these document types. At large companies (1,000 employees plus), they typically do use all three of these docs. Most mid-sized companies (200 employees or more) use at least two of them.”
Il est possible que ces autres rapports contiennent des informations importantes susceptibles d'enrichir ou influencer votre document d’exigences techniques ou d'identifier d'autres éventualités. Voici d’autres documents qui peuvent être créés par d’autres services et soutenir votre projet :
Document d'exigences métier (BRD)
Écrit par : chefs de produit, responsables marketing produit
Public : responsables commerciaux
Examiné et approuvé par : cadres de niveau C
Le document d’exigences métier définit l’analyse de rentabilité de haut niveau du projet et est généralement préparé en premier.
Un document d’exigences métier définit le but du projet du point de vue commercial. La documentation pour cette phase délimite les objectifs de l’entreprise à un niveau élevé. Les membres de cette équipe doivent avoir rencontré les responsables commerciaux appropriés au sein de votre entreprise ou de l’entreprise du client, afin de recueillir les informations commerciales nécessaires, axées à la fois sur les besoins de votre entreprise et ceux de votre client.
À partir du document d’exigences métier, vous pouvez tirer les informations suivantes qui pourraient vous aider pour votre document d’exigences techniques :
- La nature des besoins de vos clients
- La manière dont la réponse à ces besoins s’aligne sur la mission de votre entreprise
- La manière dont votre produit, système ou logiciel répond aux besoins de votre client à un haut niveau
- Une image des relations entre toutes les parties prenantes du projet, grâce à un flux approprié, des diagrammes organisationnels ou des graphiques, est recommandée pour garantir la clarté du projet
Document d’exigences du marché (MRD)
Écrit par : chefs de produit, responsables marketing produit
Public : responsables commerciaux
Examiné et approuvé par : directeur
Un document d’exigences du marché ajoute des informations au BRD au sujet des besoins du marché et identifie le paysage actuel du marché pour les produits ou programmes similaires à ceux que vous développez. Avoir des informations sur ce qui existe déjà, sur la façon dont est faite la commercialisation et sur les personnes ciblées peut vous aider à déterminer les lacunes dans d'autres fonctionnalités du produit.
À partir du document d’exigences du marché, vous pouvez tirer les informations suivantes qui pourraient vous aider pour votre document d’exigences techniques :
- Le type de produit prévu
- Les clients ciblés
- Les personas qui définissent :
- Les caractéristiques du client
- Les difficultés auxquelles font face les clients
- La manière dont le produit proposé aidera à résoudre ces difficultés
- Les produits concurrents et leurs avantages et inconvénients
- En quoi votre produit sera meilleur
Si personne dans votre entreprise ne prépare les rapports ci-dessus, vous devrez peut-être faire un travail supplémentaire pour obtenir la vue d’ensemble de l’univers dans lequel votre produit existera.
Les exigences techniques doivent se concentrer sur les résultats souhaités
Les exigences techniques de développement de logiciel comprennent des éléments tels que la planification du développement, l’architecture technique, les tests logiciels et le déploiement. Selon Renee Fellman, de bonnes exigences techniques se concentrent d'abord sur les résultats souhaités et ne sont pas trop axées sur le processus. Pourquoi ? Parce que l'endroit où vous souhaitez arriver détermine la façon dont vous allez y arriver. Par exemple, vous ne prendriez pas un chameau pour arriver au sommet du Mont Everest, mais vous pourriez en chevaucher un si votre objectif final était de parvenir à une tombe ancienne dans le désert égyptien.
Mme Fellman met en garde : « ne pas poser les bonnes questions avant de commencer à préparer le document d’exigences techniques peut conduire à un document qui ne résout pas réellement le problème auquel vous cherchez à remédier ».
Bien sûr, les questions varient en fonction de vos clients, de votre entreprise et du service ou du produit prévus, mais pour les documents d’exigences techniques, cherchez ce que doit accomplir votre nouveau système ou logiciel, en particulier du point de vue de l’utilisateur. Il vous faudra peut-être consulter vos développeurs et demander, de leur point de vue, ce qui est faisable et ce qui ne l’est pas.
La liste de contrôle des exigences techniques modèle est un outil organisationnel précieux
Utiliser une liste de contrôle modèle, comme la liste de contrôle pour le recueil d’exigences de Smartsheet, peut vous aider à vous concentrer sur les types d’informations que vous devez recueillir dans le cadre de votre analyse des exigences techniques.
Assurez-vous d’inclure :
- Exigences fonctionnelles et tâches effectuées
- Dates à suivre en termes de jalons
- Exigences physiques pour un produit tangible, comme la taille, le poids, la couleur, la forme, la texture, et la robustesse
- Spécificités de l’environnement technique
- Exigences de données
- Interfaces externes
- Compatibilité/portabilité
- Maintenance
Recueillez des informations auprès de divers groupes
Rachel S. Smith suggère que les informations pour ces types de documents peuvent provenir de diverses sources, y compris des utilisateurs finaux, des clients, des développeurs et d’autres parties prenantes. Les informations peuvent être recueillies à l’aide d’entretiens, d’enquêtes, de questionnaires, de recherches ou même de tables rondes entre les équipes ou les membres d'une même équipe.
Recourez à l’analyse d’utilisation
Identifiez les types d’utilisateurs qui utiliseront votre produit et déterminez leurs schémas d’utilisation. Cela sera utile pour déterminer les exigences nécessaires pour le niveau de performance que vous souhaitez atteindre.
Développez des cas d’utilisation
Les modèles d'interactions avec les utilisateurs typiques doivent être inclus dans le document d’exigences techniques ou dans le document d’exigences métier, à l’aide de diagrammes de cas et de rapports de cas.
Recherchez les besoins et les résultats souhaités
Envisagez de recueillir les types d’informations suivants pour votre document d’exigences techniques :
1. Définissez les attentes et les besoins des utilisateurs finaux, et la manière dont le produit sera utilisé dans le monde réel. Posez des questions (voici quelques exemples) :
- Quel problème principal votre produit ou logiciel résoudra-t-il pour votre public ?
- Que souhaitez-vous que les gens accomplissent en utilisant votre produit ou votre logiciel ?
- Comment facilitera-t-il la vie ou la rendra-t-il plus productive ?
2. Définissez la structure de l’équipe et les différentes éventualités
- Quels membres de l’équipe sont responsables des différents aspects du travail ? (N’oubliez pas l’exemple de Renee Fellman ci-dessus et assurez-vous que toutes les responsabilités importantes du travail sont attribuées.)
3. Définissez le produit
- Utilisez des maquettes, des récits ou des listes.
- Exprimez clairement les exigences d’interface.
- Clarifiez les exigences des clients particuliers et professionnels, en particulier si le produit ou le logiciel est conçu conformément à la spécification d’un client.
- Définissez les étapes de développement.
- Incluez des étapes spécifiques jusqu'à l’achèvement du projet, et créez un calendrier initial qui pourra être affiné au fur et à mesure que d'autres détails sont découverts et décidés.
- Identifiez les imprévus en examinant quelles parties du processus dépendent les unes des autres et pourquoi.
4. Créez un prototype pour clarifier les résultats que les utilisateurs attendent du nouveau produit ou système lorsqu’il sera terminé
5. Définissez l’ensemble du cycle de vie du développement du produit, y compris les personnes, les processus, le développement de logiciel et de technologies, la gestion des modifications
6. Assurez-vous que chaque exigence du système décrit :
- La fonction qu’il exécute.
- Toutes sortes de limites, en termes de conception, de contraintes juridiques ou règlementaires, ou de risques.
- Les exigences de conception environnementale pour l’emplacement opérationnel, l’utilisation ou le stockage.
Tenez compte des qualités du système
Tenez compte des qualités du système suivantes lorsque vous décrivez la qualité de service dont vous avez besoin pour répondre aux exigences de votre entreprise et de vos utilisateurs.
- Disponibilité - Durée de « bon fonctionnement » que vous pouvez attendre de votre système en fonction de ses ressources, de ses services et de son accessibilité aux utilisateurs finaux.
- Capacité latente - Manière dont votre système traitera des pics d’utilisation inattendus sans ressources supplémentaires.
- Performance - Temps de réponse et capacité latente en fonction des conditions de charge spécifiques d’une gamme d’utilisations.
- Évolutivité - Rapidité avec laquelle la capacité et le nombre d’utilisateurs peuvent être augmentés ou réduits, sans changer l’architecture originale.
- Facilité de maintenance - Facilité à surveiller, réparer et mettre à niveau les éléments matériels et logiciels du système. Les facteurs à prendre en compte comprennent la planification des temps d’arrêt, les opportunités de maintenance en fonction des schémas d’utilisation, les temps critiques pour la disponibilité des services, les plannings de diagnostic et de suivi.
- Sécurité - Principe de sécurisation du système, y compris l’autorisation et l’authentification des utilisateurs et des informations pendant le transfert.
Valider et affiner les exigences techniques
Une fois que vous avez défini vos exigences techniques, prenez le temps de les valider et de les affiner. Rachel S. Smith a déclaré : « Nous avons examiné des facteurs comme le nombre de parties prenantes ayant demandé une exigence donnée, le nombre d’autres exigences qui dépendaient de celle-ci, si elle allait faciliter l'utilisation du système ou exécuter une fonction que les utilisateurs ne peuvent pas accomplir autrement, ainsi que d’autres mesures qualitatives. »
Pour Mme Smith, la validation des exigences était un processus permettant de les évaluer autant que possible, d’écouter les commentaires et de discuter de ce que cela impliquait de garder ou de rejeter une exigence donnée. « Il n’y a pas vraiment de raccourci. Il s’agit d’impliquer les parties prenantes clés et de travailler avec elles pour comprendre toutes les divergences d’opinions et leur trouver une solution. »
Mme Smith prédit que vous ne saurez jamais si vous avez identifié toutes les exigences nécessaires. « Vous recueillerez probablement plus que nécessaire. Mais une fois que vous avez les exigences, hiérarchisez-les et travaillez sur les exigences prioritaires compatibles avec le temps et le budget dont vous disposez. Parfois, ce ne sont pas les plus grandes exigences qui sont les plus importantes. »
Tenez les parties prenantes informées
Aujourd’hui, il existe des outils qui donnent aux parties prenantes une vue d’ensemble directe du processus de développement, où elles peuvent voir le suivi visuel de l'avancement, vérifier (mais non modifier) les exigences au fur et à mesure qu’elles sont mises en œuvre, et tester les premiers prototypes. « Le développement de logiciel est une chose si délicate », explique Rachel S. Smith. « Les gens se réjouissent des fonctionnalités avant qu’elles ne soient développées, et peuvent être vraiment déçus si leurs attentes ne sont pas comblées. » Par conséquent, tenir les personnes informées, leur donner un accès précoce et leur transmettre des mises à jour régulières d'une manière qui leur convient est la clé de la satisfaction des utilisateurs finaux une fois le produit publié.
La modélisation Agile est-elle faite pour vous ?
La modélisation Agile (AM) est une autre façon de créer et de documenter un modèle qui peut être déployé dans le développement de systèmes et de produits basés sur les logiciels. Sa portée dépasse la documentation des exigences techniques pour inclure l’ensemble du processus et combine les bonnes pratiques basées sur les valeurs les plus efficaces et les principes de création du meilleur logiciel possible, selon le temps et le budget disponibles.
Pour en savoir plus sur la modélisation Agile, voici quelques livres recommandés :
- Disciplined Agile Delivery (DAD): A Practitioner’s Guide to Agile Software Delivery in the Enterprise par Scott W. Ambler et Mark Lines, IBM Press, ISBN : 013281013
- The Object Primer 3rd Edition: Agile Model Driven Development with UML 2. Cambridge University Press, 2004, ISBN# : 0-521-54018-6
- Introduction to Disciplined Agile Delivery: A Small Team's Journey from Scrum to Continuous Delivery par Mark Lines et Scott W. Ambler, Disciplined Agile Consortium, ISBN : 978 149 754 4383
Modèles d'exigences techniques vs logiciel
Les modèles sont faciles à utiliser et le coût est correct, mais il existe également des alternatives. L’entreprise de Michael Shrivathsan, Accompa, produit des logiciels de documentation des exigences qui gèrent les problèmes qui pourraient survenir à cause d’informations redondantes ou erronées.
Ce logiciel :
- Suit les interdépendances entre ces trois types de documents. Si quelque chose dans le document d’exigences métier change, cela peut entraîner un effet sur les documents d’exigences techniques et d'exigences du marché.
- Fournit un espace où conserver toutes les informations afin qu’elles puissent être facilement consommées (Mr Shrivathsan a mentionné que dans la plupart des grandes entreprises, ces informations peuvent être divisées en plusieurs silos, ce qui rend leur recherche et leur utilisation très difficile).
« Excepté pour les plus petits projets, il est presque impossible de suivre manuellement ces interdépendances », a déclaré Mr Shrivathsan. « Un outil logiciel abordable est donc nécessaire. »
Conseils pour rédiger le document d’exigences techniques
La rédaction d’exigences techniques est un peu différente de celle des autres documents métier standards. Il existe une façon de les rédiger afin qu’elles puissent être comprises par les personnes qui les utiliseront pour mener à bien un projet ou créer un nouveau type de logiciel. Voici quelques astuces qui peuvent vous aider à rédiger des exigences techniques utiles :
- Utilisez un langage simple et direct afin que tout le monde ait la même compréhension de ce que vous voulez dire.
- Soyez concis. Commencez par un paragraphe d’introduction, suivi d'une liste à puces pour améliorer la lisibilité.
- Utilisez une structure de phrase simple pour transmettre une seule idée principale à la fois.
- Parfois, une image VAUT mille mots, surtout si elle simplifie un concept ou montre la relation entre deux concepts.
Documents d’exigences techniques pour les établissements d’enseignement et les entreprises
Certains établissements d’enseignement et entreprises ont sur leurs sites des pages Web consacrées aux exigences techniques de base pour le matériel informatique, les logiciels et les navigateurs. Si ces exigences techniques de base ne sont pas respectées, les étudiants, les professeurs ou les employés ne sont pas en mesure d’accéder à l’intranet. Dans le cas des étudiants, cela signifie qu’ils ne peuvent pas suivre de cours en ligne. Dans le cas des entreprises, cela signifie que les employés ne peuvent potentiellement pas faire leur travail.
Les informations comprennent généralement :
- Les configurations minimales pour les plateformes Windows et Mac, telles que la vitesse minimale du processeur, le minimum de mémoire et le type de système d’exploitation.
- La vitesse de connexion réseau pour l’accès à Internet
- La liste actuelle des navigateurs pris en charge, ainsi que des liens pour les télécharger
- La liste actuelle des plug-ins de navigateurs, ainsi que des liens pour les télécharger
- Des informations sur l’accès à lnternet
- Le protocole d'inscription à un compte de messagerie de l’école ou de l’entreprise
- Le logiciel requis
Les modèles Smartsheet transforment vos exigences techniques en liste de contrôle fonctionnelle pour gérer n'importe quel projet
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.