Spécifications fonctionnelles

Les spécifications fonctionnelles décrivent de manière précise chacun des traitements effectués par l’application. Elles permettent de dégager une structure générale du modèle conceptuel de données, en définissant les tables majeures et leurs interactions. En voici les grandes lignes.

Architecture des traitements

Mise à jour automatique des données de référence

Les informations relatives aux ouvrages présentés sur le site proviennent essentiellement (80 à 90 %) de deux sources de données complémentaires. L’une sert à alimenter la base avec tous les nouveaux ouvrages, l’autre sert à mettre à jour toutes les données qui concernent le prix et l’état du stock des livres. Ces deux sources proviennent d’un site central. Elles se présentent sous forme de fichiers structurés, qui seront automatiquement chargés dans la base de données Oracle de la façon suivante : une fois par jour pour le premier, deux fois par jour pour le second. Toutes les autres informations seront saisies manuellement au moyen d’une petite application intranet, dédiée à l’enrichissement des données relatives aux ouvrages.

Mise à jour depuis les formulaires du site

Les données saisies depuis le site web, et enregistrées dans la base, décrivent les coordonnées des utilisateurs, ainsi que les caractéristiques de leurs commandes. Les coordonnées de l’utilisateur sont mémorisées. Dans un premier temps, elles permettent d’envoyer un colis. Dans un second temps, cela épargne de les saisir de nouveau lors des prochaines commandes. Les commandes sont enregistrées, puis traitées ultérieurement manuellement. L’utilisateur peut consulter l’historique de toutes ses commandes.

Le caddie

L’application laisse à l’utilisateur la possibilité de choisir plusieurs ouvrages et de les placer dans un caddie, ou panier, avant de passer commande. L’utilisateur a la possibilité de gérer lui même son caddie, en y ajoutant ou en y supprimant les ouvrages de son choix. Le caddie n’est en aucune façon sauvegardé dans la base. Sa durée de vie n’excède pas celle de la visite de l’utilisateur.

Étude de la transaction du processus de paiement sécurisé

La saisie du numéro de carte de crédit doit s’effectuer de manière sécurisée, en cryptant le transfert HTTP,viale protocole SSL. La commande et le numéro de la carte sont stockés dans la base, jusqu’au traitement de la commande. Le traitement s’effectue au moyen d’un PAD relié à une banque. Cette dernière valide la transaction. À cette étape, le numéro de la carte de crédit est supprimé de la base de données.

Le maquettage

Il est temps de représenter de manière concrète ce qui est suggéré par les spécifications fonctionnelles. La maquette, au format HTML, va représenter toutes les pages de l’application, elle n’est en aucun cas un prototype de l’architecture. Elle ressemble plutôt à un décor cinématographique, sans aucun lien avec des traitements ou une base de données. Elle permet de dresser la liste exhaustive de tous les types de pages rencontrées, de valider l’enchaînement des écrans(cinématique), ainsi que leur apparence, et d’affiner le dictionnaire des données.

Interface et ergonomie

Une ergonomie adaptée est indispensable pour attirer des internautes de plus en plus exigeants, habitués à naviguer à travers des interfaces intuitives, qui permettent de trouver rapidement l’information dont ils ont besoin. Aussi, un site doit-il être conçu en ayant à l’esprit deux points fondamentaux : 1. Les pages ne doivent pas être surchargées ; chacune doit contenir une seule information majeure, clairement identifiée. 2. Le nombre de navigations entre les pages pour atteindre l’information recherchée doit être réduit au maximum. Afin d’obtenir des pages claires et lisibles, la maquette doit combiner ces deux principes.

La maquette

On confond souvent le prototype de la maquette avec la maquette elle-même. Le prototype permet de valider toute la chaîne technique, depuis le navigateur jusqu’à la base de données. En général, il est constitué de deux pages. La première fait appel à un formulaire (avec envoi de données vers le serveur) ; la seconde au résultat attendu (retour de la réponse du serveur vers le navigateur client). Ce prototype permet de vérifier que toutes les couches techniques sont bien traversées, dans un sens comme dans l’autre (par exemple, navigateur
→serveur HTTP
→ page PHP
→ middleware
→ pilote de la base de données
→ procédures stockées
→ données). La maquette a pour but de valider l’ensemble des données et des traitements, la navigation (cinématique) et l’aspect graphique. En aucun cas, elle ne valide l’aspect technique du site. Ainsi, aucune des pages présentes dans une maquette n’est dynamique, aucune ne fournit un accès à une base de données. C’est le décor. Ce qu’il y a derrière est laissé à la charge du prototype.

Le Modèle conceptuel de données

Tous les éléments sont à présent réunis pour constituer le Modèle conceptuel de données (MCD). Les spécifications générales ont permis de comprendre comment chaque élément interagit avec les données présentes dans la maquette.
Entités majeures
On appelle entités majeures toutes les tables qui correspondent aux grandes notions que le projet invoque, et qui sont indispensables. Ici, ces tables sont au nombre de quatre. Une table permet de gérer les ouvrages, une autre les clients, une autre les commande, et la dernière les thèmes associés aux ouvrages. Ces quatre tables constituent le cœur du MCD. Toutes les autres ne serviront qu’à préciser chacune d’entre elles.
Entités mineures
Les entités mineures sont les tables qui permettent de compléter les descriptions des entités majeures. Ces tables sont au nombre de deux : la table des auteurs (liée à la table ouvrages) et la table des adresses de livraison (liée à la table commandes).
Entités de paramétrage
Les entités de paramétrage contiennent les données qui permettent de paramétrer l’application. Leur utilisation autorise une certaine souplesse. Ainsi, un module d’administration peut en modifier la valeur. Mais, en aucun cas, la modification ne doit porter sur le code des pages réalisées. Une seule table de ce type est présente dans le MCD. Elle décrit les grandes catégories de thèmes, par exemple l’informatique ou le management.

La maquette validée et le MCD terminé, nous allons nous appliquer à préparer la phase de développement. Les spécifications détaillées ont pour objectif de décrire toutes les données, tous les traitements et tous les événements de l’ensemble des pages qui seront soumis aux développeurs
Enjeu
Avant de débuter la réalisation, la description des spécifications détaillées est indispensable pour lever toutes les ambiguïtés qui peuvent survenir lors du développement. Ces documents sont également l’occasion de recueillir l’accord de toutes les parties concernées (client, fournisseur, maître d’ouvrage et maître d’œuvre) sur ce qui va être livré à la fin du projet, car ils décrivent toutes les règles de gestion mis en œuvre.
Que décrire ?
La description des spécifications doit répondre à toutes les attentes du programmeur, afin qu’il puisse procéder au développement de la page. La page doit contenir toutes les données présentes, toutes les règles de gestion de la page, tous les traitements effectués ainsi que leurs algorithmes, et tous les noms des pages auxquelles il est possible d’accéder depuis cette page.