Méthodes de développement. Analyse des exigences (spécification)

1 / 16 Méthodes de développement Analyse des exigences (spécification) 1 -Objectifs de l'analyse des exigences... 2 2 - Approfondissement et formalisation du besoin... 2 2.1 Séparation des besoins, contraintes et solutions... 2 2.2 Approfondissement des besoins... 2 3 - Place de l'activité dans le développement... 3 3.1 Conditions de démarrage... 3 3.2 Cas du développement séquentiel... 3 3.3 Cas des méthodes itératives (hors méthodes agiles)... 3 3.4 Cas des méthodes agiles... 4 4 - Principaux travaux... 4 5 - Les documents d'exigence... 5 6 - Rédaction de l'introduction d'une STB ou SGB... 6 7 - Mission du système... 6 8 - Liste de fonctionnalités et règles métier (SGB pour méthodes agiles)... 7 9- Détail des cas d'utilisation (STB UML)... 8 9.1 Les cas d'utilisation... 8 9.2 Découpage en cas d'utilisation... 8 9.3 Comment trouver les cas d'utilisation... 8 9.4 Cas d'utilisation abstraits... 9 9.5 Rédaction d'un cas d'utilisation... 9 9.6 Séquence des événements... 9 9.7 Spécifications complémentaires... 10 10 - Exigences fonctionnelles et interfaces (STB structurée)... 10 10.1 Décomposition arborescente... 10 10.2 Description des fonctions... 11 10.3 Diagrammes type SADT... 12 10.4 Interfaces... 12 11 - Les exigences complémentaires... 12 11.1 Environnement du système... 13 11.2 Mise en œuvre... 13 11.3 Disponibilité... 13 11.4 Dimensionnements et performances... 13 11.5 Contraintes de conception et de réalisation... 13 11.6 Validation et recette... 13 11.7 Livraison et soutien... 13 12 -Traçabilité des exigences... 14 13 - Adaptation des documents d'exigence à la réutilisation de logiciels... 14 14 - La gestion des exigences... 15 15 - La revue de spécification logiciel... 16

2 / 16 1 -Objectifs de l'analyse des exigences L'analyse des exigences est la première activité d'un développement de logiciel ou de système à logiciel prépondérant. Les objectifs de l'analyse des exigences (appelée couramment spécification) sont de : - approfondir, préciser et formaliser les besoins exprimés par le client, - se mettre d'accord avec le client sur cette formalisation, - obtenir le document de base du développement (STB spécification technique de besoins ou SGS spécification générale de besoins) permettant le démarrage de la conception de l'architecture, - préparer la validation et la recette du produit. 2 - Approfondissement et formalisation du besoin 2.1 Séparation des besoins, contraintes et solutions En principe, l'analyse du besoin est faite à partir d'un cahier des charges fourni par le client. S'il n'y en a pas, il faudra d'abord cerner le besoin et reconstituer les informations de ce cahier des charges par des interviews, l'analyse de documents Le cahier des charges peut contenir des besoins fonctionnels, des contraintes, des solutions imaginées par le client La spécification technique de besoins ne doit contenir que les exigences : besoins et contraintes, et ne pas imposer de solutions. En effet c'est au niveau de la conception que doivent être choisies les solutions, et les solutions imaginées au départ ne sont pas toujours les plus intéressantes. Il faut donc à partir du cahier des charges du client, identifier : - ce qui est un besoin du client, - ce qui est une contrainte, - ce qui est une solution possible. Exemple de définition de solution possible dans le cahier des charges " le position du mobile sera obtenue par intégration numérique des équations du mouvement par l'algorithme de Runge Kutta d'ordre 4" Obtenir la position du mobile par intégration des équations du mouvement est certes un besoin, mais le faire numériquement par l'algorithme de Runge Kutta d'ordre 4 est une solution qui n'est pas forcement la meilleure. En effet il n'est pas impossible que le système d'équations différentielles puisse être résolu de façon théorique si les équations sont simples, et parmi les méthodes numériques il en existe d'autres qui peuvent être plus simples à mettre en œuvre ou plus adaptées à la précision souhaitée telles que les algorithmes de tangente améliorée, les algorithmes à pas liés 2.2 Approfondissement des besoins Lorsqu'on a identifié un besoin, il sera en général exprimé de façon concise. Il faut l'approfondir et le préciser pour pouvoir vérifier avec le client que cela correspond bien à son besoin et préparer la conception et le codage.

