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
- 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 |
|
| 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.
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 tracCโest possible car il existe dรฉjร diffรฉrents niveaux dโexigences ; nous avons dรฉjร vu quโau sommet, nous avions les exigences mรฉtier, puis les exigences architecturales et de conception, suivies des exigences dโintรฉgration du systรจme.
Lorsque nous convertissons les exigences mรฉtier en exigences architecturales et de conception, ou que nous convertissons les exigences architecturales et de conception en exigences d'intรฉgration systรจme, il doit y avoir tracCapacitรฉ. Cela signifie que nous devons pouvoir associer chaque exigence mรฉtier ร une ou plusieurs exigences d'architecture et de conception logicielle correspondantes. Voici un exemple d'exigence mal formulรฉe : ยซ Gรฉrer les informations des รฉtudiants โ associรฉ ร l'identifiant de l'exigence BRD ? ยป L'identifiant de l'exigence n'est pas indiquรฉ.
En le convertissant en une exigence valide, le message reste le mรชme, mais il est associรฉ ร l'identifiant d'exigence 4.1. Donc, mapperping Il devrait y en avoir pour chaque besoin. De la mรชme maniรจre que nous avons des cartes de haut niveau et de bas niveau.ping exigence, la carteping Il existe รฉgalement une correspondance entre les exigences systรจme et d'intรฉgration et le code qui met en ลuvre ces exigences, ainsi qu'une cartographie.ping entre le systรจme et les exigences d'intรฉgration et le cas de test qui teste cette exigence particuliรจre.
Donc, ce tracLa capacitรฉ est prรฉsente dans 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.
Conclusion
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.
