Spécifications des exigences d'un logiciel
(Adapté de la norme IEEE 830-1993)

Ce document suggère un ensemble d’éléments à préciser pour les exigences d'un système logiciel. Il débute par une Page de titre, la table des matières et une liste des illustrations.
1.	Introduction
	Vue d'ensemble de tout le document des exigences.
1.1 Objectifs
	Les objectifs de ce document et son public-cible.
1.2 Portée
	• Identifier le système logiciel par nom, 
• Expliquer brièvement ce qu'il doit faire et ne pas faire,
• Décrire le contexte de l'application dans lequel le produit s'intègre,
incluant les objectifs, les bénéfices et retombées du projet.
1.3 Définitions, acronymes et abréviations
1.4 Documents de références
	Lister tous les documents, normes, rapports, etc., pertinents en identifiant leur bibliographie. Ajouter aux annexes au besoin.
1.5 Aperçu du document
	Sommaire de ce qu’il contient et comment il est organisé.

2.	Description générale du logiciel
	Donner une vue d'ensemble du produit logiciel dont les détails seront spécifiés dans la section 3 du document.
2.1 Perspective du produit
	Décrire sa place dans le système, par rapport aux autres produits.
	Inclure les diagrammes appropriés
	Identifier toutes les interfaces entre le produit et son environnement
	- aux autres parties du système
	- aux utilisateurs (caractéristiques nécessaires)
	- aux composantes matérielles (ports, jeu d’instructions)
	- aux composantes logicielles (SGBD, systèmes d’exploitation, progiciels)
	- aux télécommunications (protocoles de réseaux locaux, TCP/IP ...)
	- contraintes de mémoire primaire et secondaire
	- aux opérateurs (fonctions de support, archivage)
	- adaptation du site d’installation.
2.2 Vue d'ensemble des fonctions du produit
	Sommaire des fonctions majeures du logiciel (à détailler en section 3)
	pour donner une vue d’ensemble au lecteur.
2.3 Description des utilisateurs
	Caractéristiques des usagers et des opérateurs (éducation, expertise).
2.4 Contraintes d'ordre général
	- Règlements des organismes gouvernementaux, syndicaux ...
	- Limitations du matériel (timing des signaux ...)
	- Interfaces à d’autres applications
	- Opérations en parallèle
	- Fonctions d’audit
	- Fonctions de contrôle
	- Exigences de langages de programmation
	- Protocoles de communication
	- Exigences de fiabilité
	- Aspects critiques de l’application
	- Considérations de sûreté et de sécurité
2.5 Hypothèses et dépendances
Prémisses de base qui affectent les exigences (par exemple, un système d’exploitation particulier, une version), l’ordonnancement des fonctionnalités, des règles d’affaires propres au domaine, etc..
2.6 Répartition des exigences
Identifier les exigences que l’on peut retarder pour des versions ultérieures du produit.

3.	Description détaillée
 	Lister toutes les exigences à un niveau suffisamment détaillé pour pouvoir procéder par la suite à la conception du produit et l’élaboration des tests. Au minimum, la description de chaque stimulus (entrée), de chaque réponse (sortie) et de tous les traitements (fonctions) effectués par le système doivent être décrits.

	Section la plus importante du document. Toutes les exigences doivent être identifiables et traçables. Plusieurs façons d’organiser cette section sont possibles (voir gabarits dans l’annexe A de la norme). Éléments à inclure:

3.1 Interfaces externes
	Le modèle environnemental et la description détaillée de toutes les fonctionnalités sur la base des scénarios d’utilisation, dessins d’écrans (à inclure dans le guide de l’utilisateur), formats de rapports. Aspects particuliers de l’ergonomie des interfaces attendus des utilisateurs.
	Un scénario d’utilisation doit préciser la nature globale des événements inclus dans une transaction et notamment: un titre, un sommaire, les acteurs, les règles d’initiation (pré-conditions), une description générale avec précision des règles internes, les règles de terminaison (post-conditions), les exceptions, les extensions et les scénarios complémentaires.
3.2 Spécifications fonctionnelles
	Les spécifications fonctionnelles définissent les actions fondamentales pour accepter les entrées, effectuer les traitements et générer les sorties.  Inclure:
	- Le modèle objet détaillé: modèles structural, évolutif, fonctionnel, accompagnés d’un répertoire des classes d’objets.
3.3 Exigences d’opérations, de communications et de performance
	Exigences quantitatives statiques et dynamiques. Par exemple:
- Nombre de terminaux à supporter
	- Nombre d’utilisateurs simultanés
	- Quantité et types d’information à traiter
	- Nombre de transactions à traiter par unité de temps sous conditions normales et en période de pointe.
3.4 Exigences logiques de bases de données
	- Types d’information utilisées par les différentes fonctions
	- Fréquence d’utilisation
	- Capacité d’accès
	- Entités et relations des données
	- Contraintes d’intégrité
	- Exigences de rétention des données
3.5 Contraintes de conception
	Imposées par les normes, contraintes de matériel ...
Conformité aux normes:
	Exigences dictées par les normes et règlements. Par exemple
	- Format des rapports
	- Nomenclature des données
	- Procédures de comptabilité
	- Exigences d’audit, traçabilité des traitements
3.6 Exigences non-fonctionnelles
	Caractéristiques du système logiciel, selon les besoins.
	• Fiabilité
	• Disponibilité
	• Sécurité
		Protection contre intrusions, modification, destruction ...
	• Entretien des logiciels
		Exigences de modularité, complexité ...
	• Portabilité
3.7 Organisation des exigences spécifiques
	Un modèle organisationnel optimal pour toutes les situations n’existe pas. Différentes façons d’organiser les exigences de la section 3 sont appropriées selon le type de système. Voir gabarits de l’annexe A de la norme IEEE.
	Organisations suggérées:

	• Selon le mode d’opération du système – Annexe A.I ou A.2
	Comportement selon mode apprentissage, normal, urgence ...

	• Selon les classes d’utilisateurs – Annexe A.3
	Clients, préposés, administrateurs, direction ...

	• Par objets – Annexe A.4
	Classes/objets avec attributs et services. Voir gabarit suggéré.

	• Par traits principaux (features) – Annexe A.5
	Un trait est un service qui exige une séquence d’entrées pour arriver au résultat. Dans un système téléphonique: appel local, interurbain, téléconférence,  ...

	• Par stimulus ou réponse – Annexe A.6
	Traitements organisés en termes de stimulus ou de réponse (e.g. tous les traitements pour produire les chèques de paie)

	• Par hiérarchie de fonctions – Annexe A.7
	Fonctions avec entrées, sorties, ou accès des données en commun (modèles structurés avec DFD, dictionnaire de données)
	
	• Commentaires additionnels – Annexe A.8 (Selon le mode combiné des classes d’utilisateurs et par traits principaux (features)

4. Informations complémentaires

4.1 Index

4.2 Annexes
	Selon les besoins