3 / 16 Par exemple, si vous vous reportez au cahier des charges présenté dans l'introduction aux guides de rédaction, vous verrez qu'il faut définir des horaires pour des lignes de car. Il y a beaucoup de manières de définir des horaires : uniquement les heures au départ de la ligne, pour en plus le terminus et les arrêts principaux, pour tous les arrêts, en heure absolue, en relatif à l'heure de départ au début de la ligne Il va falloir choisir une solution, vérifier qu'elle convient bien au problème posé, et détailler les informations à entrer pour définir des horaires. 3 - Place de l'activité dans le développement 3.1 Conditions de démarrage L'analyse des besoins est la première activité du développement et doit être lancée au début du projet avec l'activité d'organisation du projet. Pour la démarrer il faut réunir la documentation nécessaire pour sa réalisation : - cahier des charges du client, - documentation du système (quand elle existe), - résultats d'études préliminaires qui ont pu être faites avant le projet ou lors de la préparation du projet, - spécifications des interfaces, - maquettes éventuelles déjà réalisées, - documentation technique. Il faut de plus avoir fait le choix de la méthode de développement, des techniques utilisées pour spécifier (par exemple spécification UML), et des outils employés pour rédiger ou illustrer la spécification, et éventuellement pour gérer les exigences. 3.2 Cas du développement séquentiel Dans un développement de type séquentiel, l'analyse des besoins est faite complètement et une Spécification Technique de Besoins (STB) est entièrement rédigée avant de passer à l'activité suivante de conception de l'architecture. 3.3 Cas des méthodes itératives (hors méthodes agiles) Dans une méthode itérative (non agile), on rédige une STB de façon incrémentale en la complétant à chaque itération. Dans la première version on s'attachera par exemple à faire le plan complet de la STB, rédiger en grande partie le chapitre mission, rédiger une partie du détail des fonctions ou des cas d'utilisation, et entamer la rédaction des exigences complémentaires. Dans chacune des itérations suivantes, on rédigera des fonctions ou cas d'utilisation supplémentaires en fonction des incréments fonctionnels définis pour chaque itération, et on complétera et mettra à jour les parties déjà rédigées. Il faudra faire en sorte dans la définition des objectifs des itérations que les fonctions ou cas d'utilisation soient rédigés avant de faire la conception puis le codage des parties de l'application correspondantes.

4 / 16 Cependant il est aussi possible dans un développement itératif de rédiger entièrement la STB à la première itération, et de ne faire lors des itérations suivantes que les mises à jour qui s'avèreraient nécessaires. 3.4 Cas des méthodes agiles Il est nécessaire de faire une analyse du besoin au début du développement pour savoir quelles seront les fonctionnalités à implémenter. A l'inverse des méthodes classiques, dans les méthodes agiles, on recommande de ne pas faire d'analyse détaillée au début du développement, mais uniquement au moment d'implémenter la fonctionnalité. Le réalisateur qui a une fonctionnalité à coder approfondira le besoin à travers le codage ou la définition des tests, présentera le résultat au client, et modifiera en fonction des remarques du client. Cela s'approche d'une démarche par approximations successives. Dans ces conditions il n'y a pas besoin de rédiger une Spécification Technique de Besoins avec tout le détail des fonctions ou cas d'utilisation. Il est cependant utile d'avoir un document de besoin pour présenter l'utilisation du produit, les contraintes à respecter et lister les fonctionnalités à implémenter. Ce document pourrait être appelé Spécification Générale de Besoins (SGB) pour le distinguer d'une Spécification Technique de Besoin classique et contenir : - la présentation de la mission du système, - une liste des fonctionnalités, - les règles métier et interfaces à respecter, - des exigences complémentaires. 4 - Principaux travaux Le travail principal est de trier, préciser et formaliser les besoins et les contraintes. On partira pour cela de la documentation disponible pour recenser les besoins et les contraintes, puis on approfondira les besoins et les contraintes. Cela pourra se faire par analyse de la documentation disponible, interviews du maître d'ouvrage, de futurs utilisateurs ou d'experts du domaine, propositions soumises au client, recherche de documents supplémentaires Il est recommandé d'établir pour chaque interview un compte rendu indiquant les informations complémentaires obtenues par rapport au cahier des charges. Ces comptes-rendus pourront être, après accord du client, considérés comme des compléments au cahier des charges. La spécification technique de besoins (STB) ou la spécification générale de besoins (SGB) sera rédigée. Les besoins et contraintes seront mis en forme pour y être intégrés. La mise en forme dépend de la technique de spécification choisie et sera présentée plus loin. Il faut de plus vérifier que toutes les exigences et contraintes exprimées dans le cahier des charges et les documents qui le complètent ont bien été prises en compte dans la STB ou la SGB. Pour cela on pourra faire une liste des exigences de besoin ou de contrainte du cahier des charges et des documents qui le complètent et montrer dans une matrice de traçabilité la correspondance avec les paragraphes de la STB ou la liste des fonctionnalités de la SGB.

