Qu'est-ce que l'analyse et la collecte des exigences dans SDLC?

what is requirement analysis

Ce didacticiel explique ce qu'est l'analyse des exigences, les étapes d'analyse des exigences, les exemples et les objectifs de collecte des exigences dans SDLC:

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

Le produit logiciel est construit selon les exigences 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 avait attendu.

Ce que vous apprendrez:

• Qu'est-ce que l'analyse des besoins?
  • Étapes / étapes de l'analyse des besoins
    • # 1) Rassemblement des exigences
    • # 2) Analyse des exigences collectées
    • # 3) Documenter les exigences analysées
  • Conversion des exigences commerciales en exigences logicielles
  • Comprendre les cas d'exigences non fonctionnelles
  • Différence entre les exigences commerciales et les exigences logicielles
• Conclusion
  • lecture recommandée

Qu'est-ce que l'analyse des besoins?

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

Attente du client / utilisateur final:

Le client / l'utilisateur final reçoit:

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

Cependant, comme vous pouvez le voir, que ce soit une raison quelconque pour une mauvaise livraison de produit, la principale raison est liée à 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 de produit erronée et incomplète au client / utilisateur final.

Une bonne livraison de produit nécessite une collecte correcte des exigences, un examen efficace des exigences rassemblées 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 de l'analyse des besoins

Comme vous pouvez le voir, l'analyse des exigences est la première activité dans SDLC suivie de la spécification fonctionnelle et ainsi de suite. L'analyse des exigences est une étape vitale du SDLC car elle résonne avec les tests d'acceptation qui sont essentiels pour l'acceptation du produit par les clients.

Dans ce didacticiel, 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. Collecte des exigences qui est également appelé comme élicitation.
2. Ceci est suivi de en cours d'analyse les 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) Rassemblement des exigences

Pour s'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 doit être en mesure de définir correctement ses exigences et l'analyste commercial doit ê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 commerciaux du client. Cela peut être dû à une dépendance vis-à-vis de nombreuses personnes par rapport au produit final attendu, aux outils, à l'environnement, etc. Ainsi, il est toujours judicieux d'impliquer toutes les parties prenantes susceptibles d'influencer ou d'être influencées par le produit final.

Le groupe de parties prenantes possibles pourrait être des ingénieurs de la qualité des logiciels (à la fois QC et QA), tout fournisseur tiers qui pourrait fournir une assistance dans le projet, l'utilisateur final à qui 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 de logiciels, etc. pour le développement de produits.

Exemple: Dans une organisation, ils développent un produit ADAS (système de caméra à vision panoramique pour un OEM prestigieux) qui nécessite Pile Autosar et Bootloader binaires reçus d'un autre fournisseur.

Impliquer diverses parties prenantes dans l'étape de collecte des exigences aide à comprendre les différentes dépendances les unes des autres et tout conflit futur éventuel pourrait être évité.

Parfois, il est judicieux 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 communiquer aux clients le produit qu'ils attendent et à quoi il ressemblera 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 produits:

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

(je) Dans le premier cas, il est plus facile de montrer au client à quoi ressemblerait le produit final et comment il serait développé. Dans l'ADAS automobile, il est possible de montrer aux clients un autre produit qui est déjà sur le marché et qui a été développé au sein de l'organisation.

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

Veuillez noter , il n'est pas judicieux de montrer au client le produit / proto produit 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 bagarre juridique inutile.

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

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

(ii) Le deuxième 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 des fonctionnalités ici sont codées en dur dans des programmes logiciels), ou en créant un organigramme ou un diagramme qui pourrait convaincre le client à quoi ressemblerait le produit.

Dans tous les cas, ce serait un répit pour le processus de collecte des exigences car le client sait maintenant ce qu'il veut.

L'analyste commercial peut désormais organiser des réunions formelles d'élicitation des exigences, où toutes les parties prenantes pourraient être invitées et ainsi noter les différentes exigences fournies par le client (dans certains cas, si les parties prenantes sont plus nombreuses, un scribe distinct pourrait être désigné pour noter le client. exigences ou user stories afin que l'analyste commercial puisse se concentrer sur l'animation de la réunion).

Les exigences recueillies peuvent être sous la forme de Histoires d'utilisateurs (en développement agile), des cas d'utilisation, des documents clients en langage naturel, des diagrammes, des organigrammes, etc. Les user stories sont de plus en plus populaires dans le cycle de vie du développement logiciel moderne. Les user stories sont essentiellement un ensemble d'entrées clients dans leur langage naturel.

Exemple de collecte d'exigences: Dans le système de caméra à vision panoramique ADAS, une histoire utilisateur possible pourrait être: «En tant qu'utilisateur, je devrais être en mesure de voir ce qu'il y a dans la vue arrière de ma voiture».

Il pourrait y en avoir beaucoup 'Pourquoi,' questions posées sur chaque user story, qui aideront le client à fournir des informations plus détaillées sur l'exigence.

Dans la user story ci-dessus, si un client dit 'En tant qu'utilisateur, je devrais pouvoir voir ce qu'il y a dans la vue arrière de ma voiture', en posant une question 'Pourquoi 'Pourrait donner' En tant qu'utilisateur, je devrais pouvoir voir ce qu'il y a dans la vue arrière de ma voiture, pour 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.

java comment supprimer un élément d'un tableau

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 collectées

Après la collecte des besoins, l'analyse des besoins commence. À ce stade, divers intervenants s'assoient et organisent une séance de brainstorming. Ils analysent les exigences recueillies et recherchent la faisabilité de leur mise en œuvre. Ils discutent entre eux et toute ambiguïté est dissipée.

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

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

