Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

SWEBOK Chapitre 1 EXIGENCES LOGICIELLES Introduction Le domaine de connaissance

SWEBOK Chapitre 1 EXIGENCES LOGICIELLES Introduction Le domaine de connaissance des exigences logicielles (KA) est concerné par l'élicitation, l'analyse, la spécification et la validation des exigences logicielles ainsi que la gestion des exigences pendant tout le cycle de vie du produit logiciel. Les exigences logicielles expriment les besoins et les contraintes imposées à un produit logiciel qui contribuent à la solution d'un problème du monde réel. L'analyse des exigences logicielles est étroitement liée à la conception du logiciel, aux tests du logiciel, la maintenance logicielle, la gestion de la configuration logicielle, gestion du génie logiciel, processus de génie logiciel, modèles d'ingénierie logicielle, et qualité logicielle. 1. Principes fondamentaux des exigences de logiciel. 1.1 Définition d’une exigence de logiciel Exigence de logiciel est une propriété qui doit être exposée par quelque chose afin de résoudre un problème dans le monde réel. Une propriété essentielle de toutes les exigences logicielles est qu'ils soient vérifiables comme caractéristique individuelle, comme exigence fonctionnelle ou au niveau système en tant qu'exigence non fonctionnelle. Analystes Concepteurs , testeurs et le personnel de qualité doivent s'assurer que les exigences peuvent être vérifiées dans les limites des contraintes de ressources disponibles. 1.2 Exigences de produit et de processus. Exigence de produit est un besoin ou une contrainte sur le logiciel à développer. (Ex., "Le logiciel doit vérifier qu'un étudiant satisfait à toutes les conditions préalables avant de s'inscrire à un cours’’). Exigence de processus est essentiellement une contrainte sur le développement du logiciel (Ex., "Le logiciel doit être développé en utilisant un processus RUP »). Les exigences peuvent être imposées directement par l'organisation de développement, leur client où une tierce personne tel qu'un organisme de réglementation de la sécurité. 1.3. Exigences fonctionnelles et non fonctionnelles. Les exigences fonctionnelles décrivent les fonctions que le logiciel doit exécuter. Elles sont parfois appelées capacités ou fonctionnalités. Les exigences non fonctionnelles (contraintes, exigences de qualité) sont celles qui agissent pour contraindre la solution. Ils peuvent encore être classés selon qu'ils sont exigences de performance, exigences de maintenabilité, exigences de sécurité, exigences de fiabilité, exigences de sécurité, exigences d'interopérabilité, etc. 1.4. Propriétés émergentes Certaines exigences représentent des propriétés émergentes de logiciel, c'est-à-dire des exigences qui ne peuvent pas être adressées par un seul composant mais qui dépendent de la façon dont tous les composants logiciels interopèrent. Les propriétés émergentes dépendent essentiellement de l'architecture du système. 1.5. Exigences avec évaluation quantitative Les exigences logicielles doivent être énoncées sans ambiguïté et aussi clairement que possible, et, le cas échéant, quantitativement. Il est important d’éviter des exigences vagues et invérifiables dont l’interprétation dépend de jugement subjonctif (Ex., « le logiciel doit être fiable »). L’exemple d'exigences quantifiées : le logiciel d'un centre d'appel doit augmenter le débit du centre de 20 %. 1.6. Exigences du système et exigences logicielles « Système » signifie une combinaison interactive d'éléments pour atteindre un objectif défini. Ces éléments sont le matériel, les logiciels, les micrologiciels, personnes, informations, techniques, installations, services et autres éléments de soutien. Exigences du système sont des exigences pour le système dans son ensemble. Dans un système contenant des composants logiciels, les exigences logicielles sont dérivées des exigences du système. Exigences des utilisateurs sont les exigences des utilisateurs et clients du système. 2. Processus d’exigences Montre comment le processus d'exigences met en accord avec le processus global de génie logiciel. Participants de processus Exemples typiques d'acteurs du logiciel : - utilisateurs; - clients; - analystes de marché; - régulateurs. De nombreux domaines d'application (banques, transports publics) sont réglementés. Les logiciels de ces domaines doivent être conformes aux exigences des autorités réglementaires. - programmeurs; Il ne sera pas possible de satisfaire parfaitement les exigences de chaque participant, et c'est le travail d'ingénieur logiciel pour négocier des compromis qui sont à la fois acceptables pour les participants principaux dans les limites budgétaires, techniques, réglementaires et autres contraintes. 3. Élicitation des exigences C'est la première étape dans la construction de la compréhension du problème que le logiciel doit résoudre. Une communication effective entre les différents participants est l'un des principes fondamentaux d'un bon processus d'élicitation des exigences. Cette communication continue à travers l'ensemble du cycle de vie du développement logiciel. Un élément critique de l'élicitation des exigences est d’indiquer les enjeux et objectifs du projet. Cela consiste à fournir une description du logiciel spécifié et son objectif et prioriser les livrables pour assurer que les besoins les plus importants de l’entreprise du client sont premièrement satisfaits. Cela minimise le risque que les spécialistes des exigences passent du temps pour obtenir des exigences de faible importance. D'autre part, le la description doit être évolutive et extensible pour accepter d'autres exigences non exprimées dans la première liste formelle et compatibles avec les exigences précédentes. 3.1. Sources des exigences Les exigences ont de nombreuses sources dans les logiciels typiques, et il est essentiel que toutes les sources potentielles soient identifiées et évaluées. -- Les objectifs fournissent la motivation pour le logiciel mais sont souvent vaguement formulés. Les ingénieurs logiciels doivent payer une attention particulière à l'évaluation de la valeur (par rapport à la priorité) et le coût des objectifs. -- Connaissance du domaine. L'ingénieur logiciel doit acquérir ou disposer de connaissances sur le domaine d'application. -- Parties intéressées : De nombreux logiciels se sont révélés insatisfaisants parce qu'ils ont souligné les exigences d'un groupe de parties intéressées aux dépens des autres. Par conséquent, le logiciel livré est difficile à utiliser. L'ingénieur logiciel doit identifier, représenter et gérer les « points de vue » de nombreux types différents de parties intéressées. -- Règles de l’entreprise. Ce sont des déclarations qui définissent ou contraignent certains aspects de la structure ou le comportement de l'entreprise elle-même. Ex., "Un l'étudiant ne peut pas s'inscrire aux cours du semestre prochain s'il reste des frais de scolarité non payés ». -- Conditions opérationnelles : Les exigences seront dérivées de l'environnement dans lequel le logiciel sera exécuté. -- Environnement organisationnel : Le logiciel est nécessaire pour soutenir un processus business, dont le choix provient de la structure, la culture et les politique de l'entreprise. 3.2. Techniques d'élicitation des exigences. Une fois les sources d'exigences identifiées, l'ingénieur logiciel peut commencer à demander des informations de leur part. 1. Entrevues. Interviewer les parties intéressées. 2. Scenarios. Le type de scénario le plus courant est la description du cas d'utilisation. 3. Prototypes (à partir de maquettes papier des conceptions d'interface utilisateur graphique aux versions bêta- test de produits logiciels). Cette technique est un outil précieux pour clarifier des exigences ambiguës. 4. Rencontres facilitées. Un groupe de personnes peut apporter plus d'informations sur leurs exigences logicielles et affiner les idées qui pourraient être difficile à faire remonter à la surface à l'aide d'interviews individuels. 5. Observation. Ingénieurs logiciels apprennent sur les tâches des utilisateurs en s'immergeant dans l'environnement et en observant comment les utilisateurs effectuent leurs tâches en interagissant avec entre eux et avec des outils logiciels et d'autres ressources. 6. User stories. Use story typique au format: “As a <role>, I want <goal/desire> so that <benefit>.” D’autres techniques: l’analyse produits des concurrents, techniques d'exploration de données, etc. 4. Analyse des exigences. 4.1 Classification des exigences a) exigences fonctionnelles, non fonctionnelles; b) exigences sur le produit ou le processus; c) la priorité des exigences; d) envergure de l’exigence (la mesure où l’exigence affecte le logiciel et les composants logiciels); e) volatilité/stabilité (Certaines exigences changeront au cours du cycle de vie du logiciel et même pendant le processus de développement lui-même. Signaler les exigences potentiellement volatiles peut aider l'ingénieur logiciel d’établir une conception plus tolérante à des changements.) 4.2 Modélisation conceptuelle (diagrammes de cas d'utilisation, modèles de flux de données, modèles d'état, modèles basés sur des objectifs, interactions avec l'utilisateur, modèles d'objets, etc). Le développement de modèles d'un problème de monde réel est la clé de l'analyse des exigences logicielles. Leur but est d'aider à comprendre la situation dans laquelle le problème survient, ainsi que décrire une solution. Ainsi, les modèles conceptuels comprennent des modèles d'entités du domaine problème, configurés pour refléter leurs relations et dépendances réelles. 4.3. Conception de l’architecturale et allocation des exigences. L'élaboration des exigences exige que les composants d'architecture/conception qui seront responsables de satisfaire aux exigences soit identifiés. Il s'agit de l'allocation des exigences – on affecte à l’architecture les composants responsables pour satisfaire aux exigences. 4.4. Négociation des exigences (résolution de conflit). Il s'agit de résoudre des problèmes avec les exigences où des conflits surviennent entre deux parties intéressées qui demandent des fonctionnalités mutuellement incompatibles, conflits entre les exigences et ressources, entre exigences fonctionnelles et non fonctionnelles, etc. Ici il est important de prioriser les exigences. 4.5 Analyse formelle. La formalisation est appliquée après les objectifs de l’entreprise et besoins des utilisateurs sont très bien définis. Les avantages : l’analyse permet aux exigences exprimées dans la langue d’être spécifiées précisément et sans ambiguïté, évitant ainsi le potentiel pour mauvaise interprétation. Deuxièmement, les exigences peuvent être raisonnées, permettant les propriétés souhaitées du logiciel d’être prouvées. 5. Spécification des exigences En génie logiciel, la "spécification des exigences logicielles" fait généralement référence à la uploads/Management/ swebok1-10.pdf