5 / 16 Il faut aussi identifier les interfaces du logiciel ou du système, et les caractéristiques d'utilisation du logiciel ou système (par exemple la disponibilité) pour les intégrer dans la STB ou la SGB. Pour compléter, il faudra définir dans leur principe les opérations de validation et de recette : lieu des opérations, moyens nécessaires, tests à effectuer Dans le cas d'une STB, un objectif majeur est de montrer au client que l'on à bien compris son problème et se mettre d'accord avec sur les besoins et contraintes à prendre en compte. Pour cela : - la STB sera rédigée en langage clair, - le plan type imposé par la méthode sera suivi, - la STB sera fournie au client pour approbation, - une revue de spécification sera tenue avec le client (si possible). Dans le cas des méthodes agiles, le client doit en principe collaborer de façon quasi permanente au projet, et le rôle du document d'exigences (SGB) est plus limité. 5 - Les documents d'exigence Les documents d'exigence recensent tous les besoins identifiés sous forme de fonctions à remplir et de contraintes, de façon plus ou moins détaillée selon le type de document. Les documents d'exigence sont les documents de base pour la conception de l'architecture du logiciel où on recherche une solution capable de satisfaire toutes les exigences et contraintes identifiées. Ces documents seront aussi la référence pour la définition des essais de validation. Avant l'apparition des techniques UML, il était recommandé de baser une STB sur les techniques d'analyse structurée type SADT (Structured Analysis and Design Technique) avec une décomposition arborescente des fonctions. Une STB comprenait 4 grandes parties : - la mission du logiciel, - les exigences fonctionnelles (décomposition arborescente et diagrammes type SADT/SART), - les exigences d'interface, - les exigences complémentaires (environnement, mise en œuvre, disponibilité, sécurité, contraintes de conception et de réalisation ). Avec l'apparition d'uml, les méthodes de conception objet ont couvert l'aspect analyse des besoins grâce au modèle des cas d'utilisation. Dans une STB type UML, on retrouvera les parties mission du logiciel et exigences complémentaires, et les parties exigences fonctionnelles et exigences d'interface sont regroupées dans les cas d'utilisation qui définissent les services rendus aux utilisateurs et autres acteurs du système. Dans les méthodes agiles, la rédaction des exigences détaillée n'apparaît ni nécessaire ni souhaitable. On remplacera les exigences fonctionnelles ou le modèle des cas d'utilisation par une simple liste de fonctionnalités et les contraintes de type règle métier ou interface. On arrive donc pour les documents d'exigence aux parties suivantes :

