<Nom du projet>

Vision

 

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 sera automatiquement passé en style normal (style=Body Text).]

 


Historique des révisions

Date

Version

Description

Auteur

<jj/mmm/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.       Positionnement          

2.1     Opportunité métier      

2.1.1     Position actuelle 

2.1.2     Justification au changement

2.2     Expression du problème      

2.3     Descriptif de positionnement du produit     

3.       Descriptions des parties prenantes et des utilisateurs  

3.1     Statistiques du marché     

3.2     Synthèse des parties prenantes     

3.3     Synthèse des utilisateurs     

3.4     Environnement utilisateur     

3.5     Profils des parties prenantes     

3.5.1     <Nom de la partie prenante>           

3.6     Profils des utilisateurs     

3.6.1     <Nom de l'utilisateur>           

3.7     Principaux besoins des utilisateurs ou des parties prenantes     

3.8     Alternatives et concurrence     

3.8.1     <Un concurrent>           

3.8.2     <Un autre concurrent>           

3.9      Alternatives au développement envisagées

4.       Présentation du produit      

4.1     Mise en perspective du produit     

4.2     Synthèse des capacités     

4.3     Hypothèses et dépendances     

4.4     Coût et tarification     

4.5     Licences et installation     

5.       Fonctions du produit         

5.1     Fonctions     

5.1.1       <Une fonction>

5.1.2       <Une autre fonction>

5.2     Scénarios d'exploitation

5.3       Assistance    

6.       Contraintes         

7.       Fourchettes de qualité

8.       Priorités

9.       Autres exigences produit

9.1     Standards applicables     

9.2     Exigences système     

9.3     Exigences de performances     

9.4     Exigences liées à l'environnement   

9.5       Exigences physiques  

10.            Exigences de documentation               

10.1     Manuel utilisateur     

10.2     Aide en ligne     

10.3     Guides d'installation, configuration et fichier Read Me     

10.4     Libellés et emballage     

A.                 Attributs de fonction               

   


Vision

1.                   Introduction

