<Nom du projet>

Spécification des exigences système

 

 

 

Version <1.0>

 

 

[Remarque : le canevas suivant est à utiliser avec Rational Unified Process. Le texte figurant entre crochets et affiché en caractères italiques bleus (style=InfoBlue) est destiné à guider l'auteur et doit être supprimé avant la publication du document. Tout paragraphe saisi dans ce contexte est automatiquement passé en style normal (style=Body Text).]

 

Historique des révisions

Date

Version

Description

Auteur

<jj/mm/aa>

<x.x>

<détails>

<nom>

 

 

 

 

 

 

 

 

 

 

 

 

 

Sommaire

1. Introduction         

1.1 Objectif     

1.2 Portée     

1.3      Définitions, acronymes, et abréviations     

1.4 Références     

1.5 Présentation     

2. Description générale    

2.1 Synthèse de modèle de cas d'utilisation 

2.2 Hypothèses et dépendances

3. Exigences spécifiques

3.1 Capacités du système

3.1.1 Rapports de cas d'utilisation 

3.1.2 Autre fonctionnalité

3.2 Exigences non fonctionnelles

3.2.1 Convivialité 

3.2.2 Fiabilité 

3.2.3 Performances 

3.2.4 Capacité de prise en charge 

3.2.5 Contraintes de conception 

3.2.6 Autres considérations relatives à l'ingénierie système 

3.2.6.1 Exigences physiques 

3.2.6.2 Exigences liées à l'environnement 

3.2.6.3 Exigences d'assurance des autres produits 

3.2.6.4 Exigences humaines 

3.2.6.5 Exigences logistiques 

3.2.7 Exigences relatives à la documentation en ligne de l'utilisateur et au système d'aide 

3.2.8 Composants achetés 

3.2.9 Interfaces 

3.2.9.1 Interfaces utilisateur 

3.2.9.2 Interfaces matérielles 

3.2.9.3 Interfaces logicielles 

3.2.9.4 Interfaces de communication 

3.2.10 Exigences de licence 

3.2.11 Notices légales, droits d'auteurs et autres mentions 

3.2.12 Standards applicables

4. Informations de support    


Spécification des exigences système

1.                  Introduction

[L'introduction de la Spécification des exigences système (SysRS) présente une vue d'ensemble de tout le document. Elle contient l'objectif, la portée, les définitions, les acronymes, les abréviations, les références et la présentation de la SysRS.]

[Remarque : la SysRS enregistre les exigences logicielles du système complet ou d'une portion de celui-ci. Cette spécification enregistre toutes les exigences en un seul document, en intégrant les spécifications supplémentaires ou en insérant un matériel équivalent.]

1.1     Objectif

[Spécifiez l'objectif de cette spécification. La SysRS décrit en détail les capacités fonctionnelles et de comportement du système identifié, ainsi que d'autres facteurs nécessaires à une description complète et exhaustive des exigences système.]

1.2     Portée

[Brève description du système auquel s'applique la SysRS et de tout autre élément affecté ou influencé par ce document.]

1.3     Définitions, acronymes et abréviations

[Cette sous-section contient les définitions de tous les termes, acronymes et abréviations nécessaires à la bonne compréhension de la SysRS. Ces informations peuvent être fournies en se référant au Glossaire du projet.]

1.4     Références

[Cette sous-section doit présenter une liste complète de tous les documents référencés ailleurs dans la SysRS. Chaque document doit être identifié par un titre, un numéro de rapport (le cas échéant), une date et le nom de l'organisation à l'origine de sa publication. Précisez les sources à partir desquelles il est possible d'obtenir ces références. Ces informations peuvent être fournies en se référant à une annexe ou à un autre document.]

1.5     Présentation

[Cette sous-section décrit le contenu du reste de la SysRS et explique l'organisation de ce document.]

2.                  Description générale

[Cette section de la SysRS décrit les facteurs généraux qui affectent le système et ses exigences. Elle ne cite pas d'exigence spécifique (ces dernières sont détaillées dans la Section 3), mais elle présente leur contexte et facilite leur compréhension. Incluez des éléments, tels que :

Cette section peut contenir une référence vers l'artefact Vision, plutôt que de reproduire le matériel de ce document.]

2.1               Synthèse de modèle de cas d'utilisation

 [Si vous utilisez la modélisation de cas d'utilisation, cette section contient une vue d'ensemble du modèle de cas d'utilisation. Elle répertorie les noms et décrit brièvement tous les cas d'utilisation et les acteurs, ainsi que les diagrammes et relations applicables. Faites référence au Rapport de synthèse de modèle de cas d'utilisation, qui peut être utilisé comme pièce jointe.]

2.2               Hypothèses et dépendances

[Cette section décrit les principales faisabilités techniques, la disponibilité des composants ou des sous-systèmes, ou toute autre hypothèse du projet sur laquelle peut reposer la viabilité du système décrit dans cette SysRS.]

3.                  Exigences spécifiques

[Le niveau de détail de toutes les exigences contenues dans cette section permet de concevoir un système qui répond à ces exigences et de tester le respect de ces exigences.

Dans le contexte de la modélisation de cas d'utilisation, ces exigences sont enregistrées dans les cas d'utilisation et dans les spécifications supplémentaires applicables (en tant qu'artefact à part entière, ou conformément aux paragraphes de la section "3.2 Exigences non fonctionnelles" de ce document).]

3.1               Capacités du système

[Cette section décrit les capacités requises du système, exprimées sous forme de cas d'utilisation. Pour de nombreux systèmes, elle est susceptible de constituer la majeure partie du package SysRS et son organisation demande réflexion. Elle est généralement organisée par fonctionnalité, fonction ou groupe fonctionnel (issus de l'artefact Vision et caractérisant une "capacité" au sens large), mais d'autres méthodes d'organisation sont appropriées, comme un classement par utilisateur ou par rôle.]

3.1.1           Rapports de cas d'utilisation

[En modélisation de cas d'utilisation, les cas d'utilisation définissent la majeure partie des exigences fonctionnelles du système, ainsi que quelques exigences non fonctionnelles (liées aux performances). Pour chaque cas dans ce modèle, faites référence au rapport du cas d'utilisation ou joignez-le. Assurez-vous que chaque exigence est clairement indiquée. Le cas échéant, regroupez les cas d'utilisation par capacité (décomposée en fonctions si nécessaire) afin d'atteindre le bon niveau de description fonctionnelle et de comportement.]

3.1.2           Autre fonctionnalité

[Cette section décrit toute autre exigence fonctionnelle du système (non enregistrée sous forme de cas d'utilisation) exprimée dans un langage naturel.]

3.1.2.1     <Exigence fonctionnelle numéro un>

[Description de l'exigence.]

3.2                 Exigences non fonctionnelles

[Remarque : si l'artefact Spécifications supplémentaires a été produit, vous pouvez vous contenter de l'insérer ici. Il couvre en effet les mêmes rubriques.]

3.2.1          Convivialité

[Cette section inclut toutes les exigences qui touchent à la convivialité. Par exemple :

3.2.1.1     <Exigence de convivialité numéro un>

[Description de l'exigence.]

3.2.2           Fiabilité

[Spécifiez ici les exigences de fiabilité du système. Suggestions :

3.2.2.1     <Exigence de fiabilité numéro un>

[Description de l'exigence.]

3.2.3          Performances

[Présentez les grandes lignes des caractéristiques de performance du système dans cette section. Incluez les temps de réponse spécifiques. Référencez les cas d'utilisation associés par leur nom lorsque cela est possible. En général, associez toutes les capacités requises, qu'elles soient décrites sous forme de cas d'utilisation ou de texte, à des instructions de performance (qui décrivent la qualité de réalisation de la capacité ou de la fonction que doit offrir le système). Il est plus judicieux de conserver ces instructions à proximité de la capacité concernée (dans la partie "Exigences particulières" d'une description de cas d'utilisation, par exemple). Vous pouvez laisser ici les instructions qui doivent être testées, mais qui ne sont pas associées à une capacité spécifique. Les caractéristiques de performance comprennent :

3.2.3.1      <Exigence de performance numéro un>

[Description de l'exigence.]

3.2.4          Capacité de prise en charge

[Cette section indique toutes les exigences qui améliorent la capacité de prise en charge ou la maintenabilité du système en construction, notamment les standards de codification, les conventions d'attribution de nom, les bibliothèques de classes, ainsi que l'accès et les fonctionnalités de maintenance.]

3.2.4.1    <Exigence de capacité de prise en charge numéro un>

[Description de l'exigence.]

3.2.5          Contraintes de conception

[Cette section indique les contraintes de conception du système en construction. Ces contraintes représentent des décisions de conception imposées, auxquelles il faut se conformer. Elles concernent par exemple des langages logiciels, des exigences de processus logiciel, l'utilisation imposée d'outils de développement, des contraintes architecturales et de conception, des composants achetés, des bibliothèques de classe, etc.]

3.2.5.1     <Contrainte de conception numéro un >

[Description de l'exigence.]

3.2.6     Autres considérations relatives à l'ingénierie système

[L'ingénierie système peut impliquer d'autres types d'exigences : ]

3.2.6.1   Exigences physiques

[Par exemple : le poids, la taille, la puissance, etc.]

3.2.6.2  Exigences liées à l'environnement

[Par exemple : l'humidité, les contaminants, les exigences thermiques, électriques, mécaniques, etc.]

3.2.6.3  Exigences d'assurance des autres produits

3.2.6.3.x     <Catégorie>

[Par exemple : la sûreté, la sécurité, d'autres facteurs de qualité (comme la survivabilité du système).]

3.2.6.4  Exigences humaines

[Décrivez les exigences imposées au système par les personnes qui l'utilisent et assurent sa prise en charge. Ces exigences concernent par exemple les capacités d'apprentissage (l'équipement et le matériel à inclure pour l'apprentissage), les capacités de maintenance et les considérations ergonomiques non couvertes par les descriptions et les standards de l'interface.]

3.2.6.5  Exigences logistiques

[Décrivez les exigences imposées au système pour des raisons de logistique, comme la maintenance, la prise en charge, le transport, l'approvisionnement et l'équipement en systèmes existants.]

3.2.7          Exigences relatives à la documentation en ligne de l'utilisateur et au système d'aide

[Cette section décrit, le cas échéant, les exigences liées à la documentation en ligne de l'utilisateur, aux systèmes d'aide, à l'aide sur les notices, etc.]

3.2.8          Composants achetés

[Cette section décrit les composants achetés à utiliser avec le système, les restrictions de licence ou d'utilisation applicables, ainsi que les standards de compatibilité, d'interopérabilité ou d'interface.]

3.2.9          Interfaces

[Cette section décrit les interfaces qui doivent être prises en charge par le système. Elle doit contenir notamment la spécificité, les protocoles, les ports et les adresses logiques appropriés, afin que le système puisse être développé et vérifié conformément aux exigences d'interface. Décrivez également toutes les exigences à imposer à des interfaces internes au système. Le problème se pose, par exemple, lorsque la conception du système entraîne l'utilisation interne de composants matériels et logiciels existants.]

3.2.9.1     Interfaces utilisateur

[Décrivez les interfaces utilisateur qui doivent être implémentées par le système.]

3.2.9.2      Interfaces matérielles

[Cette section définit les interfaces matérielles qui doivent être prises en charge par le système, comme la structure logique, les adresses physiques, le comportement prévu, etc.]

3.2.9.3       Interfaces logicielles

[Cette section décrit les interfaces logicielles qui doivent être prises en charge par le système, en termes d'opérations et de signaux pris en charge, de protocoles et de caractéristiques de données.]

3.2.9.4       Interfaces de communication

[Décrivez toutes les interfaces de communication vers d'autres systèmes ou périphériques, telles que les réseaux LAN, etc.]

3.2.10        Exigences de licence

[Cette section définit toutes les exigences de respect de licence ou d'autres exigences de restriction d'utilisation que le système doit présenter.]

3.2.11        Notices légales, droits d'auteurs et autres mentions

[Cette section décrit toutes les questions relatives aux clauses de protection légale, aux garanties, aux mentions de droits d'auteur, à la notice de brevet, à la marque de mots, à la marque ou à la conformité des logos, qui concernent le système.]

3.2.12        Standards applicables

[Cette section fait référence à tous les standards applicables, ainsi qu'aux sections de ces standards qui s'appliquent spécifiquement au système considéré. Il peut s'agir par exemple de normes légales, de normes de qualité et de normes réglementaires, ou de normes du secteur concernant la convivialité, l'interopérabilité, l'internationalisation, la conformité au système d'exploitation, etc.]

4.                  Informations de support

[Les informations de support facilitent l'utilisation de la SysRS. Elles comprennent :

Elles peuvent contenir des informations sur les prototypes d'architecture et d'interface utilisateur. La SysRS doit indiquer de manière explicite si les annexes qu'elle comprend font partie des exigences.]