La spécification des logiciel: décrit ce que doit faire le
système sans définir comment il doit le faire. Sert à
définir les limites du logiciel, à comprendre les
besoins et leur évolution dans le temps.
Dans cette étape, il faut :
Estimer la faisabilité technique.
Identifier les personnes pouvant contribuer à la
compréhension des besoins
Définir le futur environnement technique
Identifier les besoins ambigus comme candidats de
prototypage
Créer des scénarios d’utilisation pour aider le client à
mieux identifier les besoins.
La spécification
Description complète des informations
(données & contrôles)
Description fonctionnelle détaillée.
La représentation du comportement du
système
Indication des contraintes de conception et des
besoins, les critères de validation appropriés…
Selon la taille et la complexité du système, la
spécification peut être un modèle graphique, un
modèle mathématique formel, des scénarios
d’utilisation, des prototypes…
Revue de la spécification
Réalisée par le développeur et le client. Ils essayent de
s’assurer que la spécification est complète, consistante
et précises.
Le document de la spécification (cahier des charges)
devient un contrat pour le développement du logiciel.
Le cahier des charges: doit être:
Non ambigu: précision es termes utilisés
Complet: inclut les comportement aux événement
exceptionnels
Vérifiable: peut facilement être vérifié.
Consistant: pas de contradiction
Modifiable: reporter facilement les modification
Utilisable durant la maintenance: prévoit les évolutions.
La structure d’un cahier des charges:
Introduction: décrit brièvement les fonctions
principales du logiciel.
Matériel:décrit le matériel et les interfaces utilisés.
Domaine des données: décrit les
données/contrôles, leurs flux et leurs structures.
Besoins fonctionnels: décrivent les
fonctions(opérations/transformations) que le logiciel
doit réaliser.
Besoins non fonctionnels: toutes les spécifications qui
décrivent des contraintes:
Contraintes d’interfaces: imposées par l’
environnement logiciel, matériel ou humain.
Contraintes de performance: mémoire, temps de
réponse, sécurité…
sous_ensemble et priorités d’implémentation: définit
les éventuelles versions particulières du logiciel.
Information de maintenance: les parties susceptibles
d’évoluer.
Glossaire: la définition des termes techniques utilisés
dans le cahier des charges.
l’index: pour ne utilisation facile du cahier des charges.
Les techniques de spécification
1. Techniques informelles
a. langage naturel Avantage: facilement compréhensible
par le client. inconvénient: non cohérence, ambiguïté, non
complétude, difficulté d’organisation, redondance
d’information.
b. Enoncés structurés reposent sur l’utilisation contrôlée du
langage naturel, formulaires standards ou des structures de
contrôle issues des langages de programmation et
structurer la specification par les moyens graphiques de
mise en valeur.
c. dictionnaire de données: est constitué de l’ensemble des
données utilisées dans l’analyse et la conception. La
description de chaque donnée contient:
d. Table de décision est adaptée à la spécification des systèmes finis
dont les sorties sont définies par les entrées.
e. Matrice états/transitions: composée de lignes représentant les
différents états du système et pour chaque état, on représente
en colonnes les événements qui provoquent des transitions d’un
état vers un autre, les actions à effectuer et l’état suivant pour
chaque transition.
Adaptée aux systèmes dont les sorties sont déterminées par les
entrées et l’historiques des états antérieurs.
f. Tables de vérités (logiques): permettent d’établir la valeur de vérité que
prend une expression logique et ceci pour toutes les valeurs possibles
des clauses qui la composent.
[Link] graphiques (semi-formelles)
a. Modèle entités/associations
Objets de données: représentation d’une information composée.
Les attributs: servent à nommer une instance, décrire l’instance ou faire
référence à une autre instance dans une autre table. (en plus de
l’identificateur -clé-).
Les relations: pour connecter les objets de données.
La cardinalité: est la spécification du nombre des occurrences d’un objet qui
peut être liés aux nombres d’occurrences d’un autre objet. Elle est
exprimée en 1 et N pour définir le nombre minimum et maximum.
B. Diagramme de flux: Il existe deux types:
Modèle de contexte sert à représenter les interactions entre
le domaine d’étude et l’environnement ainsi que les éventuels
domaines connexes. Aucun détail du domaine d’étude n’y est
représenté.
Diagramme de flux de données DFD: permet de décomposer
le domaine d’études en activités. On représente les flux entre
les activités et l’environnement.
pour analyser les communications et les activités, on procède
par raffinement successifs.
la méthode de décomposition est la suivante:
1. Identifier les groupes de données entrant et sortants du
domaine d’étude pour construire le modèle de contexte.
2. Identifier les activités générant ou traitant les flux de données
pour construire le DFD niv1 (approche par données) ou
identifier une activité de niv 1 comme un ensemble d’activités
participant à une même finalité (approche par objectifs)
3. Quand une activité est ininterruptible (le traitement se
déroule sans attente de ressources extérieures), elle est alors
une opération conceptuelle.
C. Diagramme états/transitions: décrit le comportement du
système en représentant ses états et les événements qui
causent le changement de l’état du système. En plus, il
indique quelles actions sont prises comme conséquence d’un
événement particulier.
