Вы находитесь на странице: 1из 12

Spcifications des exigences d'un logiciel

(Adapt de la norme IEEE 830-1993 et comment) Ce document suggre un ensemble des items prciser pour les exigences d'un systme logiciel. Page titre Table des matires Liste des illustrations 1. Introduction Vue d'ensemble de tout le document des exigences. 1.1 Objectif du document Dlimiter le but du document et prciser le public auquel il est destin. 1.2 Porte du produit logiciel Identifier le systme logiciel par un nom Expliquer brivement ce qu'il doit faire et ne pas faire Dcrire le contexte de l'application dans lequel le produit s'intgre, incluant les objectifs, les bnfices et retombes du projet. Faire un rappel sommaire des conclusions de l'tude d'opportunit (si elle existe) et un lien au document de spcification globale du produit (s'il existe). 1.3 Dfinitions, acronymes et abrviations Dfinir de tous les termes propres au domaine de l'application, les acronymes et les abrviations, ncessaires une bonne comprhension et interprtation du document. 1.4 Documents de rfrence Lister tous les documents, normes, rapports, etc., pertinents la comprhension du dossier et identifier leurs origines. Renvoyer aux annexes au besoin. 1.5 Aperu du document Dcrire le contenu du reste du dossier et expliquer comment il est organis. 2. Description gnrale du produit logiciel Situer le cadre gnral du produit dvelopper et dcrire les facteurs qui peuvent l'affecter. S'en tenir une description de porte gnrale dont les dtails seront spcifis dans la troisime partie de ce document. 2.1 Perspective du produit

Prsenter une description sommaire du produit et de son environnement. Dcrire sa place dans le systme, par rapport aux autres produits qui en font partie. Inclure, au besoin, les diagrammes appropris. Identifier toutes les interfaces logicielles et matrielles du produit - aux autres composantes du domaine d'application - aux composantes matrielles (ports, jeu dinstructions) - aux composantes logicielles (SGBD, systmes dexploitation, progiciels) - aux tlcommunications (protocoles de rseaux locaux, TCP/IP ...). Les interfaces aux utilisateurs seront prsentes dans la section 3. 2.2 Vue d'ensemble des fonctionnalits du produit Sommaire des principales fonctionnalits du logiciel ( dtailler en section 3) pour donner un aperu au lecteur. 2.3 Caractristiques des utilisateurs Dcrire le niveau de formation, d'exprience et de connaissances technologiques particulires des utilisateurs ventuels et des oprateurs du produit. 2.4 Contraintes d'ordre gnral Description des contraintes qui vont limiter les options de dveloppement - externes l'entreprise (lois et rglements) - internes (politique administrative, de gestion, d'audit) - associes aux interfaces d'autres systmes (matriel ou logiciel) - relies des aspects critiques de l'application ou des donnes - relies la sret, la scurit et la fiabilit de l'application. 2.5 Hypothses et dpendances Prmisses de base qui affectent les exigences (par exemple, la disponibilit d'une version d'un systme dexploitation particulier) et qui entraneraient des modifications si elles ne se ralisaient pas. 2.6 Rpartition des exigences Identifier les exigences et fonctionnalits immdiates et celles que lon peut retarder pour des versions et livraisons ultrieures du produit. 3. Exigences spcifiques - description dtaille Dcrire toutes les exigences un niveau suffisamment dtaill pour procder avec la conception du produit et llaboration des tests. Au minimum, cela comprend la

description de chaque stimulus (entre), de chaque rponse (sortie) et de tous les traitements (fonctions) effectus par le systme. Section la plus importante du document. Toutes les exigences doivent tre identifiables et traables. L'organisation de cette section telle que prsente ici est approprie pour l'analyse oriente objet avec la notation UML. [Voir le sommaire "Livrables modlisation"] 3.1 Modle environnemental et interfaces externes Rsultats de l'analyse de l'environnement. Description dtaille de toutes les fonctionnalits du produit sur la base des cas d'utilisation et des scnarios. Inclut les dessins d'crans et les formats des rapports s'ils ne sont pas inclus dans le guide de l'utilisateur. 3.1.1 Les diagrammes des cas d'utilisation Montrer toutes les interactions significatives entre le systme et les acteurs utilisateurs. 3.1.2 Les scnarios de transaction La description des principaux scnarios des cas d'utilisation 3.1.3 Ecrans d'interface utilisateur Dessin des crans et des menus correspondant aux cas d'utilisation 3.1.4 Format des rapports Dessin des rapports de sortie. 3.2 Description des fonctionnalits Les exigences fonctionnelles dfinissent les actions fondamentales pour accepter les entres, effectuer les traitements et gnrer les sorties. Sur la base des des cas d'utilisation et des scnarios de transaction, prsenter les modles structural et comportemental du systme. 3.2.1 Le modle structural Modle global de classes avec associations. Modles d'objets de chaque scnario, incluant les attributs et les mthodes. Le rpertoire des classes d'objets (identit, dfinition, attributs, mthode, super-classe, association et objet associ). A prsenter en appendice. 3.2.2 Le modle comportemental

