Gabarit du Rapport d’analyse

Le but de ce document est d’évaluer votre compréhension des besoins ainsi que vos plans pour les aborder. Ce document sert à faire une saisie de l’accord entre vous et votre client en ce qui a trait à ce qui sera construit. Il sert également de référence utile pour votre équipe de projet.

Les sections qui suivent ne seront pas tous pertinentes pour chaque projet. Par exemple, les projets n’auront pas tous une interface utilisateur ou une base de données.

Contexte (1 paragraphe)

Donnez un bref contexte suffisamment élaboré pour qu’une personne lisant ce document qui ne fait pas partie de votre équipe comprenne la raison de l’existence de ce document ainsi que son utilité.

Besoins (1 page)

Fournissez une liste numérotée des besoins de ce projet avec une courte description de chaque besoin. (Une phrase sera habituellement satisfaisant; n’écrivez pas plus qu’un court paragraphe.) Les besoins devraient être regroupés en catégories apparentées. Le but de cette section est de nommer et d’identifier les besoins. Il n’est pas nécessaire d’inclure une pléthore de détails qui pourraient évoluer avec le temps; cette partie sera satisfaisante à condition que le besoin principal soit identifié.

Données exemplaires et tests élémentaires ( 2 à 3 paragraphes)

Identifiez les données que votre client fournira ou que vous construirez pour passer à l’essai et vérifier le système tout au cours du cycle de vie du projet. Si les données ne sont pas actuellement disponibles, identifiez le processus et l’horaire qui les rendront disponibles. (Dans votre Rapport de la situation du projet, identifiez également cet élément comme étant un risque qui doit être géré.)

Prenez en note qu’il est impossible que vous et votre client aient trouvé un terrain d’entente par rapport aux besoins à moins que vous êtes d’accord en ce qui a trait aux tests élémentaires et aux données exemplaires qui seront utilisés pour vérifier que les besoins ont été assouvis. Il est essentiel que vous commenciez à recueillir ces tests élémentaires et données exemplaires de bonne heure.

Identifiez deux ou trois scénarios critiques et définissez leurs données exemplaires qui seront utilisées pour commencer à travailler sur les tests élémentaires. Vous ne devez pas fournir des tests élémentaires dans ce document, mais vous devriez utiliser des scénarios et des données exemplaires pour illustrer votre analyse des besoins à travers le document.

Modèle de cas d’utilisation ou aspects fonctionnels du système (2 à 3 paragraphes par aspect ou cas d’utilisation)

Définissez quelle fonctionnalité le système fournira. Idéalement, cette fonctionnalité serait organisée à partir des cas d’utilisation principaux que gère le système; elle peut également être organisée à partir des fonctions ou aspects principaux du système. Peu importe le cas, votre système devrait avoir de 3 à 10 de ces cas d’utilisation ou aspects principaux. Incluez un diagramme de cas d’utilisation mis à jour.

Pour chaque cas d’utilisation ou aspect :

Identifiez les besoins qu’il aborde, les acteurs qu’il implique, et toute condition préalable ou restriction. 

Définissez clairement la progression ‘habituelle’ des interactions avec le système. Identifiez les variations possibles de cette progression habituelle, et tout particulièrement les ‘exceptions’ qui doivent être abordées.

Illustrez la progression habituelle (ainsi que ses variation) à l’aide d’un exemple tiré des données échantillons d’un ou plusieurs de vos scénarios critiques. (Si l’illustration apparaîtra dans vos modèles en vraie grandeur d’interface utilisateur, référenciez simplement la copie d’écran pertinente.)

Aspects non-fonctionnels (1 paragraphe par aspect)

Certains besoins sont non-fonctionnels. (Par exemple, le système doit être échelonnable et gérer une utilisation continue, ou il doit être utilisable par des utilisateurs novices.) Décrivez votre stratégie pour aborder chaque besoin :

a) du point de vue conception  (comment vous planifiez développer et construire votre système pour aborder le besoin), et

b) du point de vue essai (comment vous planifiez vérifier que le besoin est assouvi).

Architecture à haut niveau (2 à 3 pages)

Dessinez un diagramme de progiciel (ou, possiblement, un diagramme de déploiement mis à jour) qui illustre les composantes clés de votre système (ex. serveur Web, base de données, interface utilisateur) ainsi que les technologies tiers que vous utiliserez et sur lesquelles vous serez dépendants (ex. IIS, MySql, PHP, etc.). Vous devriez formuler une brève déclaration pour chaque composante en ce qui a trait à son rôle dans le maintient des besoins du système. Illustrez l’architecture de votre système en dessinant deux ou trois diagrammes d’interaction à haut niveau qui démontrent l’interaction des composantes pour vos scénarios critiques et données exemplaires. (Si vous vous servez d’un outil UML tel que Rational Rose, vous devriez créer une classe de façade pour représenter chacune de vos composantes.)

Modèle en vraie grandeur de l’interface utilisateur (2 à 3 pages)

Copies d’écrans ou vraies pages GUI ou HTML qui illustrent l’apparence et l’impression de l’interface utilisateur pour vos scénarios critiques. Assurez-vous de vous servir de vos données exemplaires.

Schémas de la base de données et formats (1 page)

Si vos données seront souvent stockées dans une base de données ou dans un ficher, définissez les schémas de bases de données ou les formats fichiers pertinents. Illustrez ces concepts en démontrant comment vous planifiez stocker vos données.

Algorithmes (2 à 3 paragraphes par algorithme)

Si votre système dépendra d’un algorithme important (reconnaissance des formes, traitement des images, stratégie des jeux, problème de la répartition, etc.), identifiez ces algorithmes dans cette section. Donnez brièvement les grandes lignes du problème qui doit être résolu, les solutions que vous avez considérées, et l’algorithme que vous avez sélectionné. Illustrez l’algorithme à l’aide d’un exemple tiré de vos données exemplaires.