Qu’Est-Ce Que L’Analyse Et La Collecte Des Exigences Dans SDLC?

Ce Tutoriel Explique Ce Qu’est L’Analyse Des exigences, Les Étapes De L’Analyse Des exigences, Des Exemples Et Les Objectifs de La Collecte des exigences dans SDLC:

Le développement logiciel est une tâche énorme qui crée un produit logiciel fonctionnel.

Le produit logiciel est construit selon l’exigence du client. La plupart du temps, ce produit logiciel est conforme à ce que le client / utilisateur final attendait, alors que parfois ce produit n’est pas entièrement conforme à ce que le client / utilisateur final attendait.

Qu’Est-Ce Que L’Analyse Des Besoins?

Comprenons l’analyse des besoins à l’aide d’un exemple.

Attentes du client/de l’utilisateur final:

Réception du client/utilisateur final:

Car vous pouvez analyser à partir des images ci-dessus qu’il existe une inadéquation entre le produit final et les attentes du client. Cela pourrait être dû à une myriade de raisons, à savoir. mise en œuvre incorrecte des exigences du client, conception défectueuse, mauvaise compréhension des exigences du client par les programmeurs et l’équipe de qualité, etc.

Cependant, comme vous pouvez le voir, qu’il s’agisse d’une raison pour une mauvaise livraison du produit, la raison principale va à l’exigence. Par conséquent, si une compréhension, une capture, une mise en œuvre et des tests corrects des exigences avaient été effectués, cela aurait contribué à atténuer la livraison erronée et incomplète du produit au client / utilisateur final.

Une bonne livraison de produit nécessite une collecte correcte des exigences, un examen efficace des exigences recueillies et enfin une documentation claire des exigences, comme condition préalable. L’ensemble de ce processus est également appelé Analyse des exigences dans le Cycle de vie du développement logiciel (SDLC)

Étapes / étapes d’analyse des exigences

Comme vous pouvez le voir, l’analyse des exigences est la première activité de SDLC suivie de la Spécification fonctionnelle, etc. L’analyse des exigences est une étape essentielle du SDLC car elle entre en résonance avec les tests d’acceptation qui sont essentiels à l’acceptation des produits par les clients.

Dans ce tutoriel, nous expliquerons comment l’analyse des exigences est effectuée dans SDLC. Nous verrons également les différentes étapes impliquées, les résultats, les défis et les mesures correctives dans l’analyse des besoins.

L’analyse des besoins commence par:

1. Rassemblement d’exigences qui est également appelé élicitation.
2. Ceci est suivi par l’analyse des exigences collectées pour comprendre l’exactitude et la faisabilité de la conversion de ces exigences en un produit possible.
3. Et enfin, documenter les exigences collectées.

#1) Collecte des exigences

Pour vous assurer que toutes les étapes mentionnées ci-dessus sont correctement exécutées, des exigences claires, concises et correctes doivent être recueillies auprès du client. Le client devrait être en mesure de définir correctement ses besoins et l’analyste commercial devrait être en mesure de les collecter de la même manière que le client a l’intention de les transmettre.

Souvent, il n’est pas possible que la collecte des exigences soit effectuée efficacement par les analystes métier auprès du client. Cela peut être dû à la dépendance de nombreuses personnes liées au produit final attendu, aux outils, à l’environnement, etc. Ainsi, il est toujours judicieux d’impliquer toutes les parties prenantes qui pourraient influencer ou pourraient être influencées par le produit final.

Le groupe de parties prenantes possibles pourrait être des ingénieurs qualité logiciels (CQ et AQ), tout fournisseur tiers susceptible de fournir un soutien dans le projet, l’utilisateur final auquel le produit est destiné, les programmeurs de logiciels, une autre équipe au sein de l’organisation qui pourrait fournir un module ou une plate-forme logicielle, des bibliothèques logicielles, etc. pour le développement de produits.