6 / 16 STB structurée STB UML SGB (méthodes agiles) Introduction Introduction Introduction Mission du logiciel Mission du logiciel Mission du logiciel Exigences fonctionnelles Modèle des cas d'utilisation Liste des fonctionnalités Exigences d'interface Règles métier et interfaces Exigences complémentaires Exigences complémentaires Exigences complémentaires Traçabilité des exigences Traçabilité des exigences La STB type UML décrit les fonctionnalités vues par les utilisateurs à travers les cas d'utilisation. Elle est donc bien adaptée aux logiciels de type interactif où la plupart des fonctionnalités découlent d'actions opérateur. La STB structurée décrit les fonctionnalités par une décomposition arborescente de fonctions. Elle est bien adaptée aux logiciels de type scientifique ou industriel où il y a des algorithmes à définir et peu d'interaction utilisateur. La SGB ne décrit pas le détail, elle est adaptée aux méthodes agiles. Il est donc recommandé pour chaque projet de choisir le type de spécification le mieux adapté à la dominante du projet. Les rédactions d'une STB type UML ou d'une SGB font l'objet de guides détaillés avec un exemple. On se limitera donc dans la suite de ce cours à présenter les principes. 6 - Rédaction de l'introduction d'une STB ou SGB L'introduction d'une STB ou SGB précise - l'objet du document (nom du système, rôle du système, environnement d'utilisation du système, limites d'utilisation importantes), - la terminologie et sigles utilisés (abréviations employées et termes ayant un sens particulier), - les documents de référence (documents auxquels la STB ou SGB se réfère, qu'elle impose, ou qui la complètent). Le plan suivant est proposé pour cette partie : 1- Introduction 1.1 Objet 1.2 Terminologie et sigles utilisés 1.3 Documents de référence 7 - Mission du système La mission du système est la seule partie descriptive de la spécification, elle doit être suffisamment claire et détaillée pour permettre de comprendre le fonctionnement du système. Elle comprendra : - les objectifs du système et les principaux services attendus par les utilisateurs,

7 / 16 - la composition du système en matériels, réseaux et éventuellement logiciels et la présentation des configurations d'utilisation, - les principes de fonctionnement du système vus des utilisateurs, - les utilisateurs du système et leur rôle, - les autres acteurs (matériels, logiciels ou systèmes en interface) et leur rôle (spécification UML), - une description rapide des services offerts aux utilisateurs (et autres acteurs), - pour une spécification UML, la liste des cas d'utilisation classés par groupes avec la correspondance avec les services offerts, - pour une spécification structurée, une description de scénarios typiques d'utilisation. Nota 1 En UML les acteurs sont : - les utilisateurs du système, soit qu'ils soient directement opérateurs du système (devant un terminal ou un micro-ordinateur), soit qu'ils l'utilisent de façon moins directe (par l'intermédiaire d'éditions, par l'exploitation de fichiers générés par le système, par la fourniture de données ), - les autres systèmes, matériels ou logiciels en interface avec le système. Nota 2 Dans une spécification UML les cas d'utilisation représentent des scénarios d'utilisation qui seront présentés dans le détail des cas d'utilisation. Le plan type suivant est proposé pour cette partie : 2 -Présentation de la mission du système 2.1 Objectifs 2.2 Composition du système 2.3 Principes de fonctionnement 2.4 Utilisateurs et acteurs 2.5 Services offerts et cas d'utilisation (ou scenarios d'utilisation) 8 - Liste de fonctionnalités, règles métier et interfaces (SGB pour méthodes agiles) Dans une méthode agile, on ne rédige pas le détail des fonctions ou cas d'utilisation. Il est cependant utile d'identifier les fonctionnalités à implémenter, cela servira pour définir le contenu et les plannings des itérations, et suivre l'avancement de la réalisation. On établira donc une liste des fonctionnalités à implémenter. On pourra partir des services et cas ou scenarios d'utilisation présentés au paragraphe précédent, et décomposer chacun en fonctionnalités pour le client. On pourra les présenter dans un tableau en indiquant pour chacune une priorité de réalisation. En complément on essaiera de recenser les règles métier et interfaces que devra respecter le logiciel pour être utilisable. Ces règles peuvent provenir d'obligations légales, des usages de la profession, du référentiel de la société, des méthodes de travail du client... Elles devront être prises en compte dans la conception et le codage du logiciel et leur respect vérifié par des tests.

