Introduction
Il ne faut pas confondre besoins et exigences. Même si à première vue, les deux peuvent vouloir signifier la même chose. Si un besoin est un objectif pas encore satisfait, une exigence, c’est la décision d’entreprendre quelque chose pour réaliser cet objectif.
RADD (Requirement Analysis and Design Definition)
La RADD est la section concernant la classification des exigences et leurs priorisations comme vue par le BABOK.
Elle permet d’avoir un contrôle et une vue d’ensemble sur toutes les fonctionnalités du projet et de connaître l’avancement de celui-ci.
Un PDF joint à cette publication, sous forme de flux de données, résume toutes les tâches, leurs descriptions, les outils, les parties prenantes impliquées, ainsi que des techniques mnémoniques. Il a été réalisé dans un but pédagogique.
Définir une exigence
En regroupant les deux définitions ci-dessus, un besoin devient une exigence dès le moment où il est décidé que celui-ci doit être satisfait.
Et pour aller plus loin, il est possible de dire sans trop se tromper qu’une exigence, c’est :
- une fonctionnalité ou une compétence que quelqu’un a besoin pour résoudre un problème.
- une fonctionnalité ou une compétence qu’une solution doit fournir pour satisfaire un standard ou une spécification.
- une représentation de ladite fonctionnalité ou compétence.
Catégoriser le exigences
Il existe au moins cinq types d’exigences, dont :
- Les exigences de l’entreprise.
- Les exigences des utilisateurs.
- Les exigences de la solution, qui peuvent être diviser en deux autres catégories, les exigences fonctionnelles et non fonctionnelles.
- Les exigences techniques.
- Les exigences de transitions.
Les exigences de l’entreprise
Ce sont les éléments qui doivent être mise en place pour servir les intérêts de l’entreprise.
Les exigences des utilisateurs
Ce sont les éléments dont a besoin un utilisateur pour achever une tâche.
Les exigences des utilisateurs décrivent également les besoins de l’entreprise, ses buts et objectifs, mais d’un point de vue utilisateur.
Lors de leurs rédactions, il faut :
- Ne pas influencer les utilisateurs.
- Obtenir un consensus pour définir l’exigence, si un désaccord devait survenir.
- Prendre tous les avis en compte.
- Essayer de ne pas frustrer les utilisateurs.
Les exigences de la solution
- Elles doivent donner un aperçu de la solution mais pas la définir.
- Ne pas se focaliser sur les exigences d’un logiciel. Cela pourrait aboutir a des fonctionnalités cool, mais pas vraiment nécessaire.
- Rester simple, sans s’emballer sur les fonctionnalités.
- Rester concentrer sur ce que la solution doit réaliser.
Les exigences fonctionnelles
Les exigences fonctionnelles décrivent l’état d’un processus.
- Elles décrivent comment doit se comporter la solution.
- Quelles sont les réponses attendues par la solution ?
- Quelles sont les règles de fonctionnement ?
- Quelles sont les fonctions ou les fonctionnalités ?
- Que doit faire l’utilisateur pour utiliser la solution ?
- Est-ce que le résultat attendu est-il correct ?
Les exigences non fonctionnelles
Type de questions à poser pour définir les exigences non fonctionnelles :
- Est-ce facile à utiliser ?
- Est-ce fiable ?
- Est-ce performant ?
- Est-ce sûre ?
- Est-ce joli ?
- Est-ce que le design est bon ?
- Est-ce intuitif, accessible facilement ?
- Quelles sont les caractéristiques techniques ? Combien de mémoire faut-il pour activer cette fonctionnalité ?
Exigences de transitions
- Peut-on passer de l’état actuel à un nouvel état ?
- Est-ce que le système est redondant ? Peut-on se permettre de le déconnecter un certain temps ?
- Faut-il revoir le matériel ?
- Faut-il penser à former le personnel ?
Exigences de la technologie
Dernière étape à entreprendre quand la solution a été décrite.
- Voir ou revoir le design.
- Voir ou revoir l’architecture.
- Choisir un langage de programmation et coder.
- Savoir où les données seront stockées.
- Savoir comment les données seront affichées.
La technologie devrait toujours avoir un recul sur les données. On peut toujours changer la façon de présenter les données, mais pas les données elles-mêmes.
Écrire les exigences
L’excellence d’une exigence n’a d’égal que sa clarté. Si vous n’avez pas de questions sur une exigence, c’est que c’est parfait.
Une exigence doit :
- Être complète : décrire son but et comment atteindre ce but.
Exemple incomplet : La comptabilité doit pouvoir traiter les dépenses des employés.
Exemple complet : Les superviseurs de la comptabilité doivent pouvoir valider les dépenses soumises par les employés.
Il faut toujours savoir précisément à qui on a affaire. La comptabilité, ce n’est pas assez précis. De même que le verbe “traiter” ne décrit pas l’action, au contraire du verbe “valider”. Les dépenses des employés ne signifient rien, au contraire de celles qui sont soumises qui définissent les dépenses qui ont été saisies par les employés, une note de frais par exemple.
- Être correcte : atteindre le but et répondre aux désirs de l’utilisateur.
Exemple incorrect : Une employée peut changer son nom de famille après un mariage.
Exemple correct : Une employée peut changer son nom de famille après que son changement ait été légalement validé.
- Être sans ambiguïté : Une exigence se doit d’être clair comme le cristal.
Ambiguë : Le dépassement d’heures n’est pas autorisé.
Non ambiguë : Une feuille d’heures de travail qui dépasse les 40h/mois ne sera pas acceptée et sera retournée au consultant pour correction.
- Être vérifiable et testable.
Non vérifiable : Le traitement des commandes doit être capable d’emballer la plupart des commandes dans les 5 minutes.
Vérifiable : Le traitement des commandes doit être capable d’emballer 90% des commandes dans les 5 minutes après réception de la fiche d’exécution.
- Être nécessaire : Elle doit décrire un objectif, pas l’intention d’un utilisateur.
Pas Nécessaire : Le système d’encaissement doit avoir son taux de change mis à jour en temps réel.
Nécessaire : Le système d’encaissement doit avoir son taux de change mis à jour quotidiennement.
- Être faisable : A valider avec l’équipe technique.
Non faisable : Le logiciel de sécurité doit capturer la raison de chaque tentative d’intrusion.
Faisable : Le logiciel de sécurité doit capture la date, l’heure et l’adresse IP de chaque tentative d’intrusion comme indiqué dans les critères de suspicion d’intrusion.
- Priorisée : Selon la valeur, le niveau du risque et la fréquence d’utilisation.
Communiquer les exigences
Il existe mille et un outil pour communiquer les exigences aux autres parties prenantes du projet.
- La plus simple étant bien entendu de le faire dans un tableau de type “Excel” avec la méthode “Kanban”.
| Description de l’exigence | A faire | En cours | A vérifier | Réalisé | Date |
|---|---|---|---|---|---|
| Le système doit pouvoir… | X | ||||
| Le traitement des commandes doit … | X | ||||
| Un client a la possibilité de … | X | 01-01-2010 |
- Il existe des solutions informatiques dont les plus connus sont JIRA et Trello de la société Atlassian.
- On appelle ces applications le backlog. Elles permettent en général de prioriser les exigences et de collaborer avec plusieurs parties prenantes.
Ne rien oublier …
Voici quelques conseils utiles pour ne pas manquer un point qui mériterait que l’on écrive une exigence.
Cascader les exigences à disposition permet de ne rien oublier.
Toujours se poser la question “Quoi ?” permet de définir les exigences du métier ou des parties prenantes.
- Que décrit le besoin de l’entreprise ?
- Quel est le problème principale ? Le couvre-t-on ?
- Quel est l’objectif à atteindre ? Y parvient-t-on ?
- Qu’a-t-on comme informations à disposition pour écrire les exigences ?
Toujours se poser la question “Comment ?” permet de définir les exigences de la solution.
- Comment et où sont stockés les données ?
- Comment le processus est-il exécuté et par qui ou quoi ?
Ceci permet de faire un rapide contrôle des exigences et surtout d’éviter la tentation de se laisser distraire par la technologie.
Les 4 composants principaux
Les exigences sont divisés en 4 groupes d’utilisation :
- Les données.
- Les processus.
- Les agents extérieurs.
- Les règles du métier.
Les données
- La définition des données doit être précise. Il faut préciser leurs origines, leurs buts, leurs fonctions.
- Les données sont stockés, dans la plupart des cas, dans une base de données.
- Les données sont représentés sous leurs formes logiques et physiques dans un diagramme UML.
- Les données sont représentés sous forme de tables, de colonnes. On leur attribue des cardinalités et des relations.
Les processus
Un processus est une action effectuée dans le but d’accomplir une tâche. Il peut être automatique ou manuel.
Exemple : Payer la facture, trouver un docteur régional.
- Pour définir les processus, on utilise des cas d’utilisation (use cases), des anecdotes d’utilisateur (user stories), des diagrammes de flux (data flow).
- Les processus sont décrits par la syntaxe “nom + verbe”.
Les agents externes
Ce sont les premier acteurs ou système, identifiés dans une exigence.
Exemple : Un client doit insérer sa carte bancaire dans le bancomat, entrer son code, le montant désiré, appuyer sur la touche OK, retirer l’argent et sa carte.
- Les acteurs interviennent sur la solution à l’aide d’une interface.
- L’exigence doit inclure la donnée transformée à l’aide d’une interface.
Les règles du métier
Une règle métier définit comment une tâche est effectuée. Les règles définissent l’acteur, le processus et les données. Il faut les écrire de manière détaillées.
Pensez aux exceptions
Un client reçoit un cadeau de fidélité après 90 jours d’inscription. Que se passe-t-il après deux inscriptions de plus de 90 jours avec le même compte.
Pensez aux cardinalités
- Est-il possible de ne pas avoir d’abonnement ?
- Est-il possible de posséder plusieurs abonnement avec le même compte ?
Pensez à l’obligation
- Le mot de passe doit être correct ou la procédure n’ira pas plus loin.
Conclusion
Définir les exigences en fonction des besoins peut prendre beaucoup de temps. La seule tâche qui incombe au BA est d’écrire des exigences qui soient claires et nom ambiguës. Si une exigence laisse un doute quant à son interprétation, alors tout le projet peut se retrouver compromis. Le BA peut se faire aider par les autres parties prenantes, en priorité par les SME. Si le dessin des schémas complexes (UML, BPMN, etc…) peut être réalisé par les gens de la technique, le BA doit les comprendre et pouvoir les communiquer de manière transparente.
Le prochain chapitre va s’articuler autour de la vérification et de la validation de la solution.