Exemple: Dans une organisation, ils développent un produit ADAS (système de caméra surround pour un OEM prestigieux) qui nécessite des binaires de pile Autosar et de chargeur de démarrage reçus d’un autre fournisseur.

La participation de diverses parties prenantes à l’étape de la collecte des exigences aide à comprendre diverses dépendances les unes des autres et tout conflit futur possible pourrait être évité.

Parfois, c’est une bonne idée de créer un modèle prototype du produit prévu prévu, et de le montrer au client. C’est un excellent moyen de transmettre aux clients quel produit s’attendent-ils et à quoi il pourrait ressembler plus tard. Cela aide le client à visualiser le produit qu’il attend et à définir des exigences claires.

Cette création de prototype dépend de deux types de produit:

1. Un produit similaire à l’intention des clients existe au sein de l’organisation.
2. Nouveau produit à développer.

( i) Dans le premier cas, il est plus facile de montrer au client à quoi ressemblerait le produit final et comment il serait développé. Dans les ADA automobiles, il est possible de montrer aux clients un autre produit déjà sur le marché et développé au sein de l’organisation.

Par exemple, Un système de caméra surround développé pour un OEM (GM, Volkswagen, BMW, etc.) et peut être présenté à un autre OEM.

Veuillez noter qu’il n’est pas sage de montrer le produit / produit proto au client en cours de développement car il peut violer l’accord de non-divulgation signé avec un autre client pour lequel ce produit est en cours de développement. Cela peut également entraîner une querelle juridique inutile.

Un autre exemple pourrait être celui du système d’infodivertissement, en cours de développement par l’organisation, et est déjà sur le marché. Les analystes commerciaux et les autres parties prenantes d’une organisation peuvent planifier une démonstration d’atelier pour le client, affichant des systèmes d’infodivertissement avec IHM tangible, des ports de connecteur d’appareil, un bac à sable, etc.

Cela aidera le client à comprendre à quoi ressemblerait le produit final et à répondre beaucoup plus clairement à ses exigences.

(ii) Le second cas peut être réalisé en créant un modèle de travail de base en effectuant un codage et un assemblage simples (la plupart du temps, les fonctionnalités sont codées en dur dans les logiciels), ou en créant un organigramme ou un diagramme qui pourrait convaincre le client de l’apparence du produit.

Dans tous les cas, ce serait une pause pour le processus de collecte des exigences car le client sait maintenant ce qu’il veut.

L’analyste d’affaires peut désormais organiser des réunions formelles de sollicitation des exigences, où toutes les parties prenantes peuvent être invitées et peuvent ainsi noter les différentes exigences fournies par le client (dans certains cas, si les parties prenantes sont plus nombreuses, un scribe séparé pourrait être nommé pour noter les exigences du client ou les histoires d’utilisateurs afin que l’analyste d’affaires puisse se concentrer sur la modération de la réunion).

Les exigences recueillies peuvent prendre la forme d’histoires d’utilisateurs (en développement agile), de cas d’utilisation, de documents en langage naturel client, de diagrammes, d’organigrammes, etc. Les histoires d’utilisateurs deviennent populaires dans le cycle de vie du développement logiciel moderne. Les histoires d’utilisateurs sont essentiellement un ensemble d’entrées client dans leur langage naturel.

Exemple de collecte d’exigences: Dans le système de caméra surround ADAS, une histoire d’utilisateur possible pourrait être: « En tant qu’utilisateur, je devrais pouvoir voir ce qu’il y a dans le rétroviseur de ma voiture ».

Il pourrait y avoir de nombreuses questions « pourquoi » posées sur chaque histoire d’utilisateur, ce qui aidera le client à fournir des informations plus détaillées sur l’exigence.

Dans l’histoire de l’utilisateur ci-dessus, si un client dit « En tant qu’utilisateur, je devrais pouvoir voir ce qu’il y a dans le rétroviseur de ma voiture », en posant une question « pourquoi » pourrait donner « En tant qu’utilisateur, je devrais pouvoir voir ce qu’il y a dans le rétroviseur de ma voiture, afin que je puisse garer ma voiture en toute sécurité ».

