<Nom du projet>

Spécification de cas d'utilisation : <Nom du cas d'utilisation>

 

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.          Nom du cas d'utilisation 

1.1      Brève description     

2.          Flux d'événements

2.1      Flux de base     

2.2      Flux alternatifs     

2.2.1       < Flux alternatif numéro un >      

2.2.2       < Flux alternatif numéro deux >      

3.          Exigences particulières

3.1      < Exigence particulière numéro un >     

4.          Préconditions    

4.1      < Précondition numéro un >     

5.          Postconditions    

5.1      < Postcondition numéro un >     

6.          Points d'extension

6.1      <Nom du point d'extension>     


Spécification de cas d'utilisation : <Nom du cas d'utilisation>

1.                  Nom du cas d'utilisation

[Le canevas suivant correspond à une spécification de cas d'utilisation, qui contient les propriétés textuelles du cas d'utilisation. Ce document est utilisé avec un outil de gestion des exigences, comme Rational RequisitePro, pour spécifier et indiquer les exigences dans les propriétés du cas d'utilisation.

Les diagrammes du cas d'utilisation peuvent être développés à l'aide d'un outil de modélisation visuelle, comme Rational Rose.  Un rapport de cas d'utilisation (avec toutes ses propriétés) peut être généré à l'aide de Rational SoDA. Pour plus d'informations, reportez-vous aux guides d'utilisation de l'outil livrés dans Rational Unified Process.]

1.1               Brève description

[Cette description communique brièvement l'objectif du cas d'utilisation. Un seul paragraphe suffit.]

2.                  Flux d'événements

2.1               Flux de base

[Ce cas d'utilisation commence dès que l'acteur agit. Un acteur initie toujours des cas d'utilisation. Le cas d'utilisation décrit ce que fait l'acteur et la réponse du système. Il doit être rédigé sous forme de dialogue entre l'acteur et le système.

Il décrit ce qui se passe à l'intérieur du système, mais n'explique pas de quelle façon, ni pour quelle raison. Si des informations sont échangées, soyez précis sur la description de leur contenu. Par exemple, l'indication selon laquelle l'acteur saisit des informations client est trop vague. Il est plus judicieux d'expliquer qu'il saisit le nom et l'adresse du client. Pour que la complexité du cas d'utilisation reste gérable, il est souvent utile de recourir à un glossaire terminologique. Vous souhaiterez probablement y définir des notions, telles que les informations clients, pour éviter de noyer vos cas d'utilisation dans la masse des détails.

Le texte du cas d'utilisation peut contenir des alternatives simples. Si la description d'une alternative tient en quelques lignes, insérez-la directement dans la section Flux d'événements. Au contraire, si le flux alternatif est plus complexe, décrivez-le dans une section à part. Par exemple, une sous-section Flux alternatif explique comment décrire des alternatives plus complexes.

Une image vaut parfois mieux qu'un long discours, même si rien ne remplace un texte clair et lisible. Si elles apportent de la clarté, n'hésitez pas à coller dans le cas d'utilisation des représentations graphiques d'interfaces utilisateur, de flux de processus ou d'autres illustrations. S'il est utile de recourir à un diagramme de flux pour présenter un processus de décision complexe, n'ayez aucun scrupule à le faire ! De la même manière, en ce qui concerne les comportements dépendant d'un état, un diagramme de transition d'état clarifie souvent mieux le comportement d'un système que quantité de pages de texte. Utilisez le support de présentation adapté à votre problème, mais veillez à ne pas employer de termes, notations ou figures susceptibles de ne pas être compris par vos lecteurs. Souvenez-vous que votre but est de clarifier la description, non de l'obscurcir.]

2.2               Flux alternatifs

2.2.1          <Flux alternatif numéro un >

[Les alternatives plus complexes sont décrites dans une section à part, référencée dans le paragraphe Flux de base de la section Flux d'événements. Considérez les sous-sections relatives aux Flux alternatifs comme des comportements alternatifs : chaque flux alternatif représente une autre possibilité de comportement, qui dérive généralement de l'existence d'exceptions dans le flux principal. Ces flux peuvent être aussi longs que nécessaire afin de décrire les événements associés au comportement. Au terme d'un flux alternatif, les événements du flux principal reprennent leur cours.]

2.2.1.1     < Sous-flux alternatif >

[Les flux alternatifs peuvent, à leur tour, être divisés en sous-sections pour plus de clarté.]

2.2.2          < Flux alternatif numéro deux >

[Un cas d'utilisation peut contenir (et contiendra très certainement) plusieurs flux alternatifs. Maintenez chacun de ces flux séparés pour plus de clarté. Leur usage améliore la lisibilité du cas d'utilisation. Les flux alternatifs permettent également d'éviter la décomposition des cas d'utilisation en hiérarchies. Souvenez-vous que les cas d'utilisation ne sont que des descriptions textuelles et qu'ils ont essentiellement pour objectif de documenter le comportement d'un système de manière claire, concise et intelligible.]

3.                  Exigences particulières

[En général, une exigence particulière est une exigence non fonctionnelle spécifique à un cas d'utilisation, qui n'est pas facilement ou naturellement définie dans le texte d'un flux d'événements de cas d'utilisation. Les exigences particulières comprennent par exemple les exigences légales et réglementaires, les standards d'application, ainsi que les attributs de qualité du système en construction, tels que sa convivialité, sa fiabilité, ses performances ou sa capacité de prise en charge. D'autres exigences peuvent être enregistrées dans cette section, comme les systèmes et environnements d'exploitation, les exigences de compatibilité et les contraintes de conception.]

3.1               < Exigence particulière numéro un >

 

4.                  Préconditions

[La précondition d'un cas d'utilisation est l'état qui doit caractériser le système avant la réalisation du cas d'utilisation.]

4.1               < Précondition numéro un >

 

5.                  Postconditions

[La postcondition d'un cas d'utilisation est une liste d'états qui peuvent caractériser le système immédiatement après la réalisation du cas.]

5.1               < Postcondition numéro un >

 

6.                  Points d'extension

[Points d'extension du cas d'utilisation.]

6.1               <Nom du point d'extension>

[Définition de l'emplacement du point d'extension dans le flux d'événements.]