Evolution du comportement de chacune des fonctionnalits. Pour chaque cas d'utilisation, prsenter un ou plusieurs parmi les diagrammes suivants (selon les besoins): Diagramme de squence, qui montre l'volution des interactions acteursobjets dans le temps Diagrammes de transition d'tat, qui montrent la squence des tats successifs dans la vie d'un objet Diagrammes d'activit, qui montrent les flux d'activit internes d'un objet Diagramme de collaborations, qui montre les flux de messages entre objets et les rles des objets participants. Le rpertoire de description des mthodes non-triviales(ou contrats), qui dcrit les mthodes des classes. A prsenter en appendice. 3.3 Exigences d'oprations et de performance Exigences quantitatives statiques et dynamiques. Par exemple: - Nombre de terminaux supporter - Nombre dutilisateurs actifs en simultan - Quantit et types dinformation traiter - Temps de rponse une requte d'information - Nombre moyen de transactions par seconde - Nombre de transactions minimal et maximal requis la seconde 3.4 Exigences logiques de bases de donnes Pour les informations persistantes de chaque classe du modle structural, indiquer - Frquence dutilisation - Volume normal conserv dans une anne - Taux de croissance de l'information - Contraintes dintgrit - Exigences de rtention des donnes 3.5 Contraintes de conception Imposes par d'autres standards, limites de matriels, etc. Respect des lois, rglements et pratiques, par exemple:

- Format des rapports - Nomenclature des donnes - Procdures de comptabilit - Exigences daudit, traabilit des traitements. 3.6 Exigences non-fonctionnelles [Voir aussi "Spcification des exigences non-fonctionnelles"] Caractristiques du produit logiciel, selon les besoins particuliers de l'application: Fiabilit Disponibilit Scurit: Protection contre intrusions, modification, destruction ... Maintenabilit: Exigences de modularit, complexit ... Portabilit. 4. Informations additionnelles 4.1 Index 4.2 Annexes Selon les besoins.

Analyse et modlisation - livrables


Sommaire des tapes et des livrables de modlisation oriente objet selon [LEV98] avec adaptations la mthode [UML1.1]. Les documents livrables dans la section 3 du dossier des spcifications des exigences (IEEE 830) sont indiqus par un astrisque (*).

1. Le modle environnemental (ch. 7)


Dfinition des termes (p.177) 1.1 Grille d'extraction des acteurs et vnements associs (fig. 7.2, p. 185) Acteurs (rle) Evnements associs (verbe et objet)

1.2 Modle environnemental (graphique, fig. 7.1, p. 179) * Diagramme des cas d'utilisation
Use case diagram [UML1.1-6]

1.3 Les scnarios de transaction


Expanded use cases [Larman, ch. 6, 7]

* 1.3.1 Liste des transactions (exemple fig. 7.5, p. 190) * 1.3.2 Description des scnarios de transaction (p. 181)

Titre du scnario Description sommaire Acteur primaire Acteur secondaire Rgle d'initiation Description du processus Rgles de terminaison Exception Extension Complmentaire

Rappel des tapes (p. 196) * 1.4 Ecrans d'interface utilisateur (fig. 7.7, p. 193; annexe I, p. 199)

2. Le modle structural (ch. 8)


Dfinition des termes (p. 215) 2.1 Grille d'extraction des objets (fig. 8.14, p. 216)) Objets (identit) Etats Oprations

* 2.2 Le rpertoire des classes d'objets (fig. 8.16, p. 220)

Identit Dfinition Attributs Mthode Super classe Association et Objet associ

2.3 Grille des associations entre objets (fig. 8.17, p. 223) Classe Association (verbe) Classe

* 2.4 Le modle structural global (graphique) Diagramme de classes et d'objets


Static structure diagrams [UML1.1-5]

* 2.5 Le modle de chaque scnario (graphique) Rgles de prsentation des modles (p. 230)

Rappel des tapes de modlisation (p. 232)