Poser la question « pourquoi » aide également à créer des exigences objectives et atomiques à partir d’énormes déclarations en langage naturel données par le client. Cela peut facilement être implémenté plus tard dans le code.

Une autre façon de rassembler l’exigence est sous la forme de cas d’utilisation. Un cas d’utilisation est une approche étape par étape pour atteindre un certain résultat. Cela ne dit pas comment le logiciel fonctionnera sur les entrées de l’utilisateur, mais plutôt ce qui est attendu des entrées de l’utilisateur.

Exemple:

#2) Analyse des exigences recueillies

Après la collecte des exigences, l’analyse des exigences commence. À ce stade, diverses parties prenantes s’assoient et font une séance de remue-méninges. Ils analysent les exigences recueillies et cherchent la faisabilité de les mettre en œuvre. Ils discutent entre eux et toute ambiguïté est résolue.

Cette étape est importante dans le processus d’analyse des besoins pour les principales raisons suivantes:

(i) Le client peut fournir certaines exigences qui pourraient être impossibles à mettre en œuvre en raison de diverses dépendances.

Exemple: Les clients peuvent demander de visualiser le système de caméra avec une fonction de caméra de recul qui aidera à garer la voiture. Le client peut également demander la fonction d’attelage de remorque qui utilise également la caméra arrière pour fonctionner.

Si le client exige que la caméra de recul pour l’aide au stationnement fonctionne en tout temps sans exception, la fonction Remorque ne fonctionnera jamais et vice versa.

( ii) Un analyste commercial aurait pu comprendre l’exigence du client différemment de la façon dont un programmeur aurait interprété.

Étant donné que les programmeurs pensent en tant qu’experts techniques, il est toujours possible que les exigences du client soient incorrectement converties en spécifications fonctionnelles qui seront ensuite incorrectement transformées en documents d’architecture et de conception, puis en code. L’impact est exponentiel et doit donc être vérifié.

Une mesure corrective possible pourrait consister à suivre une méthode agile de développement logiciel, à suivre les cas d’utilisation fournis par le client, etc.

#3) Documenter les exigences analysées

Une fois l’analyse des exigences terminée, la documentation des exigences commence. Différents types d’exigences ressortent de l’analyse des exigences.

Certains d’entre eux sont:

(i) Spécification des exigences du client.

(ii) Exigence relative à l’architecture logicielle.

Exemple:

( iii) Exigence de conception de logiciels.

Exemple:

( iv) Spécification des exigences fonctionnelles (directement dérivées des spécifications du client.)

Exemple :  » Lorsque l’utilisateur appuie sur l’icône Bluetooth de l’IHM d’infodivertissement, l’écran Bluetooth doit s’afficher  »

(v) Spécification d’exigence non fonctionnelle (à savoir. performance, contrainte, charge, etc.).

Exemple: « Il devrait être possible de coupler 15 appareils Bluetooth avec un système d’infodivertissement sans dégradation des performances du système ».

(vi) Configuration requise pour l’interface utilisateur.

Exemple: « Sur l’écran Tuner FM, un bouton doit être fourni pour sélectionner différentes stations »

Les exigences ci-dessus sont enregistrées et documentées dans les outils de gestion des exigences, tels que IBM DOORS, HP QC. Parfois, les organisations ont leurs outils de gestion des exigences sur mesure pour réduire les coûts.

Examinons maintenant le processus de conversion des exigences métier en Exigences logicielles (fonctionnelles et non fonctionnelles).

Conversion des Exigences Métier En Exigences logicielles

Les exigences métier, comme indiqué ci-dessus, sont des exigences de haut niveau qui parlent de ce que l’utilisateur final attend d’une action définie sur le système logiciel. Le développement de l’ensemble du système logiciel sur la base de ces exigences n’est pas possible car une description détaillée de la façon dont le système logiciel ou le composant sera mis en œuvre n’est pas mentionnée.

