Introduction à l'analyse des exigences logicielles

1. Introduction à l'analyse

1.1 Généralités

Étape fondamentale dans le cycle de vie du logiciel.

• Analyse du système et des exigences.
• Pour analyser les besoins, il faut au préalable les obtenir (détermination des exigences).
• Ingénierie des exigences.

1.1 Définition de l'analyse

Processus d'étude des besoins des utilisateurs pour en arriver à une définition des exigences du système, matériel ou logiciel, et le processus d'étude et de perfectionnement de ces exigences.

1.1 Ingénierie des exigences

Première phase du cycle de vie du logiciel où il y a un cahier des charges.

• À partir d'idées informelles, doivent être obtenues et documentées :
• Exigences fonctionnelles.
• Exigences non fonctionnelles, des critères pour mesurer le degré de leur réalisation.

Le processus d'élaboration de la spécification des exigences est ce qu'on appelle l'ingénierie des exigences.

• Importance croissante :
• Compréhension correcte (marchés), de la documentation (spécification) et la validation des besoins des utilisateurs et des clients.
• Les systèmes de mesure de la qualité basés sur le degré de satisfaction des utilisateurs.

1.3 Exigences

Condition ou la capacité nécessaires à l'utilisateur pour résoudre un problème ou atteindre un objectif déterminé. Apparente simplicité du concept. L'exigence est un terme commun, mais il est important de trouver du personnel qualifié avec des adjectifs qui peuvent être déroutants au premier abord.

Champ d'application

Indique quel contexte nous devons comprendre l'exigence. La portée du système indique que l'exigence devrait être atteinte au niveau du système, c'est-à-dire un ensemble de matériel du système et de logiciels. Si le champ est un logiciel, cela signifie que la prescription ne concerne que le logiciel système. Si un niveau matériel affecte uniquement le matériel.

Définition de fonction d'une exigence

Dimension pour laquelle les exigences sont classées selon la nature de la propriété spécifiée du système. La classification la plus commune est souvent les exigences fonctionnelles (quelles fonctions devrait rendre le système) et non fonctionnelles (autres caractéristiques du système). Cette classification n'est pas toujours très claire parce que, dans certains cas, une exigence peut être classée dans plusieurs catégories à la fois.

Audience

Dimension indiquant de qui il s'agit de l'exigence, à savoir, les gens devraient être en mesure de comprendre. En général, il existe deux types d'audience : les clients et les utilisateurs n'ont pas besoin d'être formés en génie logiciel et les développeurs de logiciels. Dans cette dimension, on utilise souvent la nomenclature qui sont appelées orientées vers le client :

• Exigences à court terme (C).
• Exigences du point de vue des clients et des utilisateurs.
• Exigences orientées développeurs (D).
• Exigences du point de vue des développeurs.

Représentation

Dimension qui est utilisée pour établir comment les exigences sont définies.

Les catégories sont généralement traitées formelles, semi-officielles ou formelles.

Les représentations formelles ont une sémantique rigoureuse et de la syntaxe.

Les représentations semi-formelles sont des modèles qui facilitent la compréhension entre les participants. Les représentations non officielles sont l'expression naturelle dans le texte, les vidéos, les images, la voix et les sons pour limiter le système à construire.

1.4 Objectif

Construire une spécification précise des exigences logicielles qui décrivent ce que le système doit faire, mais sans détailler la façon dont cela devrait être fait.

• Software Requirements Specification (SRS) : Ce document doit inclure à la fois les exigences D et les exigences C. Cependant, il existe des méthodes qui prônent la séparation de ces représentations dans deux documents différents.
• Le DRS (Document sur les exigences système), également connu comme catalogue d'exigences, fixant les prescriptions C.
• La LRA elle-même, qui identifie les D.
• Les exigences de la prise d'une participation ERS :
• Software Engineers (analyste).
• Les clients et les utilisateurs.

1.7 Les principes de l'analyse

• Vous devez représenter et comprendre la portée des informations du problème.
• Il convient de développer des modèles d'information qui représentent la composante fonctionnelle et le système de modèles.
• La performance doit être divisée de manière à découvrir les détails d'une manière hiérarchique.
• Le processus d'analyse progressive doit être de l'information essentielle à la mise en œuvre en détail.

1.7.1 Représentation de l'information

• Trois modes de représentation de l'information :
• Circulation de l'information.
• Le contenu d'informations.
• La structure de l'information.

1.7.2 Construction du modèle

• Objectif n° 1048790 #, pour lutter contre l'.
• Focus sur ce qui rend complexe le système.
• Représentations graphiques de l'information textuelle à compléter.
• Types :
• Logique.
• Physique.

1.7.2.1 Pourquoi modéliser ?

• Dans la vraie vie, on construit de nombreux types de modèles à des fins diverses avant.
• Objectifs de construire des modèles :
• Test d'une entité physique avant de construire.
• Client - Visualisation de communication.
• Réduction de la complexité.
• Structurez vos idées.