Analyse des exigences logicielles avec exemple
Charles Moore
Par exemple, dans le contexte d'une application bancaire, l'exigence fonctionnelle sera que lorsque le client sélectionne « Afficher le solde », il doit pouvoir consulter le dernier solde de son compte.
L’exigence logicielle peut également être non fonctionnelle, elle peut être une exigence de performance. Par exemple, une exigence non fonctionnelle est que chaque page du système soit visible par les utilisateurs dans un délai de 5 secondes.
Donc en gros l'exigence logicielle est un
- Fonctionnel ou
- Non fonctionnel
need qui doit être implémenté dans le système. Les exigences logicielles sont généralement exprimées sous forme de déclarations.
Types d'exigences
- Besoins de l'entreprise: Il s'agit d'exigences de haut niveau tirées de l'analyse de rentabilisation des projets. Par exemple, un système de services bancaires mobiles fournit des services bancaires en Asie du Sud-Est. L'exigence commerciale décidée pour l'Inde est le récapitulatif du compte et le transfert de fonds, tandis que pour la Chine, le récapitulatif du compte et le paiement des factures sont décidés comme une exigence commerciale.
| Pays | Entreprise fournissant des fonctionnalités ou des services bancaires |
|---|---|
| Inde | Sommaire du compte et transfert de fonds |
| Chine | Sommaire du compte et Bill Paiement |
- ArchiExigences structurelles et de conception: Ces exigences sont plus détaillées que les exigences métier. Il détermine la conception globale requise pour mettre en œuvre les exigences commerciales. Pour notre organisation éducative, les cas d'utilisation de l'architecture et de la conception seraient la connexion, les détails du cours, etc. L'exigence serait celle indiquée ci-dessous.
| Cas d'utilisation bancaire | Exigence |
|---|---|
| Bill Paiement | Ce cas d'utilisation décrit comment un client peut se connecter à Net Banking et utiliser le Bill Facilité de paiement.
Le client pourra voir un tableau de bord des factures impayées des émetteurs de factures enregistrés. Il peut ajouter, modifier et supprimer les coordonnées d'un émetteur de factures. Le client peut configurer des alertes SMS, email pour différentes actions de facturation. Il peut voir l’historique des factures payées antérieurement. Les acteurs qui démarrent ce cas d’utilisation sont les clients de la banque ou le personnel de support. |
- Exigences du système et de l'intégration:Au niveau le plus bas, nous avons les exigences du système et de l'intégration. Il s'agit d'une description détaillée de chaque exigence. Cela peut se présenter sous la forme d'histoires d'utilisateurs qui décrivent en réalité le langage professionnel quotidien. Les exigences sont très détaillées afin que les développeurs puissent commencer à coder. Voici un exemple de Bill Module de paiement où la condition sera mentionnée pour l'ajout d'un Biller
| Bill Paiement | Exigences |
|---|---|
| Ajouter BillERS |
|
Parfois, pour certains projets, vous ne recevrez aucune exigence ou aucun document avec lequel travailler. Mais il existe néanmoins d'autres sources d'exigences que vous pouvez prendre en compte pour les exigences ou les informations, afin de pouvoir baser la conception de votre logiciel ou de vos tests sur ces exigences. Les autres sources d'exigences sur lesquelles vous pouvez compter sont donc
Autres sources d'exigences
- Transfert de connaissances de collègues ou d'employés travaillant déjà sur ce projet
- Parler du projet à l'analyste commercial, au chef de produit, au chef de projet et aux développeurs
- Analyser la version précédente du système déjà implémentée dans le système
- Analyser l'ancien document d'exigences du projet
- Consultez les rapports de bogues passés, certains rapports de bogues sont transformés en demandes d'amélioration qui peuvent être implémentées dans la version actuelle.
- Consultez le guide d'installation s'il est disponible pour voir quelle est l'installation requise
- Analyser le domaine ou les connaissances de l'industrie que l'équipe essaie de mettre en œuvre
Quelle que soit la source d'exigences que vous recevez, assurez-vous de les documenter sous une forme quelconque, faites-les examiner par d'autres membres de l'équipe expérimentés et compétents.
Comment analyser les exigences
Prenons l'exemple d'un système logiciel éducatif dans lequel un étudiant peut s'inscrire à différents cours.
Étudions comment analyser les exigences. Les exigences doivent maintenir une qualité standard de leur exigence, différents types de qualité d'exigence comprennent
- Atomic
- Identifié de manière unique
- Complété
- Cohérent et sans ambiguïté
- Traçable
- Priorisé
- Testable
Comprenons cela avec un exemple, il y a trois colonnes dans le tableau présenté ici,
- La première colonne indique « qualité des exigences »
- La deuxième colonne indique « mauvaise exigence avec un problème »
- La troisième colonne est la même que la deuxième colonne mais – « convertie en une bonne exigence ».
| Exigence Qualité | Exemple de mauvaise exigence | Exemple de bonne exigence |
|---|---|---|
| Atomic |
|
|
| Identifié de manière unique | 1- Les étudiants pourront s'inscrire à des cours de premier cycle1- Les étudiants pourront s'inscrire à des cours de troisième cycle |
|
| Complété | Un utilisateur professeur se connectera au système en fournissant son nom d'utilisateur, son mot de passe et d'autres informations pertinentes. | Un utilisateur professeur se connectera au système en fournissant son nom d'utilisateur, son mot de passe et son code de département. |
| Cohérent et sans ambiguïté | Un étudiant suivra soit des cours de premier cycle, soit des cours de troisième cycle, mais pas les deux. Certains cours seront ouverts aux étudiants de premier cycle et de troisième cycle. | Un étudiant aura soit un diplôme de premier cycle, soit un diplôme de troisième cycle, mais pas les deux. |
| Traçable | Maintenir les informations sur les étudiants mappées à l'ID de demande BRD ? | Conserver les informations sur les étudiants - Mappées sur l'ID de demande BRD 4.1 |
| Priorisé | Étudiant inscrit-Priorité 1Maintenir les informations sur l'utilisateur-Priorité 1S'inscrire aux cours-Priorité 1Afficher le bulletin scolaire-Priorité 1 | Inscrire l'étudiant-Priorité 1Gérer les informations sur l'utilisateur-Priorité 2Inscrire des cours-Priorité 1Afficher le bulletin scolaire-Priorité3 |
| Testable | Chaque page du système se chargera dans un délai acceptable | Les pages d'inscription des étudiants et d'inscription aux cours du système se chargeront dans les 5 secondes. |
Voyons maintenant en détail chacune de ces exigences, en commençant par Atomci.
Atomic
Ainsi, chacune de vos exigences doit être atomique, ce qui signifie qu'elle doit être à un niveau de détail très bas et qu'il ne doit pas être possible de la séparer en composants. Nous allons voir ici les deux exemples d'exigences, à Atomniveaux d’exigences uniques et identifiés.
Continuons donc avec l'exemple de construction de système pour le domaine de l'éducation. Ici, la mauvaise exigence est « Les étudiants pourront s’inscrire à des cours de premier cycle et de troisième cycle ». C’est une mauvaise exigence car elle n’est pas atomique car elle parle de deux entités différentes : cours de premier cycle et cours de troisième cycle. Donc, évidemment, ce n'est pas une bonne exigence mais une mauvaise exigence, donc une bonne exigence de correspondance serait de la séparer en deux exigences. Ainsi, l’un parle des inscriptions aux cours de premier cycle tandis que l’autre parle des inscriptions aux cours de troisième cycle.
Identifié de manière unique
De même, la qualité de l'exigence suivante consiste à vérifier l'identification unique. Ici, nous avons deux exigences distinctes mais elles ont toutes les deux le même ID n°1. Ainsi, si nous faisons référence à notre exigence en référence à l'ID#, mais qu'il n'est pas clair à quelle exigence exacte nous faisons référence au document ou à une autre partie du système, car les deux ont le même ID#1. Donc, en se séparant avec des identifiants uniques, une bonne exigence sera donc de revenir en tant qu'inscriptions aux cours de la section 1, et elle a deux exigences : 1.1 l'identifiant est l'inscription aux cours de premier cycle tandis que 1.2 l'identifiant est l'inscription aux cours de troisième cycle.
Complété
De plus, chaque exigence doit être remplie. Par exemple, ici, la mauvaise exigence dit qu'un « utilisateur professeur se connectera au système en fournissant son nom d'utilisateur, son mot de passe et d'autres informations pertinentes ». Ici, les autres informations pertinentes ne sont pas claires, elles doivent donc être énoncées de manière satisfaisante pour que l'exigence soit complète.
Cohérent et sans ambiguïté
Ensuite, chaque exigence doit être cohérente et sans ambiguïté, donc ici par exemple nous avons des exigences "Un étudiant aura soit des cours de premier cycle, soit des cours de troisième cycle, mais pas les deux". Il s'agit d'une exigence, il y a une autre exigence qui dit "Certains cours seront être ouvert aux étudiants du premier cycle et du troisième cycle ».
Le problème de cette exigence est que, d'après la première exigence, il semble que les cours soient divisés en deux catégories: cours d'études supérieures et cours de troisième cycle, et les étudiants peuvent choisir l'une des deux, mais pas les deux. Mais lorsque vous lisez une autre exigence, cela entre en conflit avec la première exigence et indique que certains cours seront ouverts à la fois aux étudiants de troisième cycle et de premier cycle.
Il est donc évident de transformer cette mauvaise exigence en bonne exigence : « Un étudiant aura soit des cours de premier cycle, soit des cours de troisième cycle, mais pas les deux ». Ce qui signifie que chaque cours sera marqué comme étant un cours de premier cycle ou un cours de troisième cycle.
Traçable
Chaque exigence doit être traçable car il existe déjà différents niveaux d'exigence, nous avons déjà vu qu'en haut nous avions des exigences commerciales, puis nous avons des exigences d'architecture et de conception suivies par des exigences d'intégration de système.
Désormais, lorsque nous convertissons les exigences commerciales en exigences architecturales et de conception ou que nous convertissons les exigences architecturales et de conception en exigences d'intégration de systèmes, il doit y avoir une traçabilité. Ce qui signifie que nous devrions être en mesure de prendre en compte chaque exigence commerciale et de la mapper à une ou plusieurs exigences d'architecture et de conception logicielles correspondantes. Voici donc un exemple de mauvaise exigence qui dit « Conserver les informations sur les étudiants – mappées à l'ID de demande BRD ? » l'identifiant de l'exigence n'est pas indiqué ici.
Donc, en le convertissant en une bonne exigence, cela dit la même chose mais il est mappé avec l'ID d'exigence 4.1. La cartographie devrait donc être là pour chaque exigence. De la même manière que nous avons des exigences de mappage de haut niveau et de bas niveau, le mappage existe également entre le système et l'exigence d'intégration avec le code qui implémente cette exigence et il existe également un mappage entre le système et l'exigence d'intégration avec le scénario de test qui teste cette exigence particulière. .
Cette traçabilité s'étend donc sur l'ensemble du projet
Priorisé
| Priorisé | Étudiant inscrit-Priorité 1 Conserver les informations utilisateur – Priorité 1 S'inscrire aux cours-Priorité 1 Afficher le bulletin scolaire – Priorité 1 |
Inscrire étudiant-Priorité 1 Conserver les informations utilisateur – Priorité 2 S'inscrire aux cours-Priorité 1 Afficher le bulletin scolaire-Priorité3 |
Ensuite, chaque exigence doit être hiérarchisée, afin que l'équipe ait une ligne directrice quant à l'exigence à mettre en œuvre en premier et à celle qui peut être réalisée plus tard. Ici, vous pouvez voir que la mauvaise priorité est d'inscrire l'étudiant, de conserver les informations sur les utilisateurs et que chaque exigence a donné la priorité à 1. Tout ne peut pas avoir la même priorité, les exigences peuvent donc être priorisées. Ainsi, l'exemple de bonne exigence ici est que l'inscription de l'étudiant et l'inscription aux cours reçoivent la priorité la plus élevée 1, tandis que la maintenance des informations sur l'utilisateur vient en dessous de la priorité 2, puis nous avons l'affichage du bulletin de notes en priorité 3.
Testable
| Testable | Chaque page du système se chargera dans un délai acceptable | Les pages d'inscription des étudiants et d'inscription aux cours du système se chargeront dans les 5 secondes. |
Chaque exigence doit être testable, ici la mauvaise exigence est « chaque page du système se chargera dans un délai acceptable ». Maintenant, cette exigence pose deux problèmes : le premier est que chaque page signifie qu'il peut y avoir plusieurs pages, ce qui va faire exploser les efforts de test. L'autre problème est qu'il est indiqué que la page va se charger dans un délai acceptable, maintenant quel est le délai acceptable ? Acceptable pour qui. Nous devons donc convertir l'argument non testable en un argument testable, qui indique spécifiquement de quelle page nous parlons « pages d'inscription des étudiants et d'inscription aux cours » et le délai acceptable est également donné, qui est de 5 secondes.
Pour aller plus loin
C’est donc ainsi que nous devons examiner chaque exigence au niveau approprié. Par exemple, si nous allons créer un logiciel en ce qui concerne les exigences du système et d'intégration. Nous devons examiner les exigences système et d'intégration indiquées dans les spécifications des exigences logicielles ou les user stories et les appliquer à chaque qualité d'exigence. Vérifiez ensuite si chaque exigence est atomique, identifiée de manière unique et complète, etc.