Ainsi, les exigences métier doivent être ventilées sur des exigences logicielles plus détaillées qui seront plus détaillées sur les exigences fonctionnelles et non fonctionnelles.

Pour ce faire, les étapes suivantes peuvent être suivies:

1. Décomposez les exigences métier de haut niveau en histoires d’utilisateurs détaillées.
2. Dérivation d’un organigramme pour définir le flux des activités.
3. Fournissant la condition qui justifie les user stories dérivées.
4. Diagrammes filaires pour expliquer le flux de travail des objets.
5. Définition des exigences non fonctionnelles hors des exigences métier.

Commençons par prendre un exemple de système d’infodivertissement automobile.

L’exigence métier dit: « L’utilisateur final devrait pouvoir accéder à la boîte de widget de navigation à partir de l’IHM du système d’infodivertissement et devrait pouvoir définir l’adresse de destination ».

Ainsi, les étapes ci-dessus peuvent être implémentées comme:

#1) Décomposez les exigences métier de haut niveau en histoires d’utilisateurs détaillées.

Convertissons cette exigence métier en une histoire d’utilisateur de haut niveau, « En tant qu’utilisateur, je devrais pouvoir accéder à la boîte de widget de navigation afin de pouvoir entrer l’adresse de destination ». Cette histoire d’utilisateur raconte ce dont l’utilisateur final a besoin. Nous allons essayer de définir comment mettre en œuvre cette exigence.

Commençons par poser des questions possibles à cette histoire d’utilisateur à savoir.

1. Qui sont les utilisateurs ?
2. Comment accéder à la navigation, à bord (depuis une carte SD) ou depuis un SmartPhone ?
3. Quel type d’entrées de destination puis-je saisir ?
4. Dois-je être autorisé à entrer dans la destination même lorsque la voiture est en stationnement?

Ce sont des histoires d’utilisateurs de niveau plus détaillées dérivées d’histoires d’utilisateurs de haut niveau et nous aideraient à mieux comprendre nos besoins commerciaux.

À ce stade, nous pouvons reprendre l’une des sous-histoires de l’utilisateur et commencer à nous interroger. Prenons (non. 3):

1. Puis-je entrer des entrées de destination comme les coordonnées Géographiques, l’adresse postale, via la reconnaissance vocale, etc.?
2. Ai-je besoin d’un GPS pour entrer les coordonnées géographiques?
3. Puis-je saisir l’adresse de destination actuelle en effectuant une recherche dans l’historique des adresses ?

#2) Dérivation d’un organigramme pour définir le flux d’activités.

Maintenant, nous pouvons voir que les exigences métier sont ventilées en cas d’utilisation très détaillés qui peuvent être marqués dans l’organigramme comme ci-dessous:

#3) Fournir des conditions qui justifient les histoires d’utilisateurs dérivées.

Nous pouvons voir que des informations plus détaillées émergent en raison de la décomposition des besoins métier de haut niveau en histoires d’utilisateurs détaillées de bas niveau et de l’organigramme. À partir de cet organigramme, nous pouvons obtenir les détails techniques nécessaires à la mise en œuvre, à savoir.

• Le temps de chargement de l’écran pour afficher l’entrée de destination doit être de 1 sec.
• Le clavier d’entrée de destination doit comporter des caractères alphanumériques et des symboles spéciaux.
• Le bouton bascule activer/désactiver le GPS doit être présent sur l’écran d’entrée de destination de navigation.

Les informations ci-dessus satisfont les histoires d’utilisateurs et permettent de tester l’exigence de manière discrète et mesurable en évitant toute confusion avec l’exigence lors de sa mise en œuvre en tant que fonctionnalités.

#4) Diagrammes filaires pour expliquer le flux de travail des objets.

À partir du cas d’utilisation ci-dessus, nous dériverons un diagramme filaire qui rendra l’interface utilisateur plus claire.

#5) Définition des exigences non fonctionnelles hors des exigences métier.

