Analyse des exigences logicielles avec exemple
Charles Moore
⚡ Résumé intelligent
L'analyse des exigences logicielles décompose les besoins des parties prenantes en énoncés fonctionnels et non fonctionnels, les classe aux niveaux métier, architectural et système, puis vérifie chacun d'eux par rapport à des attributs de qualité afin de garantir un produit testable. tracspécification possible et priorisée.
Une exigence logicielle est un besoin fonctionnel ou non fonctionnel qui doit être implémenté dans le système. Fonctionnel signifie fournir un service particulier à l'utilisateur.
Par exemple, dans le contexte d'une application bancaire, l'exigence fonctionnelle est que lorsqu'un client sélectionne « Voir le solde », il puisse consulter le solde de son compte le plus récent.
Une exigence logicielle peut également être non fonctionnelle, comme une exigence de performance. Par exemple, une exigence non fonctionnelle pourrait stipuler que chaque page du système doit se charger pour les utilisateurs en moins 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 d'énoncés.
Types d'exigences
Besoins de l'entrepriseIl s'agit d'exigences générales issues de l'analyse de rentabilité du projet. Par exemple, un système de services bancaires mobiles dessert l'Asie du Sud-Est. Pour l'Inde, les exigences concernent le récapitulatif de compte et les virements, tandis que pour la Chine, elles incluent le récapitulatif de compte et le paiement de factures.
| 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 conceptionCes exigences sont plus détaillées que les exigences métier et orientent l'architecture de la solution. Elles déterminent la conception globale nécessaire à la mise en œuvre de l'exigence métier. Pour un établissement d'enseignement, les cas d'utilisation typiques en matière d'architecture et de conception incluent la connexion, les informations sur les cours et l'inscription. L'exigence serait telle qu'illustré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 Plateforme de paiement. Le client peut consulter un tableau de bord récapitulant les factures impayées des fournisseurs enregistrés. Il peut ajouter, modifier et supprimer les informations d'un fournisseur. Il peut configurer des alertes SMS et e-mail pour différentes actions de facturation. Il peut également consulter l'historique de ses factures payées. Ce cas d'utilisation concerne les clients de la banque ou le personnel du service client. |
Exigences du système et de l'intégrationAu niveau le plus bas, nous avons les exigences système et d'intégration. Elles fournissent une description détaillée de chaque exigence. Celle-ci peut être formalisée sous forme de récits utilisateurs rédigés dans un langage métier courant. Les exigences contiennent suffisamment de détails pour que les développeurs puissent commencer à coder. Bill L'exemple de module de paiement ci-dessous illustre les exigences relatives à l'ajout d'un facturier.
| Bill Paiement | Exigences |
|---|---|
| Ajouter BillERS | Nom du fournisseur de services publics, Numéro de client, Paiements automatiques – Oui/Non, Paiement intégral Bill – Oui/Non, limite de paiement automatique – Ne pas payer si Bill dépasse le montant spécifié |
Il arrive parfois, pour un projet, de ne recevoir aucune spécification ni aucun document. Même dans ce cas, d'autres sources d'information sont disponibles pour vous aider à concevoir votre logiciel ou vos tests. Ces sources sont listées ci-dessous.
Autres sources d'exigences
- Transfert de connaissances de collègues ou d'employés travaillant déjà sur ce projet
- Discutez du projet avec l'analyste fonctionnel, le chef de produit, le responsable du projet et les développeurs.
- Analyser la version précédente du système déjà implémenté
- Analyser les anciens documents d'exigences du projet
- RevConsultez les rapports de bogues précédents ; certains rapports de bogues sont transformés en demandes d’amélioration susceptibles d’être implémentées dans la version actuelle.
- Consultez le guide d'installation, s'il est disponible, pour savoir quelles installations sont nécessaires.
- Analysez les connaissances du domaine ou du secteur que l'équipe tente de mettre en œuvre.
Quelle que soit la source des exigences que vous utilisez, documentez-les dans un format partagé et faites-les examiner par des membres expérimentés de l'équipe.
Comment analyser les exigences
Prenons l'exemple d'un système logiciel éducatif où un étudiant peut s'inscrire à différents cours.
Examinons comment analyser les exigences. Chaque exigence doit respecter un ensemble d'attributs de qualité standard, notamment les suivants :
- Atomic
- Identifié de manière unique
- Cohérent et sans ambiguïté
- Traçable
- Priorisé
- Testable
Le tableau suivant illustre chaque attribut à l'aide de trois colonnes :
- La première colonne indique « qualité des exigences »
- La deuxième colonne indique « mauvaise exigence avec un problème »
- La troisième colonne montre la même exigence « transformée en une bonne exigence ».
| Exigence Qualité | Exemple de mauvaise exigence | Exemple de bonne exigence |
|---|---|---|
| Atomic | Les étudiants pourront s'inscrire à des cours de premier cycle et de troisième cycle | Les étudiants pourront s'inscrire à des cours de premier cycle. Les étudiants pourront s'inscrire à des cours de deuxième cycle. |
| Identifié de manière unique | 1- Les étudiants pourront s'inscrire à des cours de premier cycle. 1- Les étudiants pourront s'inscrire à des cours de deuxième cycle. | Inscription aux cours. Les étudiants pourront s'inscrire à des cours de premier cycle. Les étudiants pourront s'inscrire à des cours de deuxiè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é 1. Gestion des informations utilisateur - Priorité 1. Inscription aux cours - Priorité 1. Consultation du bulletin scolaire - Priorité 1 | Inscription des élèves - Priorité 1. Gestion des informations utilisateur - Priorité 2. Inscription aux cours - Priorité 1. Consultation du 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. |
Examinons plus en détail chacun de ces attributs, en commençant par Atomci.
Atomic
Chaque exigence doit être atomique, c'est-à-dire qu'elle doit être au niveau de détail le plus fin et ne pas pouvoir être décomposée en composants. Les exemples suivants comparent les exigences atomiques et non atomiques.
Reprenons l'exemple du système éducatif : ici, l'exigence mal formulée est « Les étudiants pourront s'inscrire à des formations de premier cycle et de cycle supérieur ». Cette exigence est mal formulée car elle ne se limite pas à une seule entité : elle mélange deux entités distinctes, les formations de premier cycle et de cycle supérieur. L'exigence correcte correspondante la sépare en deux exigences distinctes : l'une concerne l'inscription aux formations de premier cycle, et l'autre l'inscription aux formations de cycle supérieur.
Identifié de manière unique
L'attribut de qualité suivant est l'identification unique. Dans le mauvais exemple, deux exigences distinctes partagent le même identifiant #1. Si une équipe fait référence à une exigence par son identifiant, il devient impossible de savoir laquelle des deux est visée. La bonne exigence les regroupe dans la section 1 — Inscription aux cours, avec les sous-exigences 1.1 (inscription aux cours de premier cycle) et 1.2 (inscription aux cours de deuxième cycle).
Chaque exigence doit être complète. Par exemple, une exigence mal formulée indique qu'« un professeur se connectera au système en fournissant son nom d'utilisateur, son mot de passe et d'autres informations pertinentes ». L'expression « autres informations pertinentes » est vague. Une exigence complète énumère les champs exacts, tels que le code du département, que le professeur doit renseigner.
Cohérent et sans ambiguïté
Chaque exigence doit être cohérente et sans ambiguïté. Dans le mauvais exemple, une exigence stipule : « Un étudiant suivra soit des cours de premier cycle, soit des cours de deuxième cycle, mais pas les deux », tandis qu’une autre stipule : « Certains cours seront ouverts aux étudiants de premier cycle et de deuxième cycle ».
La première exigence implique que les cours soient divisés en deux catégories exclusives, mais la seconde exigence la contredit en ouvrant certains cours aux deux groupes.
Cette bonne exigence résout le conflit en indiquant clairement que chaque cours est soit de premier cycle, soit de cycle supérieur, et qu'un étudiant ne peut s'inscrire qu'à des cours d'une seule catégorie.
Traçable
Chaque exigence doit être tracréalisable car les exigences existent à plusieurs niveaux : commercial, architectural et de conception, et système et intégration.
Lorsque vous convertissez un besoin métier en exigences architecturales et de conception, ou des exigences architecturales et de conception en exigences système et d'intégration, tracLa flexibilité doit être préservée. Chaque exigence métier doit correspondre à une ou plusieurs exigences architecturales et de conception. Dans le mauvais exemple « Gérer les informations des étudiants – associé à l’identifiant de l’exigence BRD ? », l’identifiant de l’exigence est manquant.
L'exigence correcte reprend la même affirmation, mais la fait correspondre explicitement à l'exigence BRD ID 4.1. Chaque exigence doit comporter un traccarte des capacitéspingLes exigences système et d'intégration doivent également correspondre au code qui les implémente et aux cas de test qui les vérifient.
TracLa capacité est donc présente de bout en bout tout au long du projet.
Priorisé
Chaque exigence doit être priorisée afin que l'équipe sache ce qu'il faut implémenter en premier et ce qui peut attendre. Dans le mauvais exemple, les fonctionnalités « Inscrire un étudiant », « Gérer les informations utilisateur », « Inscrire aux cours » et « Consulter le bulletin » sont toutes classées en priorité 1. Or, tout ne peut pas être prioritaire 1 ; les exigences doivent donc être hiérarchisées de manière réaliste. Le bon exemple attribue la priorité 1 (la plus élevée) aux fonctionnalités « Inscrire un étudiant » et « Inscrire aux cours », la priorité 2 à « Gérer les informations utilisateur » et la priorité 3 à « Consulter le bulletin ».
Testable
Chaque exigence doit être testable. Le mauvais exemple, « chaque page du système se chargera dans un délai acceptable », n'est pas testable pour deux raisons. Premièrement, « chaque page » peut désigner des dizaines de pages, ce qui augmente considérablement la charge de test. Deuxièmement, la notion de « délai acceptable » est imprécise : acceptable pour qui et par rapport à quel critère ? Une bonne exigence résout ces deux problèmes en nommant les pages concernées (« pages d'inscription des étudiants et d'inscription aux cours ») et en fixant un objectif mesurable de 5 secondes.