8 / 16 Par exemple dans un logiciel de facturation dans un contexte BtoB (business to business), on pourra trouver : - le respect des champs imposés par le ministère des finances dans les factures, - la facturation en prix hors taxe avec ajout de la TVA in fine, - l'application de taux de TVA différenciés selon le type de produit, et la possibilité de modifier les taux de TVA Les interfaces à respecter peuvent être des interfaces matérielles imposés (par exemple le type de réseau), ou des interfaces logiciel (par exemple l'utilisation d'une base de données existante). On pourra pour ces règles les définir dans le document ou renvoyer à un document de référence. 9- Détail des cas d'utilisation (STB UML) Cette partie spécifie de façon détaillée les cas d'utilisation (y compris les cas d'utilisation abstraits). Si les cas d'utilisation dépassent quelques unités, on les présentera groupe par groupe. On arrive alors au plan suivant pour cette partie : 3 - Détail des cas d'utilisation 3.1 Groupe de cas d'utilisationg1 3.1.1 Cas d'utilisation G1.1 3.1.i Cas d'utilisation G1.i 3.j Groupe de cas d'utilisation Gj 3.j.k Cas d'utilisation Gj.k 9.1 Les cas d'utilisation Les cas d'utilisation définissent les services rendus par le système aux différents acteurs. Un cas d'utilisation définit une séquence d'événements, du point de vue d'un (ou plusieurs) acteurs, qui aboutit à un résultat observable. Pour un acteur de type utilisateur, il définit les fonctions à assurer pour rendre les services attendus. Pour un acteur de type système, matériel ou logiciel en interface, il définit les fonctions à assurer pour l'interface. 9.2 Découpage en cas d'utilisation Les fonctionnalités du système sont réparties entre les cas d'utilisation correspondant à des séquences d'événements. Pour rendre la spécification compréhensible, il est recommandé de regrouper dans un même cas d'utilisation les événements liés entre eux et les séquences d'événements similaires. Il ne faut pas faire des cas d'utilisation trop petits, mais il faut aussi éviter l'excès inverse (ne faire qu'un seul cas d'utilisation!). 9.3 Comment trouver les cas d'utilisation La première source est l'examen de tous les services identifiés que le système doit rendre aux différents acteurs. Chaque service devra faire partie de l'un des cas d'utilisation du système.

9 / 16 Pour compléter le modèle, on examinera les aspects complémentaires non couverts par les services identifiés, par exemple : - démarrage et arrêt du système, - interfaces du système, - administration du système, par exemple création ou modifications de mots de passe, journal de bord - sauvegarde et restauration des données, initialisations de fichiers ou bases de données 9.4 Cas d'utilisation abstraits Pour faciliter et simplifier la rédaction, il est possible de définir des cas d'utilisation abstraits. Ces cas d'utilisation abstraits pourront définir des séquences d'événements utilisées dans un ou plusieurs autres cas d'utilisation, par exemple pour détailler un traitement ou définir une fonction commune. On peut aussi définir dans un cas d'utilisation abstrait des propriétés communes et en faire hériter d'autres cas d'utilisation (relation de type généralisation ou héritage). 9.5 Rédaction d'un cas d'utilisation Un nom doit être donné à chaque cas d'utilisation, composé de quelques mots et différent des noms de tous les autres cas d'utilisation. Il doit être significatif du contenu du cas d'utilisation. Le plan type d'un cas d'utilisation est le suivant : Brève description Références Séquence des événements Séquence nominale Séquences alternatives Spécifications complémentaires Données en entrée Données en sortie Traitements Autres exigences La brève description décrit en quelques lignes le rôle et l'objet du cas d'utilisation en se référant aux acteurs. Les références peuvent indiquer les paragraphes du cahier des charges ou de la partie mission de la spécification concernés, les autres cas d'utilisation appelés 9.6 Séquence des événements La séquence des événements décrit de façon claire et compréhensible la suite des événements (actions opérateurs, traitements faits par le système, commandes faites par le système, affichages ou éditions ). Elle doit indiquer ce que le système fait, et non comment il doit le réaliser. Les règles à respecter sont : - décrire comment le cas d'utilisation débute et finit, - décrire quelles données sont échangées entre l'acteur et le cas d'utilisation,

