Gabarit d’analyse

Le but de ce « milestone » est d’évaluer votre compréhension des besoins ainsi que vos plans pour les aborder. Aussi, il 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.

Page de besoins

1. Identifier et gérer les besoins les plus essentiels.

 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 les besoins les plus essentielles soit identifiés.

C'est suffisant de fournisser une liste numérotée des besoins de ce projet avec une courte définition précise et "testable" de chaque besoin. (Une phrase sera habituellement satisfaisant; n’écrivez pas plus qu’un court paragraphe.).  
La liste devrait inclure les besoins fonctionnels et non fonctionnels. 
 
Si vous préférez, ou si votre client insiste, vous pouvez décider d'utiliser plutôt un outil pour gérer les exigences; utilisez un libellé »besion» pour suivre comme »issues»: ou utilisez un »product backlog» pour gérer les »user stories / features»

2. Données exemplaires et scénarios critiques

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. (identifiez également cet élément comme étant un »risk » 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 »milestone », mais vous devriez utiliser des scénarios et des données exemplaires pour illustrer votre analyse des besoins.

Spécification des scénarios critiques

Définissez et spécifiez-les en tant que « issues », ou en tant que documents dans le contrôle de code source ou sur votre page de besoins.

Pour chaque scénaris critique:

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

Définissez et spécifiez-les en tant que « issues », ou en tant que documents dans le contrôle de code source ou sur votre page de besoins.

Pour chaque aspect non-fonctionnel 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).

Page de documentation

Indiquez où la documentation est trouvée (wiki, code source, google drive etc.) y compris (si il est pertinent):

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.

Page d’architecture

Mettre à jour au besoin.

Illustrez en dessinant des diagrammes d’interaction à haut niveau comment votre architecture traite les scénarios critiques.

Pages acteurs et cas d'utilisation, démonstration du système, d’environnement de développement

Mettre à jour au besoin.

Risques, Plan du projet

Mettre à jour au besoin (issues, boards, pages …).