[Ce document a pour objectif de réunir, analyser et définir les besoins et fonctions de haut niveau du <<Nom du système>>. Il met l'accent sur les capacités requises par les parties prenantes et les utilisateurs cible, et sur la raison de ces besoins. La description de la manière dont <<Nom du système>> y répond est détaillée dans le cas d'utilisation et les spécifications supplémentaires. Remarque : ce canevas de Vision tente de couvrir tous les types de développements, depuis les produits prêts à l'emploi développés en vue de répondre à un besoin soupçonné du marché, jusqu'aux systèmes personnalisés développés sous contrat en vue de répondre aux exigences d'un client spécifique. Par conséquent, les mots "produit" et "système" peuvent être utilisés sans différenciation particulière pour désigner "ce qui est à développer". En principe, la personnalisation du document devrait restreindre ce canevas à une application spécifique.]

 [L'introduction de la Vision présente une vue d'ensemble de tout le document. Elle doit contenir l'objectif, la portée, les définitions, les acronymes, les abréviations, les références et la présentation de la Vision.]

1.1               Objectif

[Spécifiez l'objectif de ce document.]

1.2               Portée

[Brève description de la portée de la Vision : indication du ou des projets associés 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 Vision. Ces informations peuvent être fournies en se référant au glossaire du projet.]

1.4               Références

[Cette sous-section contient une liste complète de tous les documents référencés ailleurs dans la Vision. 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. Spécifiez les sources à partir desquelles les références peuvent être obtenues. 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 Vision et explique l'organisation de ce document.]

2.                  Positionnement

2.1               Opportunité métier

[Décrivez brièvement l'opportunité métier de ce projet.]

2.1.1     Position actuelle

[Dans cette sous-section, décrivez le contexte, l'objectif et la portée des circonstances du métier ou du système existant, y compris, le cas échéant, les règles appliquées, les capacités du système actuel, les parties prenantes impliquées et les problèmes de prise en charge.]

2.1.2     Justification au changement

[Dans cette sous-section, décrivez les nouvelles circonstances ou les nouveaux besoins apparus, du point de vue de l'exploitation ou du métier, qui motivent la réalisation d'un changement. Identifiez brièvement les changements proposés et rejetés, ainsi que leurs justifications. Si des études ont été menées sur la nécessité d'un changement, elles peuvent être référencées ici.]

2.2               Expression du problème

[Rédigez une phrase qui résume le problème que ce projet est en voie de résoudre. Vous pouvez utiliser le format suivant : ]

Le problème

[décrivez ce problème]

concerne

[énumérez les parties prenantes concernées par le problème]

et a pour impact

[décrivez l'impact de ce problème].

Pour être satisfaisante, une solution doit apporter

[répertoriez les principaux avantages d'une solution satisfaisante].

2.3               Descriptif de positionnement du produit

[Rédigez une phrase qui résume, le plus généralement possible, la position unique que le produit compte occuper sur le marché. Vous pouvez utiliser le format suivant : ]

Pour

[client cible],

qui

[expression du besoin ou de l'opportunité],

(nom du produit)

 est un [catégorie du produit]

qui/que

[expression de l'avantage principal (ce qui pousse à acheter le produit)].

Contrairement à

[principal produit concurrent],

notre produit

[expression de la principale différenciation].

[Le descriptif de positionnement d'un système ou d'un produit communique les objectifs du système et l'importance du projet à tout le personnel concerné.]

3.                  Descriptions des parties prenantes et des utilisateurs

[Afin de fournir efficacement des produits et services qui répondent aux besoins réels des parties prenantes et des utilisateurs, il est nécessaire d'impliquer toutes les parties prenantes dans le processus de modélisation des exigences. Vous devez également identifier les utilisateurs du système et vous assurer que la communauté des parties prenantes les représente de manière adéquate. Cette section présente un profil des parties prenantes et des utilisateurs impliqués dans le projet, ainsi que les problèmes clés qui doivent, selon eux, être traités par la solution proposée. Elle ne décrit pas leurs demandes ou exigences spécifiques, qui sont enregistrées dans un artefact à part, relatif aux demandes des parties prenantes. En revanche, elle explique le contexte de ces exigences et les raisons de leur existence.]

3.1               Statistiques du marché

[Résumez les principales statistiques du marché qui motivent vos décisions produit. Décrivez et positionnez les segments de marché cible. Estimez la taille et la croissance du marché en fonction du nombre d'utilisateurs potentiels ou du montant dépensé par vos clients pour tenter de combler les besoins auxquels votre produit ou votre amélioration devrait répondre. Examinez les principales tendances et technologies du secteur. Répondez à ces questions stratégiques :

?          Quelle est la réputation de votre organisation sur ces marchés ?

?        Quelle devrait être cette réputation ?

?          Comment ce produit ou ce service vous permet-il d'atteindre vos objectifs ?]

3.2               Synthèse des parties prenantes

[Un certain nombre de parties prenantes sont concernées par le développement, mais toutes ne sont pas des utilisateurs. Présentez une liste récapitulative de ces dernières. (Les utilisateurs sont récapitulés dans la section 3.3.)]

Nom

Description

Responsabilités

[Nommez le type de partie prenante.]

[Décrivez brièvement la partie prenante.]

[Résumez les principales responsabilités de la partie prenante concernant le système en développement (son intérêt en tant que partie prenante). Par exemple, cette partie prenante :

- vérifie que le système sera maintenable

- vérifie qu'il existera une demande sur le marché correspondant aux fonctions du produit

- suit la progression du projet

- approuve le financement]

3.3               Synthèse des utilisateurs

[Présentez une liste récapitulative de tous les utilisateurs identifiés.]

Nom

Description

Responsabilités

Partie prenante

[Nommez le type d'utilisateur.]

[Décrivez brièvement ce qu'il représente pour le système.]

[Répertoriez les principales responsabilités de l'utilisateur concernant le système en développement ; par exemple :

- enregistre les détails

- produit des rapports

- coordonne le travail]

[Si l'utilisateur n'est pas représenté directement, identifiez la partie prenante chargée de représenter ses intérêts.]

 

3.4               Environnement utilisateur

[Détaillez l'environnement de travail de l'utilisateur cible. Quelques suggestions :

Vous pouvez inclure ici des extraits du modèle métier pour donner un aperçu de la tâche, des travailleurs métiers impliqués, etc.]

3.5               Profils des parties prenantes 

[Décrivez ici chaque partie prenante dans le système en remplissant le tableau suivant. Souvenez-vous que les parties prenantes peuvent être de types très divers : utilisateurs, services, développeurs techniques, etc. Un profil exhaustif couvre les rubriques suivantes pour chacun de ces types.]

3.5.1          <Nom de la partie prenante>

Représentant

[Qui est le représentant de la partie prenante pour ce projet ? (Facultatif, si déjà documenté ailleurs.)  Vous devez citer des noms.]

Description

[Brève description du type de partie prenante.]

Type

[Qualifiez la spécialisation de la partie prenante, ses connaissances techniques, ainsi que son degré d'expertise : gourou, chevronné, expert, utilisateur occasionnel, etc.]

Responsabilités

[Répertoriez les principales responsabilités de la partie prenante concernant le système en développement (son intérêt en tant que partie prenante).]

Critères de réussite

[Comment la partie prenante définit-elle la notion de réussite ?

Comment est-elle récompensée ?]

Implication

[Quelle est l'implication de la partie prenante dans le projet ? Référez-vous le plus possible aux rôles Rational Unified Process : réviseur de recueil des exigences, etc.]

Livrables

[La partie prenante requiert-elle d'autres livrables ? Il peut s'agit de livrables de projet ou de sorties du système en cours de développement.]

Commentaires / Problèmes

[Cette partie est consacrée aux problèmes qui affectent la réussite d'un projet et à d'autres informations pertinentes.]

 

3.6               Profils des utilisateurs 

[Décrivez ici chaque utilisateur du système en remplissant le tableau suivant. Souvenez-vous que les types d'utilisateur peuvent être très variés, allant du gourou au néophyte. Par exemple, un gourou peut avoir besoin d'un outil flexible, sophistiqué et multiplateforme, tandis qu'un néophyte pourra avoir besoin d'un outil simple d'utilisation et convivial. Un profil exhaustif couvre les rubriques suivantes pour chaque type d'utilisateur.]

3.6.1          <Nom de l'utilisateur>

Représentant

[Qui est le représentant de l'utilisateur pour ce projet ? (Facultatif, si déjà documenté ailleurs.) Cette section se rapporte souvent à la partie prenante qui représente l'ensemble d'utilisateurs ; par exemple, Partie prenante : PartiePrenante1.]

Description

[Brève description de chaque type d'utilisateur.]

Type

[Qualifiez la spécialisation de la partie prenante, ses connaissances techniques, ainsi que son degré d'expertise : gourou, utilisateur occasionnel, etc.]

Responsabilités

[Répertoriez les principales responsabilités de l'utilisateur concernant le système en développement : enregistre les détails, produit des rapports, coordonne le travail, etc.]

Critères de réussite

[Comment l'utilisateur définit-il la notion de réussite ?

Comment est-il récompensé ?]

Implication

[Quelle est l'implication de l'utilisateur dans le projet ? Référez-vous le plus possible aux rôles Rational Unified Process : réviseur de recueil des exigences, etc.]

Livrables

[L'utilisateur produit-il des livrables ? Si oui, pour qui ?]

Commentaires / Problèmes

[Cette partie est consacrée aux problèmes qui affectent la réussite d'un projet et à d'autres informations pertinentes. Citez par exemple des tendances qui facilitent ou freinent le travail de l'utilisateur.]

 

3.7               Principaux besoins des utilisateurs ou des parties prenantes

[Répertoriez les problèmes clés pour lesquels il existe des solutions, tels qu'ils sont perçus par les parties prenantes. Répondez aux questions suivantes pour chaque problème :

?          Quelles sont les raisons de ce problème ?

?          Quelles sont les solutions apportées aujourd'hui ?

?          Quelles sont les solutions souhaitées par la partie prenante ou par l'utilisateur ?]

[Il est essentiel de comprendre l'importance relative que la partie prenante ou l'utilisateur accorde à la résolution de chaque problème. Les techniques de classement par importance et de vote cumulatif permettent de distinguer les problèmes qui doivent absolument être résolus de ceux que les utilisateurs ou parties prenantes aimeraient simplement voir abordés.

Remplissez le tableau suivant. Si vous utilisez Rational RequisitePro pour enregistrer les besoins, ce tableau peut être remplacé par un extrait ou un rapport de cet outil.]

Besoin

Priorité

Préoccupations

Solution actuelle

Solutions proposées

Messages de diffusion

 

 

 

 

 

3.8               Alternatives et concurrence

[Identifiez les alternatives perçues comme disponibles par la partie prenante. Une alternative peut consister à acheter le produit d'un concurrent, à construire une solution maison ou tout simplement à maintenir le statu quo. Répertoriez tous les choix concurrents connus, existants ou potentiels. Indiquez les principaux points forts et points faibles de chaque concurrent, tels qu'ils sont perçus par la partie prenante ou par l'utilisateur.]

3.8.1          <Un concurrent>

3.8.2          <Un autre concurrent>

3.9       Alternatives au développement envisagées

[Dans cette sous-section, décrivez toutes les alternatives au produit proposé qui ont été envisagées, ainsi que toutes les études menées sur les conséquences éventuelles de ces choix.]

4.                  Présentation du produit

[Cette section offre une vue d'ensemble des capacités du produit, des interfaces vers d'autres systèmes et des configurations système.] 

4.1               Mise en perspective du produit

[Cette sous-section de la Vision place le produit en perspective par rapport à d'autres produits associés et à l'environnement utilisateur. Si ce produit est indépendant et entièrement autonome, spécifiez-le ici. S'il s'agit d'un composant d'un système plus vaste, cette sous-section explique la manière dont ces systèmes interagissent et identifie les interfaces pertinentes entre eux. Pour afficher en toute simplicité les principaux composants du système plus vaste, les interconnexions et les interfaces externes, vous pouvez notamment utiliser un schéma de principe. 

Identifiez les impacts de l'exploitation, de l'organisation et du développement sur les parties prenantes et sur d'autres systèmes.]

4.2               Synthèse des capacités

[Résumez les principaux avantages et fonctions offerts par le produit. Par exemple, la Vision d'un système d'assistance client peut utiliser cette section pour aborder la documentation du problème, le routage et la génération de rapport de statut, sans détailler ce que requiert chacune de ces fonctions.

Organisez les fonctions de manière à ce que la liste soit compréhensible pour le client ou pour tout autre nouveau lecteur. Un simple tableau répertoriant les principaux avantages du produit et les fonctions qui les prennent en charge peut suffire. Par exemple :]

Tableau 4-1   Système d'assistance client

Avantage pour le client

Fonctions associées

Le nouveau personnel d'assistance est rapidement opérationnel.

Une base de connaissances soutient le personnel d'assistance en identifiant rapidement les réparations et solutions palliatives connues.

Les clients sont plus satisfaits, car aucun dossier n'est perdu ou abandonné.

Les problèmes sont traités de façon unique, classés et suivis tout au long du processus de résolution. Une notification automatique est déclenchée pour chaque problème devenu ancien et non encore résolu.

La direction peut identifier les zones de problème et évaluer la charge de travail du personnel.

Les rapports de tendance et de répartition permettent une revue de haut niveau du statut du problème.

Des équipes d'assistance réparties peuvent collaborer pour résoudre les problèmes.

Un serveur de réplication permet aux divers services de l'entreprise de partager les informations en cours de la base de données.

Les clients peuvent résoudre seuls leurs problèmes, ce qui diminue les coûts d'assistance et améliore le temps de réponse.

Une base de connaissances peut être mise à disposition sur Internet. Elle comprend des fonctions de recherche hypertextuelle et un moteur de requête graphique.

4.3               Hypothèses et dépendances

[Répertoriez chaque facteur qui affecte les fonctions citées dans la Vision. Répertoriez également les hypothèses qui altéreront la Vision si elles sont modifiées. Par exemple, la Vision est construite dans le contexte d'une plus grande entreprise. Un changement apporté dans ce contexte peut avoir des répercussions sur la Vision. Les facteurs de changement peuvent être d'ordre économique, politique, juridique ou écologique. La Vision peut également être dépendante de la disponibilité d'un équipement, d'un logiciel ou d'autres composants système, ou de l'existence de compétences ou spécialisations particulières.]

4.4               Coût et tarification

[Pour les produits vendus à des clients externes et pour de nombreux systèmes construits en interne, les problèmes de coût et de tarification peuvent affecter directement la définition et l'implémentation du système. Consignez dans cette section toutes les contraintes de coût et de tarification pertinentes. Par exemple, les contraintes relatives aux coûts de distribution (nombre de disquettes, nombre de CD-ROM, matriçage de CD) ou à d'autres coûts de vente de marchandises (manuels, emballage), peuvent être, selon la nature du système, essentielles ou inutiles à la réussite du projet.]

4.5               Licences et installation

[Les problèmes de licences et d'installation peuvent eux aussi affecter directement l'effort de développement. Par exemple, la nécessité de prendre en charge les contrôles des accès, la sérialisation, la protection par mot de passe ou la licence réseau créera pour le système des exigences supplémentaires qui devront être prises en compte dans l'effort de développement.

Les exigences d'installation peuvent également affecter la construction du logiciel ou entraîner la nécessité de construire un logiciel d'installation séparé. De plus, les systèmes physiques peuvent imposer des exigences d'installation particulières, s'ils doivent par exemple respecter des contraintes spécifiques de sécurité ou de survivabilité.]

5.                  Fonctions du produit

[Répertoriez et décrivez brièvement les fonctions du produit. Ce sont les capacités générales du système qui permettent d'offrir certains avantages aux utilisateurs. Pour chaque fonction, décrivez également les caractéristiques de performances associées : indiquez le degré de "bonne" réalisation à atteindre, ainsi que quelques dimensions, par exemple pour le temps : le temps de réponse, le taux de transactions. Le terme "fonction" ne porte pas de signification particulière. Vous pouvez préférer les termes "fonctionnalité" ou "capacité". Tous ces termes décrivent ce que doit faire le produit ou le système. Chaque fonction est un service qui est demandé par des éléments extérieurs et qui requiert généralement une série d'entrées pour produire le résultat escompté. Par exemple, un système de suivi des problèmes peut posséder une fonction de génération de rapports de tendance. A mesure que le modèle de cas d'utilisation prend forme, mettez à jour cette description pour refléter les cas d'utilisation.

La Vision étant revue par un éventail de membres du personnel impliqués, elle doit être assez générale pour être comprise de tout le monde. Cependant, elle doit également être assez détaillée pour fournir à l'équipe les informations nécessaires à la création d'un modèle de cas d'utilisation.

Afin de gérer la complexité de manière efficace, pour tout nouveau système ou nouvel incrément de système, nous recommandons d'élever les capacités au niveau le plus abstrait, de façon à énumérer entre 25 et 99 fonctions. Ces fonctions constituent la base fondamentale de la définition du produit et de la gestion de la portée et du projet. Chaque fonction sera développée dans le modèle de cas d'utilisation, ou exprimée en détail dans un langage naturel si le projet choisit par exemple de ne pas produire de cas d'utilisation.

Tout au long de cette section, chaque fonction pourra être perçue par les utilisateurs et opérateurs extérieurs ou par d'autres systèmes externes. Ces fonctions doivent comprendre une description de la fonctionnalité et de tout problème de convivialité pertinent à aborder. Appliquez les instructions suivantes :

?          Ne concevez pas. Maintenez les descriptions des fonctions à un niveau général. Concentrez-vous sur les capacités requises et les raisons (et non les modalités) de leur implémentation.

?          Si vous utilisez la boîte à outils Rational RequisitePro, toutes les fonctions doivent être sélectionnées en tant qu'exigences de type pour une référenciation et un suivi plus faciles.]

5.1               Fonctions

5.1.1     <Une fonction>

5.1.2     <Une autre fonction>

5.2               Scénarios d'exploitation

[Décrivez quelques utilisations du produit ou du système qui illustrent certaines interactions importantes ou intéressantes entre le système et ses utilisateurs, son environnement et/ou d'autres systèmes.]

5.3               Assistance

[Dans cette sous-section, décrivez la manière dont l'assistance doit en principe être fournie, en incluant l'organisation, les équipements, les cycles de maintenance et les accords avec le client.]

6.                  Contraintes

[Indiquez toutes les contraintes de conception, les contraintes externes ou d'autres dépendances.]

7.                  Fourchettes de qualité

[Définissez des fourchettes de qualité pour les performances, la robustesse, la tolérance aux pannes, la convivialité et d'autres caractéristiques semblables qui ne sont pas enregistrées dans la section "Fonctions".]

8.                  Priorités

[Définissez le degré de priorité des différentes fonctions du système.]

9.                  Autres exigences produit

[A un niveau général, répertoriez les standards applicables, les exigences de plateforme et de matériel, de performances, et les exigences liées à l'environnement.]

9.1               Standards applicables

[Répertoriez tous les standards que le produit doit respecter. Il peut s'agir de normes légales et réglementaires (FDA, UCC), de normes de communication (TCP/IP, ISDN), de compatibilité avec une plateforme (Windows, UNIX, etc.), de qualité et de sécurité (UL, ISO, CMM).]

9.2               Exigences système

[Pour le développement d'un système logiciel, définissez toutes les exigences système nécessaires à la prise en charge de l'application. Elles peuvent concerner les systèmes d'exploitation ou plateformes réseau hôtes, les configurations, la mémoire, les périphériques et les logiciels compagnons.]

9.3               Exigences de performances

[Utilisez cette section pour détailler les exigences de performances. Les problèmes de performances peuvent concerner notamment les facteurs de charge utilisateur, la capacité de communication ou de bande passante, le rendement, l'exactitude, ainsi que la fiabilité ou les temps de réponse observés dans un éventail de conditions de charge différentes.]

9.4               Exigences liées à l'environnement

[Détaillez les exigences liées à l'environnement selon les besoins. Pour les systèmes physiques, elles peuvent concerner la température, les chocs, l'humidité, les rayonnements, etc. Pour les systèmes logiciels, elles peuvent concerner les conditions d'utilisation, l'environnement utilisateur, la disponibilité des ressources, les problèmes de maintenance, le traitement d'erreurs et la reprise sur incident.]

9.5        Exigences physiques

[S'il existe des exigences physiques, telles que des limites de poids, de masse ou de taille, décrivez-les dans cette sous-section.]

10.             Exigences de documentation

[Cette section décrit la documentation qui doit être développée pour assurer la réussite du déploiement du système.]

10.1            Manuel utilisateur

[Décrivez l'objectif et le contenu du manuel utilisateur. Discutez de la longueur souhaitée, du niveau de détail, de la nécessité d'un index, du glossaire, du choix de privilégier les manuels de référence ou les tutoriels, etc. Les contraintes de formatage et d'impression doivent également être identifiées.]

10.2            Aide en ligne

[De nombreux systèmes offrent une aide en ligne pour assister l'utilisateur. La nature de ces systèmes est inhabituelle, car ils combinent des aspects de programmation (tels que les liens hypertextes) et des aspects de rédaction technique (tels que l'organisation et la présentation). Pour beaucoup, le développement d'un système d'aide en ligne est considéré comme un projet dans le projet, qui bénéficie de véritables gestion de portée et activité de planification.]

10.3            Guides d'installation, configuration et fichier Read Me

[Pour offrir une solution complète, il est important d'élaborer un document contenant des instructions d'installation et de configuration. De plus, un fichier Read Me est généralement inclus en tant que composant standard. Ce fichier peut contenir une section intitulée "Nouveautés dans cette édition" et aborder les problèmes de compatibilité avec les éditions précédentes. La plupart des utilisateurs apprécient également la définition de tous les bogues et solutions palliatives connus dans le fichier Read Me.]

10.4            Libellés et emballage

[Les systèmes modernes s'efforcent d'offrir une présentation cohérente, de l'emballage du produit aux menus d'installation, écrans d'accueil, systèmes d'aide, boîtes de dialogue, etc. Cette section définit les besoins et les types de libellés à incorporer. Sont notamment concernés les mentions de droit d'auteur, les notices de brevet, les logos d'entreprise, les icônes et autres éléments graphiques normalisés, etc.]

A.          Attributs de fonction

[Les fonctions possèdent des attributs qui peuvent permettre d'évaluer, de suivre, de classer par priorité et de gérer les éléments du produit proposés pour l'implémentation. Bien que tous les types et attributs d'exigence soient résumés dans le plan de gestion des exigences, vous souhaiterez sans doute répertorier et décrire brièvement les attributs des fonctions choisies. Les sous-sections suivantes correspondent à un ensemble d'attributs de fonction suggérés.]

A.1            Statut

[Défini après négociation et revu par l'équipe de gestion de projet. Suit la progression réalisée au cours de la définition de la version de référence du projet.

Proposée

[Désigne les fonctions en cours de discussion qui n'ont pas encore été revues ni acceptées par une "voie officielle", telle qu'un groupe de travail constitué de représentants provenant de l'équipe projet, de la gestion de produit et de la communauté d'utilisateurs et de clients.]

Approuvée

[Désigne les fonctions considérées comme utiles et faisables, qui ont été approuvées par une voie officielle pour l'implémentation. ]

Incorporée

[Désigne les fonctions incorporées dans la version de référence du produit à un certain moment.]

A.2            Avantage

[Défini par le service de commercialisation, le responsable de produit ou l'analyste métier. Toutes les exigences ne sont pas égales. Le classement des exigences en fonction de leur avantage relatif pour l'utilisateur permet d'ouvrir le dialogue avec les clients, les analystes et les membres de l'équipe de développement. Cet attribut est utilisé pour la gestion de la portée et la définition des priorités du développement.]

Critique

[Désigne les fonctions essentielles. Si leur implémentation échoue, le système ne répondra pas aux besoins du client. Une édition ne peut être livrée que si toutes les fonctions critiques sont implémentées.]

Importante

[Désigne les fonctions importantes pour l'efficacité et l'efficience du système dans la plupart des utilisations. Elles ne peuvent être facilement offertes par un autre moyen. L'absence d'une fonction importante pourrait affecter la satisfaction du client ou de l'utilisateur, voire le chiffre d'affaires, mais la livraison de l'édition ne s'en trouve pas retardée.]

Utile

[Désigne les fonctions qui prennent en charge une utilisation moins courante et qui seront par conséquent moins souvent employées ou pour lesquelles il est possible de trouver des solutions palliatives raisonnablement efficaces. L'absence d'un tel élément dans l'édition ne devrait pas avoir de conséquence importante sur le chiffre d'affaires ou sur la satisfaction du client.]

 

A.3            Effort

[Défini par l'équipe de développement. Etant donné que certaines fonctions requièrent plus de temps et de ressources que les autres, l'estimation du nombre d'équipes, de personnes ou de semaines nécessaires, ou de toute autre mesure liée à un effort (telles que le nombre de lignes de code ou de points de fonction requis pour le logiciel) représente le meilleur moyen d'évaluer la complexité et de fixer des attentes sur ce qui peut ou non être accompli en un laps de temps donné. Cet attribut est utilisé pour la gestion de la portée et la définition des priorités du développement.]

A.4            Risque

[Défini par l'équipe de développement en fonction de la probabilité de réalisation d'événements indésirables, tels que des coûts supplémentaires, des retards ou même une annulation. Pour la plupart des responsables de projet, le classement des risques en trois catégories (élevé, moyen, faible) est suffisant, même s'il est possible d'ajouter des échelons plus précis. Vous pouvez également évaluer le risque indirectement, en mesurant l'incertitude (fourchette) qui accompagne l'estimation des délais par l'équipe projet.]

A.5            Stabilité

[Définie par l'analyste et l'équipe de développement en fonction de la probabilité de changement dans la fonction ou dans sa compréhension. Cet attribut permet de fixer les priorités du développement et de déterminer les éléments pour lesquels il conviendra de recueillir des informations supplémentaires.]

A.6            Edition cible

[Enregistre la version du produit dans laquelle la fonction doit apparaître pour la première fois. Cette zone peut être utilisée pour attribuer certaines fonctions d'une Vision à une édition de référence particulière. En l'associant à la zone "Statut", votre équipe peut proposer, enregistrer et débattre de diverses fonctions dans l'édition, sans nécessairement les développer par la suite. Seront implémentées uniquement les fonctions qui possèdent le statut "Incorporée", et dont l'édition cible est définie. Lors de la gestion de la portée, il est possible d'augmenter le numéro de version de l'édition cible attribuée, afin que la fonction reste consignée dans la Vision, tout en étant planifiée pour une édition ultérieure.]

A.7            Affectée à

[Dans de nombreux projets, les fonctions seront affectées à des "équipes fonction", responsables du recueil, de l'enregistrement et de l'amélioration des exigences supplémentaires ainsi que de l'implémentation. Cette simple liste permettra à chaque membre de l'équipe projet de mieux comprendre ses responsabilités.]

A.8            Motif

[Cette zone de texte est utilisée pour remonter aux origines de la fonction demandée. Les exigences doivent leur existence à des motifs spécifiques. Cette zone contient une explication ou une référence vers une explication. Elle peut par exemple indiquer un numéro de page ou de ligne d'une spécification d'exigence produit ou un moment précis (minute) sur la cassette vidéo d'une importante revue client.]