10 / 16 - ne pas décrire le détail de l'interface utilisateur, sauf si c'est nécessaire pour comprendre le comportement du système, - décrire la séquence des événements et pas seulement la fonctionnalité ; commencer chaque action par "Quand l'acteur ", - décrire seulement les événements qui appartiennent au cas d'utilisation, et pas ce qui arrive dans d'autres cas d'utilisation ou à l'extérieur du système. La séquence nominale est ce qui arrive "normalement". Les séquences alternatives couvrent ce qui arrive dans certains cas ou lors d'erreurs. Pour rendre le document lisible, il est recommandé de structurer la séquence de base et les séquences alternatives en étapes, et de faire des paragraphes numérotés avec un titre. On peut aussi illustrer la séquence de base et les séquences alternatives par des diagrammes. 9.7 Spécifications complémentaires La séquence d'évènements décrit des évènements qui peuvent nécessiter des données d'entrée, faire des traitements, générer des données en sortie Les spécifications complémentaires précisent ces données et ces traitements. On peut aussi trouver d'autres exigences pour le cas d'utilisation, on les mettra alors dans un paragraphe autres exigences, par exemple : - des contraintes de performances ou de disponibilité, - des contraintes sur l'état du système au début du cas d'utilisation et en fin de cas d'utilisation. Ces exigences ne sont à mettre ici que si elles ne se rapportent qu'à ce cas d'utilisation, si elles se rapportent à l'ensemble du système, elles sont à mettre dans les exigences complémentaires de la STB. 10 - Exigences fonctionnelles et interfaces (STB structurée) 10.1 Décomposition arborescente Dans une STB structurée, les fonctionnalités sont décrites sous forme d'une décomposition arborescente de fonctions. On découpe d'abord les fonctionnalités en fonctions de premier niveau représentant les grandes fonctions du système. Chaque fonction de premier niveau est ensuite décomposée en fonction de deuxième niveau, puis on refait des décompositions jusqu'à obtenir des fonctions raisonnablement simples à définir. Le nombre de niveau dépendra de la complexité du problème et peut varier avec les fonctions. Il faut faire attention à se limiter à un nombre raisonnable de fonctions.

11 / 16 SYSTEME FONCTION F1 FONCTION F2 FONCTION F3 FONCTION F4 FONCTION F2.1 FONCTION F2.2 FONCTION F2.3 10.2 Description des fonctions Pour la rédaction, le plan de cette partie sera calqué sur la décomposition arborescente des fonctions. Elle sera découpée selon les fonctions de premier niveau. Pour chaque fonction de premier niveau, un paragraphe décrira cette fonction, puis les paragraphes suivants décriront les fonctions de niveau inférieur incluses dans cette fonction. La description aura la forme suivante : 3.i.1 Description de la fonction Fi 3.i.1.1 Objet et composition 3.i.1.2 Evénements déclencheurs 3.i.1.3 Données en entrée 3.i.1.4 Données en sortie 3.i.1.5 Traitements 3.i.2 Description de la fonction Fi.1 3.i.3 Description de la fonction Fi.1.1 L'objet indique le rôle de la fonction et la décomposition de la fonction au niveau suivant. Les événements déclencheurs indiquent comment est activée la fonction (commande opérateur, appel par autre fonction ) Les données en entrée et les données en sortie définissent les principales données à l'entrée dans la fonction, et à la sortie de la fonction. Les traitements détaillent la séquence des événements, en précisant les fonctions appelées lorsqu'il y en a (fonctions issues de la décomposition de la présente fonction ou autres fonctions du système), et les algorithmes de calcul pour les fonctions de dernier niveau.

12 / 16 10.3 Diagrammes type SADT Il est recommandé d'appuyer la décomposition fonctionnelle sur des diagrammes fonctionnels structurés type SADT montrant les interactions entre fonctions. Exemple de diagramme type SADT : F1 FLUX k FONCTION F2.2 FLUX 21 FONCTION F2.1 F4 FLUX i FONCTION F2.3 10.4 Interfaces On complétera les exigences fonctionnelles par la définition des interfaces qu'on pourra classer par types d'interface : 4 - Interfaces 4.1 Interfaces avec des matériels 4.2 Interfaces avec d'autres produits logiciels 4.3 Interfaces avec des fichiers ou bases de données 4.4 Interfaces homme - machine 11 - Les exigences complémentaires On aborde dans cette partie les exigences qui portent sur l'ensemble du système, ces exigences dépendront du type de système, on pourra par exemple aborder les aspects suivants : 5 -Exigences complémentaires 5.1 Environnement du système 5.2 Mise en œuvre 5.3 Disponibilité 5.4 Dimensionnements et performances 5.5 Contraintes de conception et de réalisation 5.6 Validation et recette 5.7 Livraison et soutien

