Tâche: Développer les spécifications supplémentaires |
|
 |
Cette tâche consiste à enregistrer les exigences ne s'appliquant pas à des cas d'utilisation particuliers. |
|
Objet
Enregistrer les exigences ne pouvant être facilement enregistrées dans les Cas
d'utilisation. |
Relations
Rôles | Principal:
| Complémentaire:
| Auxiliaire:
|
Entrées | Obligatoire:
| Facultatif:
| Externe:
|
Sorties |
|
Description principale
Tout au long des tâches relatives aux exigences qui sont basées sur les demandes regroupées des prenantes, les
exigences ne s'appliquant pas à des Cas
d'utilisation particuliers sont enregistrés dans les spécifications supplémentaires. Il est possible d'enregistrer
dans les spécifications supplémentaires les exigences aussi bien fonctionnelles que non fonctionnelles.
Pour plus d'informations pour répertorier et enregistrer les exigences, voir Concept : Exigences.
Pendant cette tâche, assurez-vous que toutes les exigences sont spécifiées de façon suffisamment détaillée pour être
transmises aux concepteurs, testeurs et rédacteurs.Si les exigences font l'objet d'un suivi ou de tout autre type de
gestion formelle, assurez-vous que chaque exigence est clairement identifiée et étiquetée.
|
Etapes
Enregistrement d'exigences fonctionnelles qui ne sont pas propres au cas d'utilisation
Les exigences fonctionnelles décrivent les comportements (fonctions ou services) du système qui prennent en charge les
objectifs, les tâches ou activités de l'utilisateur [MAL2001].
Alors que beaucoup d'exigences fonctionnelles vont être documentées dans Cas
d'utilisation, il existe des exigences fonctionnelles qui ne peuvent pas s'appliquer à des cas d'utilisation
spécifiques. Exemple : les exigences en matière de génération de rapport, de contrôle, d'impression, de sécurité,
de prise en charge/mise en application de licence, d'authentification etc. De telles exigences fonctionnelles
doivent être documentées dans la spécification supplémentaire.
S'il existe un nombre important d'exigences fonctionnelles sur l'ensemble du système, il est important de bien
réfléchir à l'organisation de cette section. Une méthode type serait de les organiser par fonction/ensemble de
fonctions mais il est possible d'avoir recours à d'autres méthodes d'organisation. Une organisation par
utilisateur ou par sous-système, par exemple, peut être appropriée.
Les exigences fonctionnelles représentent le "F" de "FURPS+. Pour plus d'informations sur les catégories
"FURPS+", voir Concept : Exigences.
|
Enregistrement des qualités du système
Les exigences non fonctionnelles comprennent à la fois les qualités et les contraintes [MAL2001]. Nous traitons ici des qualités. Les contraintes sont abordées
dans une autre étape.
Les qualités [du système] représentent les propriétés ou les caractéristiques du système qui intéressent les parties
prenantes et affectent donc le degré de satisfaction du système de ces dernières. [MAL2001]
Les qualités représentent le "URPS" de "FURPS+".Ces lettres représentent chacune de ces catégories d'exigences comme
suit :
-
Usability (convivialité) : Esthétique et cohérence de l'interface utilisateur.
-
Reliability (fiabilité) : Disponibilité (total du "temps utilisable" du système),
exactitude des calculs relatifs au système et capacité du système à supporter les échecs.
-
Performance (performance) : rendement, temps de réponse, temps de reprise, temps de démarrage et
temps d'arrêt.
-
Supportability (capacité de support) : testabilité, adaptabilité, maintenabilité, compatibilité,
configurabilité, installation, évolutivité et localisation.
Pour plus d'informations sur les catégories "FURPS+" ainsi que l'enregistrement des exigences non fonctionnelles, voir
Concept : Exigences.
En fonction du nombre de qualités à documenter pour le système, vous pouvez créer des sous-sections pour chaque type de
qualité.
Les sections suivantes fournissent quelques exemples de types d'informations que vous pouvez vouloir enregistrer pour
chaque qualité :
Convivialité
Lorsque vous décrivez les exigences en matière de convivialité, il se peut que vous vouliez spécifier :
-
Le temps d'apprentissage requis pour que les utilisateurs normaux et les utilisateurs chevronnés deviennent
productifs pour des opérations particulières
-
Le temps passé pour des tâches types
-
Les exigences pour répondre aux normes de convivialité courantes, comme par exemple les normes CUA d'IBM ou les
normes GUI de Microsoft
Fiabilité
Lorsque vous décrivez les exigences en matière de fiabilité, il se peut que vous vouliez spécifier :
-
La disponibilité – spécifie le pourcentage de temps disponible ( xx.xx%), les heures d'utilisation, l'accès à la
maintenance, les opérations relatives à un mode défectueux etc.
-
Mean Time Between Failures (MTBF, Moyenne des temps de bon fonctionnement) – généralement spécifié en heures mais
cela peut aussi se faire en jours, mois ou années.
-
Mean Time To Repair (MTTR, Temps moyen de reprise) – combien de temps le système peut-il rester sans fonctionner
après une panne ?
-
L'exactitude – spécifie la précision (résolution) et l'exactitude (selon quelque norme connue) requise dans les
sorties du système.
-
Le nombre maximum de bogues ou le taux d'incident – généralement exprimé en termes de bogues/KLOC (mille lignes de
code) ou bogues/point de fonction.
-
Bogues ou taux d'incident – répertoriés en termes de bogues mineurs, significatifs et critiques : les exigences
doivent définir ce que l'on entend par bogue "critique" ; par exemple une perte totale des données ou une
incapacité complète à utiliser certaines parties de la fonctionnalité du système.
Performance
Lorsque vous décrivez les exigences en matière de performance, il se peut que vous vouliez spécifier :
-
Le temps de réponse pour une transaction (moyen, maximum)
-
Le rendement (les transactions par seconde par exemple)
-
La capacité (le nombre de clients ou les transactions que le système peut accommoder par exemple)
-
Les modes de détérioration (quel est le mode opératoire acceptable lorsque le système a été détérioré)
-
L'utilisation de ressources : mémoire, disque, communications etc.
Lorsque vous documentez les exigences de performance, veillez à inclure les temps de réponse spécifiques. Référencez
les Cas d'utilisation associés par leur nom lorsque cela est possible.
Capacité de prise en charge
Lorsque vous décrivez les exigences en matière de capacité de prise en charge, il se peut que vous vouliez spécifier :
-
Normes de codage
-
Conventions de dénomination
-
Bibliothèques de classe
-
Accès à la maintenance
-
Fonctionnalités de maintenance
|
Enregistrement de contraintes
A cette étape, vous documentez toute contrainte de conception sur le système en construction. En terme général,
une contrainte est une restriction du degré de liberté dont nous disposons pour fournir des solutions [LEF2000]. Les contraintes de conception représentent des décisions prises
concernant la conception et auxquelles il faut se conformer.
Une contrainte représente le '+' de "FURPS+" et peut être répertoriée comme suit :
-
Contrainte de conception : spécifie ou limite les options possibles pour l'architecture et/ou la
conception d'un système. Demander, par exemple, qu'une base de données relationnelle soit utilisée
pour la persistance.
-
Contrainte d'implémentation : spécifie ou limite le codage ou la construction d'un système.
Exemple : normes obligatoires, processus, outils, langages d'implémentation, plateformes matérielles, systèmes
d'exploitation, composants tiers, bibliothèque de classe et limites de ressources (utilisation d'espace mémoire ou
d'espace disque).
-
Contrainte d'interface : spécifie un élément externe avec lequel le système doit interagir ou les
contraintes relatives aux formats ou à d'autres facteurs utilisées au sein d'une telle interaction. Exemple :
interface avec un système externe via des files d'attentes de messages.
-
Contrainte physique : spécifie une contrainte physique imposée pour le matériel utilisé pour
héberger le système - forme, taille ou poids par exemple.
En fonction du nombre de contraintes à documenter pour le système, vous pouvez créer des sous-sections pour chaque type
de contrainte. De plus :
-
Si les exigences comprennent l'achat de composants tiers, assurez-vous de documenter toute licence applicable ou
les restrictions d'usage ainsi que toute compatibilité/interopérabilité associée ou normes d'interface. Il est
recommandé de créer une section distincte par composant acheté.
-
Si les exigences comprennent des exigences d'interface spécifiques, il est recommandé de créer des sections
distinctes pour les différents types d'interfaces (ex : utilisateur, matériel, logiciel). Pour chaque interface,
assurez-vous d'inclure la spécificité adéquate, les protocoles, les ports, les adresses logiques etc. de manière à
ce que le logiciel puisse être développé et vérifié par rapport aux exigences d'interface. En particulier :
-
Pour les interfaces utilisateur, décrivez celles qui doivent être implémentées par le logiciel.
-
Pour les interfaces matérielles, insérez la structure logique, les adresses physiques, le comportement
escompté etc.
-
Pour les interfaces logicielles, insérez une description des interfaces dans d'autres composants du
système. Il peut s'agir de composants achetés, de composants d'autres applications réutilisés ou de
composants en cours de développement pour des sous-systèmes en dehors de la portée de ce système, mais avec
lesquels l'application logicielle doit interagir.
Pour plus d'informations sur les catégories "FURPS+" ainsi que l'enregistrement des contraintes, voir Concept : Exigences.
|
Enregistrement des exigences de conformité
Par conformité, nous entendons la conformité par rapport aux normes (y compris les normes de régulation, les normes de
codage ou les guides de style de l'interface utilisateur) ainsi que les clauses de protection légales, les garanties,
les mentions de droits d'auteurs, notice de brevet, marque de mot, marque et/ou conformité des logos.
Les exigences de conformité peuvent être réalisées en fonction des autres exigences (fonctionnelles, non fonctionnelles
et de contraintes).Dans ce cas, les détails relatifs à ces exigences doivent être documentés dans les sections
applicables de la spécification supplémentaire comme mentionné plus haut.Cependant, il est important de résumer les
normes et les règles auxquelles un système doit se conformer.Les exigences de conformité résultantes peuvent faire
référence aux exigences détaillées applicables, si nécessaire.
En fonction du nombre de d'exigences de conformité à documenter pour le système, vous pouvez créer des sous-sections
pour les différents types de conformité affectant le système.
Les sections suivantes fournissent quelques exemples de types d'informations que vous pouvez vouloir enregistrer pour
les différents types de conformité :
Exigences relatives aux licences
Définition de toute exigence de mise en application de licence ou d'autres exigences de restriction d'usage que le
logiciel doit exposer.
Mentions légales, de droits d'auteur et autres mentions
Description des questions de clauses de protection légales, de garanties, de mentions de droits d'auteur, de notice de
brevet, de marque de mot, de marque ou de conformité des logos nécessaire au logiciel.
Normes applicables
Description (par référence) de toute norme applicable et des sections spécifiques de telles normes qui s'appliquent au
système en cours de description. Cela peut comprendre par exemple les normes légales, de qualité, réglementaires et les
normes d'application pour la convivialité, l'interopérabilité, l'internationalisation, la conformité au système
d'exploitation, etc.
|
Enregistrement des exigences de documentation
A cette étape, vous décrivez les exigences relatives à la documentation, s'il y en a. Parmi les exigences de
documentation, on peut inclure les exigences pour une aide en ligne ainsi que la documentation pour l'utilisateur final
(ex : guides d'installation, guides d'utilisation, matériel d'apprentissage etc.).
Tout comme les exigences de conformité, les exigences de documentation conduisent à d'autres types d'exigences.Il
s'agit en particulier des exigences fonctionnelles (le système doit fournir un accès fonctionnel à l'aide en ligne) et
des exigences de convivialité (un accès à la demande aux informations d'utilisation du système garantit la convivialité
globale du système).
Tout comme les exigences de conformité, les exigences détaillées prenant en charge les exigences de documentation
doivent être documentées dans les sections applicables de la spécification supplémentaire comme mentionné plus haut,
mais il est aussi important de documenter et de résumer les exigences globales de documentation pour le système. Les
exigences résultantes peuvent faire référence aux exigences détaillées applicables.
En fonction du nombre d'exigences de documentation à documenter pour le système, vous pouvez créer des sous-sections
pour les différents types de documentations à fournir pour le système.
|
|
Propriétés
Plusieurs occurrences |  |
Commandé par les événements |  |
En cours |  |
Facultatif |  |
Planifié |  |
Réitérable |  |
Considérations clés
Les exigences qui couvrent les cas d'utilisation (éventuellement les exigences sur l'ensemble du système) dictent
souvent le développement de l'architecture du système. En fait, pour certains projets, de telles exigences peuvent être
beaucoup plus importantes que leurs contreparties qui se rattachent davantage au domaine (ou au cas d'utilisation) Par
exemple, si vous étiez en train de développer des systèmes médicaux de respiration artificielle, les exigences en
matière de fiabilité seraient alors critiques.
Malheureusement, comme il est souvent difficile de regrouper de telles exigences, celles-ci sont souvent oubliées. La
tâche qui nous concerne ici décrit l'approche globale pour regrouper ces exigences. Pour plus d'informations sur
une approche "systématique" pour regrouper les exigences à l'aide de questionnaires spécifiques, voir [EEL2004].
|
Plus d'informations
Guides d'utilisation de l'outil |
|
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.
|
|