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
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