13 / 16 11.1 Environnement du système On précisera les matériels, logiciels et systèmes en interface avec le système, s'il y en a. On indiquera leur rôle et leurs principales caractéristiques. On précisera le type d'interface, et si besoin, on définira cette interface de façon détaillée. 11.2 Mise en œuvre Les exigences concernant la mise en œuvre du système seront précisées, ainsi que les procédures utilisées pour l'initialisation, l'exploitation et l'arrêt du système (si elles ne sont pas définies dans les cas d'utilisation) 11.3 Disponibilité On précisera les périodes de fonctionnement du système, les objectifs de disponibilité s'il y en a, les contraintes sur les délais de réparation ou de reconfiguration et réinitialisation après incident. 11.4 Dimensionnements et performances On précisera les paramètres dimensionnant du système : par exemple nombre de postes, nombre d'utilisateurs simultanés, tailles des tables de base de données On précisera aussi les performances globales du système et les conditions dans les quelles elles doivent être atteintes (par exemple avec N utilisateurs simultanés) : temps de réponse à une requête, délai de recherche en base de données, nombre de transactions traitées par seconde 11.5 Contraintes de conception et de réalisation Les contraintes de conception peuvent porter sur : - l'utilisation de matériels, logiciels ou réseaux imposés, - l'utilisation de normes, de standards d'interface, - l'utilisation d'une méthode de conception objet. Les contraintes de réalisation peuvent porter sur : - le choix d'un langage de programmation, - des règles ou standards de programmation, - le traitement des erreurs, - l'utilisation d'outils d'aide au développement (compilateur, aide à la mise au point, gestionnaire de configuration ) 11.6 Validation et recette Si la validation du logiciel doit être faite, on définira tous les essais à réaliser pour pouvoir effectuer cette validation. Si le logiciel doit être recetté, on précisera les opérations à réaliser pour la recette. 11.7 Livraison et soutien On précisera sous quelle forme doit être livré le système et le logiciel du système, et les travaux d'installation s'ils sont prévus.

14 / 16 On précisera les moyens nécessaires pour assurer le soutien du système en service : maintenance matériel, maintenance logiciel, matériels et pièces de rechange, formations 12 -Traçabilité des exigences La traçabilité doit permettre de savoir dans une STB : - quelle est l'origine des exigences énoncées dans la STB, - si toutes les exigences du client ont bien été prises en compte dans la STB. Pour cela on fait une matrice indiquant pour chaque exigence : - l'intitulé de l'exigence, - la référence d'origine (nom du document, paragraphe alinéa), - la référence dans la STB (paragraphe, alinéa). Pour pouvoir répondre aux deux questions, on pourra présenter la matrice d'une part classée par référence d'origine, d'autre part classée par référence STB. 13 - Adaptation des documents d'exigence à la réutilisation de logiciels. La théorie voudrait que les documents d'exigence soient rédigés sans faire d'hypothèses sur les solutions qui seront retenues pour réaliser le logiciel, et que les solutions soient ensuite choisies lors de la conception de l'architecture. La réalité est un peu différente. En effet le processus est de nature itérative. Lors de la préparation du projet il faut déjà faire une esquisse de solution pour établir le plan de développement et estimer le coût du projet. On a donc déjà une esquisse de solution lors de la rédaction du document d'exigence, et si le document d'exigence conduit à une remise en cause complète de la solution, cela va conduire à de gros problèmes au niveau des coûts et délais du projet. Si l'esquisse de solution est qu'une grande partie du logiciel doit faire l'objet d'un développement et que les logiciels réutilisés ne peuvent couvrir que des fonctions périphériques ou accessoires, on peut alors écrire le document d'exigence sans faire d'hypothèses sur les solutions, et indiquer dans le paragraphe contraintes de conception et de réalisation les logiciels à réutiliser. Cependant de nombreux logiciels sont aujourd'hui réalisés en intégrant entre eux des logiciels existants, ou en paramétrant des progiciels. Cela n'ôte pas d'intérêt à la démarche de commencer par approfondir le besoin et rédiger un document d'exigence, puis de définir l'architecture. Cependant il faudra adapter le contenu du document d'exigence pour prendre en compte le fait que des fonctions importantes seront réalisées par des logiciels existants. En effet il ne servirait à rien de décrire dans le détail des séquences d'événements qui ne seraient pas réalisables avec les logiciels existants, ni de décrire dans le détail les séquences d'événements engendrées par les logiciels existants.