3. Le modle dynamique de comportement (ch. 9)


Dfinition des termes (p. 246)
3.1 Trae des vnements de chaque scnario (fig. 9.1, p. 247) OMIS

3.2 Diagrammes des interactions Acteurs-Objets (fig. 9.2, p. 249) * Diagrammes de squence ou de collaboration
Sequence diagrams [UML1.1-7], [Larman, ch. 13] Collaboration diagrams [UML1.1-8]

3.3 Diagrammes de transition d'tats (fig. 9.3, p. 250) * Diagrammes de transition d'tats ou d'activit
Statechart diagrams [UML1.1-9] Activity diagrams [UML1.1-10]

Rappel des tapes (p. 271) 4. Le modle fonctionnel (ch. 10)


4.1 Arbre de dcomposition fonctionnelle (fig. 10.1, p. 276) - OMIS 4.2 Notation, le DFD (figs. 10.2-4, p. 279-280) - OMIS

* 4.3 Description des mthodes (p. 283)

Nom (paramtres) Classe propritaire Description Lit (objets et attributs) Modifie (attributs) Message autre objet Pr-conditions Post-conditions
Contracts [Larman, ch. 14]

4.4 Diagramme des dpendances fonctionnelles (fig. 10.12, p. 289) - OMIS

Rappel des tapes (p. 294) 5. Rvision et validation du dossier (ch. 12, p.315)

Spcification des exigences non-fonctionnelles

Les produits logiciels doivent rpondre des exigences diffrentes dun produit lautre. On peut diviser les spcifications en deux catgories majeures: les spcifications fonctionnelles qui prcisent les traitements effectuer, le comportement exig; les spcifications autres que le comportement, dites non-fonctionnelles. Les fonctionnalits seules ne constituent pas lintgralit des besoins de lutilisateur. Selon la norme IEEE 830-1993, les principales exigences non-fonctionnelles sont Fiabilit Disponibilit Scurit: Protection contre intrusions, modification, destruction ... Maintenabilit: Exigences de modularit, complexit ... Portabilit. Il nest pas ncssaire de toujours inclure toutes les spcifications non-fonctionnelles, mais seulement celles dont on a besoin pour une application particulire (e.g. maintenabilit et portabilit pour un produit longue vie). Ne pas oublier que toute exigence, mme nonfonctionnelle, doit tre spcifie de manire pouvoir la vrifier plus tard. 1. La norme ISO 9126 dfinit six caractristiques de qualit des produits logiciels, dont la capacit fonctionnelle (functionality). On peut dfinir chaque caractristique en termes de plusieurs attributs. Chaque attribut doit avoir une dfinition prcise et possder des indicateurs mesurables (qui ne sont pas dfinis par cette norme). Les cinq caractristiques non-fonctionnelles mentionnes dans la norme ISO 9126 sont: Fiabilit Facilit dutilisation Rendement Maintenabilit Portabilit 2. Fiabilit (Reliability) Abilit du logiciel maintenir son niveau de performance sous des conditions spcifies pour une dure spcifie. Attributs:

Maturit: Frquence des dfaillances (MTF), Densit des dfaults Stabilit du produit, Tolrence aux dfaillances, Densit et couverture des tests Facilit de recouvrement en cas de dfaillance 3. Facilit dutilisation (Usability) Leffort ncessaire pour lutilisation du logiciel par un ensemble dutilisateurs spcifis ou implicites. Ce nest pas une dfinition base sur lergonomie seulement. Attributs: Facilit de comprhension (Understandability) Facilit dopration Facilit dapprentissage 4. Rendement (Efficiency) Relation entre le niveau de performance du logiciel et les ressources utilises, sous des conditions donnes. Attributs: Par rapport au temps: Turnaround, Rponse, UCT, E/S, Attente, Rseau Par rapport aux ressources (taille et utilisation): Mmoire principale, Mmoire virtuelle, Workingset, Fichiers, Rseau 5. Facilit dentretien (Maintenability) Leffort ncessaire pour modifier le logiciel (corrections, amliorations, adaptation). Attributs: Par rapport lanalyse des dfaillances Par rapport aux modifications Stabilit (risque deffets imprvus aprs modification) Facilit de validation (testability)

6. Portabilit (Portability)

Facilit de transfrer le logiciel dun environnement donn un autre. Attributs: Facilit dadaptation diffrents environnements Facilit dinstallation Conformance aux normes, degr douverture Facilit de substitution (replaceability) pour un autre logiciel similaire.