Planification de bonnes exigences
Alors, qu'est-ce qui fait une bonne exigence? Une bonne exigence doit être utile et exploitable; il doit définir un besoin et fournir une voie vers une solution. Tout le monde dans l'équipe doit comprendre ce que cela signifie. Les exigences varient en complexité.
Un bon document d'exigences peut faire partie d'un groupe avec des exigences de haut niveau décomposées en sous-exigences.
Ils peuvent également inclure des spécifications très détaillées qui incluent un ensemble d'exigences fonctionnelles décrivant le comportement ou les composants du produit final.
Les bonnes exigences doivent être concises et spécifiques et doivent répondre à la question «de quoi avons-nous besoin?» Plutôt que «comment répondre à un besoin?»
De bonnes exigences garantissent que toutes les parties prenantes comprennent leur part du plan; si les pièces ne sont pas claires ou mal interprétées, le produit final peut être défectueux ou tomber en panne.
La prévention des échecs ou des interprétations erronées des exigences peut être facilitée en recevant des commentaires de l'équipe en continu tout au long du processus à mesure que les exigences évoluent. Une collaboration continue et l'adhésion de tous sont la clé du succès.
Collecte et analyse des exigences
Une exigence est une condition ou une capacité dont une partie prenante a besoin pour résoudre un problème ou atteindre un objectif organisationnel; une condition ou une capacité qui doit être remplie ou possédée par un système.
L'analyse des exigences en génie logiciel couvre les tâches qui entrent dans la détermination des besoins ou des conditions à satisfaire pour un produit nouveau ou modifié en tenant compte des éventuelles exigences conflictuelles de diverses parties prenantes, l'analyse, la documentation, la validation et la gestion des exigences logicielles ou système.
Les exigences devraient être -
- Documented
- Actionable
- Measurable
- Testable
- Traceable
Les exigences doivent être liées aux besoins ou aux opportunités métier identifiés et définies avec un niveau de détail suffisant pour la conception du système.
Un analyste d'affaires recueille des informations en observant les systèmes existants, en étudiant les procédures existantes, en discutant avec les clients et les utilisateurs finaux. L'analyste doit également avoir des compétences imaginatives et créatives en l'absence d'un système fonctionnel. L'analyse des exigences collectées pour trouver les liens manquants est une analyse des exigences.
Approche de sollicitation
Pour obtenir les objectifs, posez les questions suivantes à l'expert métier, au responsable du développement et au parrain du projet:
Quels objectifs commerciaux de l'entreprise ce projet contribuera-t-il à atteindre?
Pourquoi faisons-nous ce projet maintenant?
Que se passera-t-il si nous le faisons plus tard?
Et si nous ne le faisons pas du tout?
Qui bénéficiera de ce projet?
Est-ce que les personnes qui en bénéficieront la considèrent comme l’amélioration la plus importante qui puisse être apportée à ce stade?
Devrions-nous plutôt faire un projet différent?
Les objectifs possibles pourraient être la réduction des coûts, l'amélioration du service client, la simplification du flux de travail, le remplacement d'une technologie obsolète, le pilotage d'une nouvelle technologie et bien d'autres. Assurez-vous également de bien comprendre comment le projet proposé aidera à atteindre l'objectif déclaré.
Différents types d'exigences
Les types d'exigences les plus courants qui intéressent un analyste commercial sont les suivants:
Besoins de l'entreprise
Les exigences métier sont les activités critiques d'une entreprise qui doivent être réalisées pour atteindre les objectifs organisationnels tout en restant indépendant de la solution. Un document des exigences commerciales (BRD) détaille la solution commerciale d'un projet, y compris la documentation des besoins et des attentes des clients.
Besoins des utilisateurs
Les exigences de l'utilisateur doivent spécifier les exigences spécifiques que l'utilisateur attend / souhaite que le logiciel soit construit à partir du projet logiciel. Une exigence d'un utilisateur doit être vérifiable, claire et concise, complète, cohérente, traçable, viable.
Le document des exigences de l'utilisateur (URD) ou la spécification des exigences de l'utilisateur est un document généralement utilisé en génie logiciel qui spécifie ce que l'utilisateur s'attend à ce que le logiciel soit capable de faire.
Configuration requise
Les exigences système concernent la définition des exigences en matière de ressources logicielles et des prérequis qui doivent être installés sur un ordinateur pour assurer le fonctionnement optimal d'une application.
Exigences fonctionnelles
Les exigences fonctionnelles capturent et spécifient le comportement spécifique prévu du système en cours de développement. Ils définissent des éléments tels que les calculs du système, la manipulation et le traitement des données, l'interface utilisateur et l'interaction avec l'application, et d'autres fonctionnalités spécifiques qui montrent comment les besoins des utilisateurs sont satisfaits. Attribuez un numéro d'identification unique à chaque exigence.
Prérogatives non fonctionnelles
L'exigence non fonctionnelle est celle qui spécifie des critères qui peuvent être utilisés pour juger du fonctionnement d'un système plutôt que des comportements spécifiques. L'architecture du système parle du plan de mise en œuvre des exigences non fonctionnelles.
Les exigences non fonctionnelles parlent de la façon dont le système devrait ressembler ou peuvent être mentionnées comme «le système doit être». Les exigences non fonctionnelles sont appelées qualités du système.
Exigences de transition
Les exigences de transition décrivent les capacités que la solution doit remplir afin de faciliter la transition de l'état actuel de l'entreprise à l'état futur souhaité, mais qui ne seront pas nécessaires une fois la transition terminée.
Ils se distinguent des autres types d'exigences, car ils sont toujours de nature temporaire et parce qu'ils ne peuvent pas être développés tant qu'une solution existante et nouvelle n'est pas définie. Ils couvrent généralement la conversion de données à partir de systèmes existants, les lacunes de compétences qui doivent être comblées et d'autres changements connexes pour atteindre l'état futur souhaité. Ils sont développés et définis par l'évaluation et la validation de la solution.
Traçabilité et gestion du changement
La traçabilité des exigences est un moyen d'organiser, de documenter et de suivre toutes vos exigences, de la génération de l'idée initiale à la phase de test.
La matrice de capacité de suivi des exigences (RTM) fournit une méthode de suivi des exigences fonctionnelles et de leur mise en œuvre tout au long du processus de développement. Chaque exigence est incluse dans la matrice avec son numéro de section associé.
Au fur et à mesure de l'avancement du projet, le RIM est mis à jour pour refléter l'état de chaque exigence. Lorsque le produit est prêt pour le test du système, la matrice répertorie chaque exigence, quel composant du produit y répond et quel test vérifie qu'il est correctement implémenté
Inclure des colonnes pour chacun des éléments suivants dans le RTM -
- Description de l'exigence
- Référence de l'exigence dans FRD
- Méthode de vérification
- Référence d'exigence dans le plan de test
Example- Reliez les points pour identifier les relations entre les éléments de votre projet. C'est un connecteur de flux aval commun.
Idée Exigences Conception Test Objectifs commerciaux
Vous devez être en mesure de retracer chacune de vos exigences jusqu'à son objectif commercial d'origine.
En traçant les exigences, vous pouvez identifier les changements d'effets d'entraînement, voir si une exigence a été remplie et si elle est testée correctement. La traçabilité et la gestion du changement apportent aux managers la tranquillité d'esprit et la visibilité nécessaire pour anticiper les problèmes et assurer une qualité continue.
Assurance qualité
Réaliser correctement les exigences du premier coup peut se traduire par une meilleure qualité, des cycles de développement plus rapides et une plus grande satisfaction des clients à l'égard du produit. La gestion des exigences vous aide non seulement à bien faire les choses, mais aide également votre équipe à économiser de l'argent et de nombreux maux de tête tout au long du processus de développement.
Des exigences concises et spécifiques peuvent vous aider à détecter et à résoudre les problèmes tôt, plutôt que plus tard, lorsqu'ils sont beaucoup plus coûteux à résoudre. De plus, cela peut coûter jusqu'à100 times plus pour corriger un défaut plus tard dans le processus de développement après son codage, que pour corriger tôt tout en étant une exigence.
En intégrant la gestion des exigences dans votre processus d'assurance qualité, vous pouvez aider votre équipe à gagner en efficacité et à éliminer les retouches. De plus, la reprise est là où se produisent la plupart des problèmes de coût.
En d'autres termes, les équipes de développement gaspillent la majorité de leurs budgets sur des efforts qui ne sont pas exécutés correctement la première fois. Par exemple, un développeur code une fonctionnalité sur la base d'un ancien document de spécification, pour savoir plus tard, que les exigences pour cette fonctionnalité ont changé. Ces types de problèmes peuvent être évités grâce aux meilleures pratiques efficaces de gestion des exigences.
En résumé, la gestion des exigences peut sembler une discipline complexe, mais lorsque vous la résumez à un concept simple, il s'agit d'aider les équipes à répondre à la question: «Tout le monde comprend-il ce que nous construisons et pourquoi?» Des analystes commerciaux, chefs de produit et chefs de projet aux développeurs, responsables de l'assurance qualité et testeurs, en passant par les parties prenantes et les clients impliqués - si souvent la cause première de l'échec d'un projet est une mauvaise compréhension de la portée du projet.
Lorsque tout le monde collabore et dispose d'un contexte et d'une visibilité complets sur les discussions, les décisions et les changements liés aux exigences tout au long du cycle de vie du projet, c'est lorsque le succès se produit de manière cohérente et que vous maintenez une qualité continue. De plus, le processus est plus fluide avec moins de frictions et de frustration en cours de route pour toutes les personnes impliquées.
Note- La recherche a montré que les équipes de projet peuvent éliminer 50 à 80% des défauts du projet en gérant efficacement les exigences. Selon l'institut de génie logiciel Carnegie Mellon, «60 à 80% du coût du développement logiciel est en cours de retouche.»
Obtention de l'approbation des exigences
L'approbation des exigences officialise l'accord des parties prenantes du projet que le contenu et la présentation des exigences, tels que documentés, sont exacts et complets. Un accord formel réduit le risque que, pendant ou après la mise en œuvre, une partie prenante introduise une nouvelle exigence (auparavant non rencontrée).
L'obtention de l'approbation des exigences implique généralement un examen final en face à face des exigences, tel que documenté, avec chaque partie prenante du projet. À la fin de chaque examen, l'intervenant est invité à approuver formellement le document d'exigences examiné. Cette approbation peut être enregistrée physiquement ou électroniquement.
L'obtention de l'approbation des exigences est généralement la dernière tâche de la communication des exigences. L'analyste d'affaires exigera les résultats des examens des exigences formelles, y compris la prise en compte de tous les commentaires ou objections soulevés au cours du processus d'examen.