15 / 16 On pourra donc adapter ainsi un document d'exigences : - dans la partie mission du logiciel, on présentera rapidement les fonctions des logiciels réutilisés en renvoyant à la documentation de ces logiciels qui figurera dans les documents de référence, - dans la présentation des services, on indiquera ce qui est pris en charge par les logiciels réutilisés, - pour une STB type UML, dans le détail des cas d'utilisation, on ne cherchera pas à décrire les séquences d'événements liées aux logiciels réutilisés, mais plutôt à considérer ces logiciels comme des boites noires et à décrire les enchaînements, et les entrées et sorties de ces logiciels. 14 - La gestion des exigences Une STB définit un ensemble d'exigences, besoin et contraintes. Ces exigences peuvent varier au cours du développement et de la maintenance, soit suite à des demandes du client, soit à la suite de problèmes rencontrés par l'équipe de développement. Une procédure de gestion des évolutions devra être mise en place dans le cadre de la gestion de configuration pour contrôler ces évolutions. La STB est la référence du développement et la base des opérations de validation, et il faut la mettre à jour lorsque les exigences évoluent. Si les évolutions des exigences sont peu nombreuses, on peut à chaque évolution d'exigence faire une nouvelle édition de la STB ou rédiger un complément à la STB. Ce type de solution n'est pas viable pour des systèmes très volumineux ou très évolutifs, et il faut passer à la technique des bases d'exigences. Il existe des outils sur le marché (par exemple Requisite Pro de Rational) qui extraient du texte d'une STB les exigences élémentaires et constituent une base de données. Lorsque les exigences évolueront par la suite, il suffira de mettre à jour la base de données. Cette base de données pourra être utile pour établir les matrices de traçabilité, définir le plan et les procédures de qualification (où on doit s'assurer que chaque exigence de la STB est prise en compte) et suivre la prise en compte des modifications d'exigences. Cependant pour que les outils puissent travailler il faut identifier les exigences élémentaires pendant la rédaction de la STB. Une solution possible est de mettre entre crochet les exigences élémentaires en leur donnant un identificateur. Exemple de rédaction d'une séquence de cas d'utilisation 2.1.1 Début [EX3.1 Quand l'usager sélectionne le service achat de billets au simulateur de borne, le simulateur affiche la liste des arrêts avec le numéro de zone tarifaire, et des boutons de sélection de zone tarifaire]. [EX3.2 Une touche annulation sera aussi affichée en permanence]. 2.1.2 Zone tarifaire L'usager sélectionne la zone tarifaire 2.1.3 Nombre de billets

16 / 16 [EX3.3 Le simulateur affiche un clavier permettant d'entrer le nombre dans la limite de 99. L'usager entre le nombre de billets désiré]. 15 - La revue de spécification logiciel Une STB est le document de référence pour le développement. Il faut s'assurer qu'elle prend bien en compte le besoin du client. Il est donc recommandé de faire dès que possible dans le développement une revue de spécifications avec le client. Cette revue pourra avoir lieu à la fin de l'activité analyse des exigences dans un développement séquentiel, et à la fin d'une itération dès que la STB sera jugée assez complète dans un développement itératif. Pour une revue, on constitue un groupe de revue avec des membres de l'équipe de projet, des représentants du client et éventuellement des experts du domaine. On fournit à tous les membres du groupe de revue les documents soumis à revue (ici la STB), les documents de référence des documents soumis à revue, et les autres documents utiles à la compréhension. Les membres du groupe de revue analysent la documentation soumise à revue et font des remarques ou demandes d'explication. L'équipe de projet analyse ces remarques et demandes et y répond. Le groupe de revue termine en faisant des recommandations au client et au fournisseur. Dans une méthode agile, le besoin est analysé tout au long du développement et le client peut alors donner son avis. La revue de spécification logiciel présente beaucoup moins d'intérêt.