Il est impératif que les exigences logicielles détaillées soient dérivées des exigences métier de haut niveau, mais souvent, seules les exigences fonctionnelles sont identifiées qui indiquent comment un système se comportera face à une entrée / action utilisateur particulière.

Cependant, les exigences fonctionnelles ne clarifient pas les performances des systèmes et d’autres paramètres qualitatifs tels que la disponibilité, la fiabilité, etc.

Exemples:

a) Nous prendrons l’exemple du système d’infodivertissement automobile ci-dessus.

Si le conducteur (utilisateur final) de la voiture lit de la musique à partir de l’USB et que le guidage de navigation est en cours, reçoit également un appel entrant via Bluetooth en mode Mains libres, la charge sur le processeur et la consommation de RAM augmente à un niveau maximum car plusieurs processus s’exécutent en arrière-plan.

À ce stade, si le conducteur appuie sur une interface tactile du système d’infodivertissement pour rejeter un appel entrant via SMS à réponse automatique (de la même manière que nous le faisons sur nos téléphones mobiles), le système devrait être en mesure d’effectuer cette tâche et ne devrait pas se bloquer ou tomber en panne. C’est la performance du système lorsque la charge est élevée et que nous testons la disponibilité et la fiabilité.

b) Un autre cas est le scénario de stress.

Prenons un exemple, le système d’infodivertissement reçoit des SMS dos à dos (peut-être 20 SMS en 10 secondes) via un téléphone Bluetooth connecté. Le système d’infodivertissement doit être capable de gérer tous les SMS entrants et à aucun moment ne doit manquer la notification SMS entrante sur l’IHM d’Infodivertissement.

Les exemples ci-dessus sont des cas d’exigences non fonctionnelles qui n’ont pas pu être testées par les seules exigences fonctionnelles. Bien que parfois, les clients manquent de fournir ces exigences non fonctionnelles. Il est de la responsabilité de l’organisation de leur fournir ces informations, lorsqu’un produit est livré au client.

Comprendre les cas d’exigences non fonctionnelles

Le tableau ci-dessous explique les exigences non fonctionnelles:

Exigences non fonctionnelles, contrairement aux exigences fonctionnelles, prenez le cycle de vie complet d’un projet pour être implémenté, car ils sont implémentés progressivement dans des sprints Agiles respectifs ou dans différentes itérations.

C’est ainsi que nous dérivons les Exigences logicielles des Exigences métier.

Différence Entre Les Exigences Métier Et Les Exigences Logicielles

Nous avons vu ci-dessus comment dériver les exigences Logicielles des exigences Métier de haut niveau. Les exigences logicielles permettent au programmeur et à l’ingénieur de test de développer le système et de le tester efficacement. Ainsi, nous savons maintenant que les exigences métier sont des exigences de langage naturel client de haut niveau, tandis que les exigences logicielles sont des exigences détaillées de bas niveau qui aident à la mise en œuvre du système logiciel.

Examinons la différence détaillée entre les deux types d’exigences.

Conclusion

L’analyse des exigences est l’épine dorsale de tout modèle SDLC.

Un problème manqué lors de l’analyse des besoins et détecté lors des tests unitaires pourrait coûter des dizaines de milliers de dollars à une organisation et ce coût pourrait entraîner des millions de dollars s’il provient du marché comme rappel (en 2017, le fabricant américain d’airbags Takata a infligé une amende de 1 milliard de dollars en raison de l’explosion des airbags).

L’organisation finirait par effectuer des tâches de contrôle des dommages telles que l’analyse des causes profondes, la préparation des documents 5 pourquoi, l’analyse de l’arbre des pannes, le document 8D, etc. au lieu de se concentrer sur le développement de logiciels et la qualité.

Dans le pire des cas, l’organisation serait entraînée dans des poursuites judiciaires intentées par le client si la fonctionnalité affectée est liée à la sécurité / sécurité, comme l’accès de sécurité, l’airbag, l’ABS (système de freinage antiblocage), etc.