Exemple: Clientspeut demander à faire une vue panoramique du système de caméra avec une fonction de caméra de recul qui aidera à parking la voiture. Le client peut également demander le Bande-annonce fonction d'attelage qui utilise également la caméra arrière pour fonctionner.

Si le client déclare une exigence que la caméra de recul pour parking l'assistance devrait fonctionner à tout moment sans exception, alors le Bande-annonce fonction ne fonctionnerait jamais et vice versa.

(ii) Un analyste commercial peut avoir compris l'exigence de la client différemment de la façon dont un programmeur aurait interprété.

Étant donné que les programmeurs pensent comme des experts techniques, il est toujours possible que les exigences des clients 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 être en suivant une méthode agile de développement logiciel, en suivant 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 découlent de l'analyse des exigences.

Certains d'entre eux sont:

(je) Spécification des exigences du client.

(ii) Exigence d'architecture logicielle.

Exemple:

(iii) Exigence de conception de logiciel.

Exemple:

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

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

(v) Spécification d'exigences non fonctionnelles (c'est-à-dire performances, contraintes, charges, 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».

(nous) Exigences de 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 des outils de gestion des exigences, comme 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 Besoins de l'entreprise à Logiciels requis (fonctionnel et non fonctionnel).

Conversion des exigences commerciales en exigences logicielles

Les exigences commerciales, comme indiqué ci-dessus, sont des exigences de haut niveau qui décrivent 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 basé sur 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 commerciales doivent être décomposées en exigences logicielles plus détaillées qui seront davantage détaillées en 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 user stories détaillées.
2. Dériver un organigramme pour définir le flux des activités.
3. Fournir la condition qui justifie les user stories dérivées.
4. Diagrammes filaires pour expliquer le flux de travail des objets.
5. Définir les exigences non fonctionnelles hors des exigences métier.

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

L'exigence commerciale stipule que «l'utilisateur final doit pouvoir accéder à la boîte de widgets de navigation à partir de l'IHM du système d'infodivertissement et doit pouvoir définir l'adresse de destination».

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

c entretien questions et réponses pdf

# 1) Décomposez les exigences métier de haut niveau en user stories détaillées.

Transformons cette exigence métier en une user story de haut niveau, ' En tant qu'utilisateur, je devrais pouvoir accéder à la boîte du widget de navigation afin de pouvoir saisir l'adresse de destination ». Cette user story raconte ce dont l'utilisateur final a besoin. Nous essaierons de définir comment mettre en œuvre cette exigence.

Commençons par poser des questions éventuelles à cette user story, à savoir.

1. Qui sont les utilisateurs?
2. Comment puis-je accéder à la navigation, à bord (à partir de la carte SD) ou à partir d'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 user stories de niveau plus détaillé dérivées de user stories de haut niveau et nous aideraient à mieux comprendre nos besoins commerciaux.

À ce stade, nous pouvons reprendre l'une des sous-histoires d'utilisateurs et commencer à nous interroger. Prenons (n ​​° 3):

1. Puis-je saisir des entrées de destination telles que les coordonnées géographiques, l'adresse postale, via la reconnaissance vocale, etc.?
2. Ai-je besoin d'un GPS pour saisir 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ériver un organigramme pour définir le flux des activités.

Nous pouvons maintenant voir que l'exigence métier est décomposée 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 user stories dérivées.

Nous pouvons voir que des informations plus détaillées émergent en raison de la décomposition de l'exigence métier de haut niveau en user stories détaillées de bas niveau et dans 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 seconde.
• Le clavier d'entrée de destination doit comporter des caractères alphanumériques et des symboles spéciaux.
• Le bouton d'activation / désactivation du GPS doit être présent sur l'écran de saisie de la destination de navigation.

Les informations ci-dessus satisfont les user stories et permettent de tester l'exigence de manière discrète et mesurable en évitant toute confusion avec l'exigence tout en étant implémentée 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 à partir des exigences commerciales.

Il est impératif que les exigences logicielles détaillées soient dérivées d'exigences commerciales 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 particulière de l'utilisateur.

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 à mesure que plusieurs processus sont fonctionnant en arrière-plan.

À ce stade, si le conducteur appuie sur une interface à écran tactile du système d'infodivertissement pour rejeter un appel entrant via un SMS de réponse automatique (de la même manière que nous le faisons dans nos téléphones mobiles), le système devrait être en mesure d'exécuter cette tâche et ne devrait pas se bloquer ou planter. 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 uniquement par les 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:

Les exigences non fonctionnelles, contrairement aux exigences fonctionnelles, prennent le cycle de vie complet d'un projet pour être implémentées, car elles sont implémentées de manière incrémentielle dans les Sprints Agile 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 commerciales et les exigences logicielles

Nous avons vu ci-dessus comment dériver des exigences logicielles à partir d'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 commerciales sont des exigences de langage naturel de haut niveau pour les clients, 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 besoins est la base 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 conduire à des millions de dollars s'il provenait du marché en tant que rappel (en 2017, le fabricant américain d'airbag chargé, Takata a 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 de documents 5 pourquoi, l'analyse de l'arbre de défaillances, le document 8D, etc.

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

lecture recommandée

• Phases, méthodologies, processus et modèles du SDLC (cycle de vie du développement logiciel)
• Caractéristiques des exigences fonctionnelles et des exigences non fonctionnelles
• Comment tester la spécification des exigences logicielles (SRS)?
• 5 erreurs mortelles dans la gestion des exigences et comment les surmonter
• Comment tester une application sans exigences?
• Mesures pour SSDLC (Secure Software Development Life Cycle)
• Modèle en spirale - Qu'est-ce que le modèle en spirale SDLC?
• Qu'est-ce que le modèle de cascade SDLC?