Ingénierie des besoins d’un système d’information PDF

Processus d\'ingénierie des exigences  ====================================== Introduction: ------------- Afin de produire un produit de qualité, il est important d\'avoir des exigences précises de la part du client. Cela commence par le processus d\'ingénierie des exigences, qui peut être divisé...

Processus d\'ingénierie des exigences  ====================================== Introduction: ------------- Afin de produire un produit de qualité, il est important d\'avoir des exigences précises de la part du client. Cela commence par le processus d\'ingénierie des exigences, qui peut être divisé en cinq étapes : collecte des exigences, documentation des exigences, analyse et vérification des exigences, gestion des modifications des exigences et clôture de la phase des exigences. Dans cet article de blog, nous discuterons en détail de chacune de ces étapes et montrerons comment elles contribuent à produire un produit de haute qualité. **Qu\'est-ce que l\'exigence et l\'ingénierie des exigences ?** Il y a deux termes ici, « Exigence » et « Ingénierie des exigences ». Une exigence est précisément définie comme une condition ou une capacité dont un utilisateur a besoin pour résoudre un problème ou atteindre un objectif. En d\'autres termes, les exigences sont des conditions ou des capacités qui doivent être remplies ou possédées par un système afin de satisfaire un contrat, des normes, des spécifications et d\'autres documents formels.  L\'ingénierie des exigences est définie comme le processus de définition, de documentation et de maintenance des exigences. La discipline comprend toutes les techniques, méthodes et procédures liées à la définition et à la gestion des besoins des utilisateurs liés au système étudié.  Dans l\'ensemble, l\'ingénierie des exigences est un ensemble d\'activités qui concernent l\'identification et la communication de l\'objectif d\'un système ou d\'un logiciel et du contexte dans lequel il sera utilisé.  Par conséquent, l\'ingénierie des exigences agit comme un pont entre les besoins réels des utilisateurs, des clients et d\'autres groupes concernés par le logiciel ou le système et les capacités et opportunités offertes par les technologies à forte intensité logicielle.  **Quels sont les principes de l\'Ingénierie des Exigences ?** Les deux principes de base de l\'ingénierie des exigences sont le problème et la solution de l\'ingénierie des exigences.  - Il est utile de séparer le problème et la solution lors de la collecte des exigences. - Cette séparation ne peut jamais être pleinement réalisée dans la vie pratique. L\'ingénierie des exigences consiste à construire le bon système. Fondamentalement, il s\'agit de construire un système adapté aux problèmes de l\'utilisateur. Il s\'agit d\'une partie axée sur les problèmes. Il s\'agit essentiellement de concevoir, vérifier, mettre en œuvre et maintenir le système créé pour s\'assurer qu\'il correspond aux problèmes de l\'utilisateur. C\'est la partie orientée solution. Processus d\'ingénierie des exigences : ======================================= Il y a quelques activités auxquelles nous sommes confrontés lorsque nous travaillons avec les exigences. Dans le cycle Ingénierie des Exigences, il y a cinq activités principales, à savoir, 1. **Recueil des exigences** -- c\'est le processus d\'examen, de documentation et de compréhension des besoins et des contraintes des parties prenantes et des utilisateurs pour la saison. Les utilisateurs ont besoin d\'informations sur le domaine, d\'informations sur le système existant, de réglementations, de normes, etc. Sur la base de ces informations, nous élicitons les exigences. Ensuite, nous passons à l\'analyse des besoins et à la négociation.  2. **Analyse des besoins et négociation** -- l\'analyse est le processus d\'affinement des besoins et des contraintes de l\'utilisateur sur la base des informations recueillies et obtenues. Ensuite, nous passons à l\'activité de documentation.  3. **Documentation/spécification des exigences** -- après avoir obtenu le cahier des charges, nous passons à la partie documentation. Nous documentons clairement et précisément les besoins et contraintes des utilisateurs.  4. **Validation des exigences** -- enfin, dans l\'activité de validation, nous insérons que les exigences de la saison sont complètes, concises et claires.  5. **Gestion des exigences **-- La gestion des exigences est un moyen de collecter, d\'analyser, d\'affiner et de hiérarchiser tous les produits ou exigences, dans la phase de développement. Lorsque nous finalisons ces cinq activités, nous les répétons encore et encore jusqu\'à ce que nous obtenions un ensemble de documents d\'exigences convenus qui sont des spécifications formelles. **Recueil des exigences:** Comme nous l\'avons vu précédemment, l\'élicitation des exigences est le processus d\'examen, de documentation et de compréhension des besoins et des contraintes des utilisateurs pour la saison. Les utilisateurs ont besoin d\'informations sur le domaine, d\'informations sur le système existant, de réglementations, de normes, etc. Sur la base de ces informations, nous élicitons les exigences. Nous utilisons le mot « élicitation » au lieu de « rassemblement », car le rassemblement signifie simplement recueillir les exigences et les mettre dans un document. En revanche, l\'élicitation est un processus plus complexe. Vous n\'obtenez pas les exigences aussi facilement que lors de la collecte. Cela demande un effort supplémentaire.  Lors de l\'élicitation, vous demandez à l\'utilisateur ou au client : - Quels sont leurs objectifs pour le système/produit ?  - Que faut-il accomplir ? - Comment les besoins saisonniers s\'intègrent-ils dans les besoins de l\'entreprise ? - Comment le produit/système saisonnier doit-il être utilisé de manière régulière ? Cela semble simple, mais ce n\'est pas du tout le cas ! Selon Ian Sommerville et Pete Sawyer, l\'élicitation des exigences est le processus de découverte des exigences d\'un système en communiquant avec les clients, les utilisateurs du système et les autres personnes concernées par le développement du système. Puisque \'rassembler\' ou \'capturer\' ne semble pas très précis, nous utilisons le mot \'élicitation\'.  \"Je sais que vous pensez avoir compris ce que vous pensez que j\'ai dit, mais je ne suis pas sûr que vous réalisiez que ce que vous avez entendu n\'est pas ce que je voulais dire\" - Robert McCloskey, porte-parole du département d\'État. Ce qu\'il voulait dire par sa citation, c\'est que parfois les gens comprennent mal ce que les autres leur disent. Parfois, ce qu\'ils disent n\'est pas ce qu\'ils ont en tête. Finalement, toute cette mauvaise communication a conduit à l\'erreur de collecte des exigences.  **Quelles sont les étapes lors de l\'élicitation ?** **[ÉTAPE 1] ** **Source des exigences :** Il existe différentes sources à partir desquelles nous pouvons recueillir nos besoins. Certains d\'entre eux incluent: - Les intervenants - Systèmes existants - Documents existants - Concurrents et autres systèmes similaires - Interfaces avec les systèmes - Lois et normes - Politiques de l\'entreprise **[ÉTAPE 2]** **Définissez la portée du projet :** Les étapes suivantes peuvent être suivies afin de définir la portée du projet : 1. Découvrez pourquoi le projet est lancé  2. La propriété définit les objectifs clés à atteindre à travers le projet  3. Rédigez un énoncé de travail pour le projet qui vous aidera à répartir le travail de manière appropriée entre les membres de l\'équipe 4. Lister les éléments à livrer à la fin du projet 5. Sélectionnez les étapes clés à atteindre 6. Identifier les principales contraintes et limites auxquelles l\'équipe peut éventuellement être confrontée lors du développement du projet 7.  Créer une liste d\'éléments exclus de la liste des éléments d\'étendue 8. Demandez aux parties prenantes de signer le document de portée car il fournit une confirmation qu\'elles sont informées du projet et de son contenu.  **[ÉTAPE 3]** **Tâches d\'élicitation :** *Élicitation de la planification :* - Pourquoi cette exigence particulière devrait-elle être mise en œuvre et les avantages qu\'elle apportera ? -- Objectifs du projet  - Qui sera chargé de le créer ? -- Des professionnels pour les efforts d'élicitation - Quel sera le meilleur moment pour le mettre en œuvre ? -- Planifier un devis sources  - Comment sera-t-il mis en œuvre ? -- Stratégies et procédures - Et les risques  *Lors de l\'élicitation :* - Confirmer la viabilité du projet. Découvrez si le projet en vaut vraiment la peine ou non - Comprendre les problèmes et les enjeux du point de vue des parties prenantes - Extraire l\'essentiel des exigences énoncées par les parties prenantes - Découvrez de meilleures façons de faire le travail pour les utilisateurs - L\'innovation est la clé de la victoire *Après élicitation :* - Analyser les résultats afin de bien comprendre les informations recueillies - Négocier un ensemble cohérent d\'exigences acceptables pour les parties prenantes. Établir également les priorités - Consigner les résultats dans le cahier des charges des exigences L\'élicitation est un processus incrémental. Vous devez répéter cette étape autant de fois que nécessaire.  Maintenant, sélectionnez un ensemble approprié de techniques pour chaque source d\'exigences. Déterminez cette technique en fonction de la source, du système à développer, etc. Rappelez-vous que toutes les techniques ne peuvent pas être utilisées dans toutes les situations.  **[ÉTAPE 4]** **Documentation des exigences -- ** La dernière étape du processus d\'élicitation consiste à finaliser toutes les exigences sous la forme d\'un document. Ce document contient principalement les notes et les besoins des utilisateurs. Et ces exigences vont être incomplètes, incohérentes et non organisées. Mais ce n\'est que le point de départ. Le document peut être modifié de temps en temps, et des éléments peuvent être ajoutés ou modifiés. **Analyse des besoins et négociation :** L\'analyse des exigences est généralement une procédure d\'analyse, de validation et d\'alignement des exigences documentées au cours de la phase d\'élicitation des exigences. En d\'autres termes, l\'analyse des exigences est un processus d\'étude et de compréhension des exigences énoncées par les parties prenantes. L\'analyse des exigences nécessite une communication fréquente avec les parties prenantes et les utilisateurs finaux afin de définir les attentes, de résoudre les conflits et enfin de documenter les principales exigences. Les solutions peuvent impliquer des problèmes tels que : - Différents types de configuration pour le flux de travail dans l\'entreprise - Mise en place d\'un nouveau système qui doit être utilisé à partir de maintenant, etc.  Une chose à garder à l\'esprit est que l\'élicitation des exigences et l\'analyse des exigences fonctionnent ensemble. Ils se nourrissent tous les deux. Lorsque nous commençons à rassembler les exigences, nous les élicitons et les analysons en même temps. **Objectifs de l\'analyse des besoins :** 1. L\'objectif premier de l\'analyse des besoins est de comprendre les exigences et les besoins des utilisateurs  2. Lorsque nous utilisons différentes sources pour recueillir les exigences, il peut y avoir des conflits entre elles. L\'analyse des exigences consiste à trouver ces conflits parmi les exigences énoncées par les utilisateurs et à les résoudre.  3. Négocier les exigences avec les utilisateurs et les parties prenantes. Notre système ne peut en aucun cas répondre à toutes les exigences de la manière exacte dont elles sont expliquées par les parties prenantes et les utilisateurs.  4. Nous devrons négocier et hiérarchiser les besoins. Certaines exigences ne sont peut-être pas importantes pour nous, mais elles peuvent être assez importantes pour les utilisateurs finaux. Pour les comprendre, il faut analyser et hiérarchiser les exigences des parties prenantes.  5. Nous devons élaborer sur les exigences énoncées par les utilisateurs et le système. Cela aide à documenter les exigences dans les spécifications des exigences. En outre, cela aide les développeurs à mieux développer, concevoir et tester car ils comprennent les exigences d\'une manière élaborée et meilleure.  6. Nous devons classer les exigences en différentes catégories et sous-catégories et répartir ensuite ces exigences dans différents sous-systèmes.  7. Nous devons également évaluer les exigences de la qualité qui est souhaitée par l\'organisation.  8. Enfin, il faut veiller à ne rien manquer d\'important. Documentation/spécification des exigences : =========================================== La spécification des exigences, également connue sous le nom de documentation, est un processus consistant à noter toutes les exigences du système et de l\'utilisateur sous la forme d\'un document. Ces exigences doivent être claires, complètes, exhaustives et cohérentes.  Au cours de l\'activité de capture, nous recueillons toutes les exigences provenant de diverses sources. Au cours des activités d\'analyse et de négociation, nous analysons et comprenons ces exigences. Maintenant, nous devons préparer un document officiel expliquant ces exigences. C\'est ce qu\'est le cahier des charges. Pour être précis, c\'est le processus de documentation de tous les besoins et contraintes de l\'utilisateur et du système de manière claire et précise.  **Méthode de documentation des exigences :** **OREILLES** serait une méthodologie efficace ici. Ça signifie *Approche simple de la syntaxe des exigences*. Dans cette méthode, nous écrivons un langage clair, concis et compréhensible. Cela améliore l\'ensemble du flux de travail d\'ingénierie des exigences et simplifie le travail en rendant les choses assez faciles à comprendre.  Pour y parvenir, voici quelques principes qui doivent être gardés à l\'esprit lors de la rédaction des exigences. Ils impliquent : Chaque exigence doit être sous la forme d\'une phrase complète. Aucune puce, acronyme, abréviation ou mot à la mode ne doit être utilisé. Essayez de faire des phrases courtes, directes et complètes.  Assurez-vous que chaque exigence a un sujet, un prédicat et un verbe appropriés. Le sujet serait le type d\'utilisateur ou le système dont nous parlons. Le prédicat serait les conditions ou les actions ou les résultats souhaités que nous attendons. Nous devons utiliser des mots comme « doit », « volonté » et « doit » pour exprimer une sorte de nécessité, et des mots comme « peut » pour exprimer le caractère facultatif de l\'exigence.  Chaque exigence doit expliquer efficacement le résultat final que nous attendons du système.  De plus, l\'exigence doit décrire la qualité que nous attendons du système. Cela aide lorsque nous mesurons le résultat final et voyons si l\'exigence est correctement mise en œuvre ou non. **Quelques conseils pour les exigences de rédaction :** Vous trouverez ci-dessous quelques conseils qui peuvent vous aider à améliorer votre rédaction pour les exigences.  - Formez des phrases courtes et significatives en utilisant la voix active.  - Lisez les exigences du point de vue du développeur et du testeur pour comprendre la précision des exigences.  - N\'utilisez pas \'et/ou\' qui compose plusieurs exigences. Essayez de faire des phrases simples qui peuvent être testées unitairement.  - Assurer un niveau similaire de cohérence et d\'uniformité dans l\'explication des exigences. - Évitez autant que possible les répétitions car cela peut faciliter la lecture mais augmenter la maintenance.  - Assurez-vous que l\'exigence est traçable.  **Caractéristiques d\'un cahier des charges :** - Un document d\'exigence décrit efficacement toutes les exigences du système à concevoir.  - Toutes les exigences décrites dans ce document sont pratiques et vérifiables. - Les entrepreneurs et les fournisseurs signent les contrats sur la base de ce document d\'exigences. - Le document d\'exigence est une description détaillée des notes prises lors de l\'élicitation de l\'exigence.  Validation des exigences : ========================== La validation est un processus utilisé pour vérifier si le système est à la hauteur ou non. La validation répond à la question : « Construisons-nous le bon système ? Il s\'agit de tester et de valider le système et de voir si le système que nous avons construit est correct ou non et s\'il répond ou non aux attentes du client. Les diverses méthodes utilisées pour valider le système comprennent les tests en boîte noire, les tests en boîte blanche, les tests d\'intégration et les tests unitaires. La validation vient toujours après la vérification.  La vérification est un processus utilisé pour vérifier si le système atteint ou non les objectifs escomptés sans aucun bogue ou problème. La vérification répond à la question : « Construisons-nous correctement le produit ? » Il s\'agit de tester et de vérifier si le système répond à ses exigences sans aucun problème. Les diverses méthodes utilisées pour vérifier le système comprennent des examens, des visites guidées, des inspections et des vérifications au bureau. La vérification est un processus manuel effectué avant la validation. **Techniques de Validation :** Différentes techniques peuvent être utilisées pour valider les exigences. Ils comprennent: - *Contrôles* -- Lors de la vérification des exigences, nous relisons les documents d\'exigences pour nous assurer qu\'aucune note d\'élicitation n\'est oubliée. Lors de ces contrôles, nous vérifions également le niveau de traçabilité entre toutes les exigences. Pour cela, la création d\'une matrice de traçabilité est nécessaire. Cette matrice garantit que toutes les exigences sont prises au sérieux et que tout ce qui est spécifié est justifié. Nous vérifions également le format des exigences lors de ces vérifications. Nous voyons si les exigences sont claires et bien écrites ou non.  - *Prototypage* -- C\'est une façon de construire un modèle ou une simulation du système qui doit être construit par les développeurs. Il s\'agit d\'une technique très populaire pour la validation des exigences parmi les parties prenantes et les utilisateurs car elle les aide à identifier facilement les problèmes. Nous pouvons simplement contacter les utilisateurs et les parties prenantes et obtenir leurs commentaires.  - *Conception des tests* -- Lors de la conception des tests, nous suivons une petite procédure où nous finalisons d\'abord l\'équipe de test, puis construisons quelques scénarios de test. Les tests fonctionnels peuvent être dérivés de la spécification des exigences elle-même où chaque exigence est associée à un test. Au contraire, les exigences non fonctionnelles sont difficiles à tester car chaque test doit être retracé jusqu\'à son exigence. Le but est de comprendre les erreurs dans la spécification ou les détails qui sont manqués.  - *Examen des exigences* -- Lors de l\'examen des exigences, un groupe de personnes compétentes analyse les exigences de manière structurée et détaillée et identifie les problèmes potentiels. Après cela, ils se réunissent pour discuter des problèmes et trouver un moyen de résoudre les problèmes. Une liste de contrôle est préparée comprenant diverses normes et les examinateurs cochent les cases pour fournir un examen formel. Après cela, une approbation finale est effectuée.  **Gestion des exigences :** Selon Ian Sommerville, \"la gestion des exigences est le processus de gestion des exigences changeantes au cours du processus d\'ingénierie des exigences et du développement du système\". L\'objectif principal de la gestion des exigences est de garantir des exigences claires, concises et sans erreur à l\'équipe d\'ingénierie afin qu\'elle puisse s\'assurer de détecter les erreurs dans le système et potentiellement réduire le coût du projet ainsi que les risques.  **Principales préoccupations de la gestion des exigences :** La gestion des exigences suscite certaines inquiétudes. Ils comprennent: - Gérer les changements dans les exigences convenues - Gérer la relation entre toutes les exigences - Gérer les dépendances entre les documents d\'exigences qui sont produits au cours du processus d\'ingénierie système. **Types d\'exigences :** Il existe en gros deux types d\'exigences : 1. *Configuration requise* -- Les exigences système peuvent être appelées la version étendue des exigences utilisateur. Les exigences du système servent de point de départ pour toute nouvelle conception de système. Ces exigences sont une description détaillée des exigences de l\'utilisateur auxquelles le système doit satisfaire.  2. *Besoins des utilisateurs* -- L\'exigence de l\'utilisateur est une combinaison d\'exigences fonctionnelles et non fonctionnelles. Ces exigences des utilisateurs doivent être conçues de manière à être facilement compréhensibles par des utilisateurs qui n\'ont aucune connaissance technique. Par conséquent, ils doivent être rédigés en langage naturel à l\'aide de tableaux, de formulaires et de diagrammes simples. Assurez-vous également que le document ne contient pas de détails sur la conception du système, les logiciels ou les notations formelles. Exigences fonctionnelles vs non fonctionnelles : ================================================ *Exigences fonctionnelles*, comme son nom l\'indique, décrivent les fonctions du système à concevoir. Il s\'agit d\'une description de ce que sera le système et de la façon dont il fonctionnera pour répondre aux besoins des utilisateurs. Ils fournissent une description claire de la façon dont le système est censé répondre à une commande particulière, des fonctionnalités et de ce que les utilisateurs attendent.  *Prérogatives non fonctionnelles* expliquer les limites et les contraintes du système à concevoir. Ces exigences n\'ont aucun impact sur la fonctionnalité de l\'application. En outre, il existe une pratique courante consistant à sous-classifier les exigences non fonctionnelles en diverses catégories telles que : - Interface utilisateur - Fiabilité  - Sécurité - Performance - Entretien - Normes  La sous-classification des exigences non fonctionnelles est une bonne pratique. Cela aide lors de la création d\'une liste de contrôle des exigences qui doivent être satisfaites dans le système à concevoir.  Les exigences non fonctionnelles sont aussi importantes que les exigences fonctionnelles. Si les exigences fonctionnelles spécifient ce qu\'un système doit faire, les exigences non fonctionnelles décrivent comment le système le fera. Par exemple, la nouvelle application nous fournira la liste finale de tous les utilisateurs connectés. Cela fait partie des exigences fonctionnelles. Si l\'exigence stipule que le système ne fonctionnera que sur un système Windows et Linux, cela fera partie des exigences non fonctionnelles.  La seule différence entre les deux est que le système ne peut pas fonctionner sans satisfaire à toutes les exigences fonctionnelles. D\'autre part, le système vous donnera le résultat souhaité.