Capture des besoins techniques : des spécifications logicielles

By 16 April 2011

2. Capture des besoins techniques

La capture des besoins techniques recense toutes les contraintes et les choix dimensionnant la conception du système. Les outils et les matériels sélectionnés ainsi que la prise en charge des contraintes d’intégration conditionnant généralement des prés requis d’architecture générale.

La capture des besoins techniques se présente comme suit:

  • Capture des spécifications logicielles.
  • Capture des spécifications liées à la configuration matérielle.

2.1. Capture des spécifications logicielles

Une fois les spécifications matérielles déterminées, on passe aux spécifications non fonctionnelles autrement dit techniques ou logicielles. C’est des fonctionnalités techniques que le système va assurer à l’utilisateur indépendamment du terme métier ou fonctionnel.

On va donc énumérer une liste de fonctionnalités techniques que notre système va pouvoir assurer et offrir aux utilisateurs, c’est pourquoi nous avons introduit les concepts d’exploitant et de cas d’utilisation techniques:

2.1.1. Les exploitants

Appelés aussi « acteurs techniques » du système, ce sont les acteurs qui bénéficient des fonctionnalités techniques du système:

  • Utilisateur: c’est les personnes qui utilisent d’une manière ou d’une autre les fonctionnalités du système.
  • Administrateur: c’est la personne chargée de gérer toute la gestion de la plateforme ainsi que de celle des utilisateurs.

2.1.2. Identification des cas d’utilisation techniques

Nous allons procéder d’une manière hiérarchique sous forme d’un arbre en déterminant comme racines les principaux objectifs et aboutissants aux cas d’utilisations qui seront représentés par les feuilles de cet arbre.
Identification des objectifs techniques et les cas d’utilisation associés.
Tableau06. Identification des objectifs techniques et les cas d’utilisation

Objectifs Niveau1 Objectifs –Niveau2 Cas d’utilisation

associés.
Gestion de la sécurité
Authentification ‐S’authentifier.
‐ Vérification des champs.
‐ Mémoriser mot de passe.
‐ Changer le mot de passe.
‐ Fermeture de session.
Confidentialité ‐Gestion des rôles.
Paiement sécurisé ‐Envoyer le paiement via une plate‐forme sécurisée.
Sauvegarde et restauration ‐ Sauvegarder la BDD.
‐ Restaurer la BDD.
Gestion des données
Données dynamique ‐Affichage dynamique
Intégrité ‐ Mise à jour simultanées.
Interopérabilité ‐Déploiement en réseau.
Compatibilité ‐ Exécuter sur différents navigateurs.
Historique ‐ Affichage des différentes opérations effectuées par chaque exploitant.
Statistiques ‐ Afficher les statistiques de la plate‐forme.
Panier ‐ Migration du panier d’un utilisateur anonyme.
Gestion d’aide
Gestion des erreurs ‐Affichage des types d’erreurs.
‐ Envoyer l’erreur par mail à l’administrateur.
Aide en ligne ‐Consulter l’aide d’utilisation.
Notifications ‐ Message de confirmation ou d’erreurs.
Mails ‐Envoi de mails.
Gestion du paiement
Plate‐forme multidevises. ‐Choisir une devise à l’achat et le paiement.
Mode de paiement ‐Possibilité de choisir un mode de paiement.
Optimisation
Navigation ‐Opérations imbriquées.
Impression ‐ Possibilité d’imprimer sa facture.

2.1.3. Description des cas d’utilisation techniques

a) Cas d’utilisation: « S’authentifier »

Précondition:

  • • L’exploitant est inscrit dans le système.

Scénario nominal:

  • • L’exploitant saisi ses identifiants dans la page d’authentification.
  • • Le système le dirige vers l’espace qui lui est approprié.

b) Cas d’utilisation: « Vérifier la validité des champs »

Précondition:

  • • L’exploitant doit s’authentifié et accéder à un formulaire d’ajout ou modification.

Scénario nominal:

  • • L’exploitant accède à un formulaire.
  • • Il saisi les données et notre système contrôle sur chaque champ, s’il n’est pas vide, ou invalide (respectant les normes posé par la plate‐forme).

c) Cas d’utilisation: « Mémoriser le mot de passe »

Précondition:

  • • L’exploitant doit s’authentifié.

Scénario nominal:

  • • L’exploitant coche l’option de mémorisation.
  • • Le système fait en sorte de mémoriser le mot de passe pour la prochaine connexion.

d) Cas d’utilisation: « Changer le mot de passe »

Précondition:

  • • L’exploitant doit s’authentifié.

Scénario nominal:

  • • L’exploitant ouvre sa page.
  • • S’il a oublié le mot de passe il doit contacter l’administrateur.
  • • Sinon il peut accéder après authentification sur son espace perso à l’option de changement de mot de passe.
  • • Il doit saisir son ancien et nouveau mot de passe afin de valider le changement.

e) Cas d’utilisation: « Fermeture de session»

Précondition:

  • • L’exploitant doit s’authentifié.

Scénario nominal:

  • • Si le système détecte qu’il n’y a pas de mouvement sur la plate‐forme de la part de l’exploitant, alors il ferme la session courante.

f) Cas d’utilisation: « Gestion des rôles »

Précondition:

  • • L’administrateur doit s’authentifié.

Scénario nominal:

  • • A l’ajout, on affecte à chaque utilisateur un rôle.
  • • Une fois l’utilisateur authentifié par son compte, notre système le redirige selon son rôle vers son espace perso.
  • • L’administrateur peut migrer un utilisateur d’un rôle à un autre.

g) Cas d’utilisation: « Envoyer paiement via une plateforme sécurisée »

Précondition:

  • • L’exploitant doit être authentifié.

Scénario nominal:

  • • Après le choix du mode de paiement, le système redirige le client vers le module de paiement choisi.
  • • Le module lui envoi ses identifiant vers la base de données de la banque cible.
  • • La banque débite le compte et envoi la notification à l’exploitant.

h) Cas d’utilisation: « Sauvegarder la BDD »

Précondition:

  • • L’administrateur doit être authentifié.

Scénario nominal:

  • • Il lance l’opération de sauvegarde.
  • • Le système sauvegarde la BDD dans un fichier. sql et le stocke dans un répertoire spécifié.

i) Cas d’utilisation: « Restaurer la BDD »

Précondition:

  • • L’administrateur doit être authentifié.

Scénario nominal:

  • • Il lance l’opération de restauration.
  • • Le système le fichier .sql sauvegardé auparavant et l’injecte dans la BDD en écrasant les données existantes.

j) Cas d’utilisation: « Affichage dynamique »

Précondition:

  • • L’exploitant réalise une opération sur la base de données.

Scénario nominal:

  • • L’exploitant accède à la plate‐forme.
  • • Chaque changement est pris en compte par le système (catégorie, produits, clients…)
  • • L’exploitant peut remarquer qu’a chaque opération, le système réagi.

k) Cas d’utilisation: « Mise à jour simultanée »

Précondition:

  • • Deux utilisateurs effectuant la même opération au même temps.

Scénario nominal:

  • • Le système met en attente l’une des opérations.
  • • Il exécute la plus prioritaire ensuite il met à jour la BDD.
  • • Il exécute la deuxième opération et met à jour la BDD.

l) Cas d’utilisation: « Déploiement en réseau »

Précondition:

  • • Système déployé sur un serveur.

Scénario nominal:

  • • Les exploitants entrent l’URL exacte.
  • • Ils accèdent directement à l’interface d’accueil du système.

m) Cas d’utilisation: « Exécuter sur différents navigateurs »

Précondition:

  • • Installation des navigateurs sur la machine.

Scénario nominal:

  • • Lancement du navigateur choisi.
  • • Saisi de l’adresse URL.
  • • La plate‐forme s’exécute sur n’importe quel navigateur.

n) Cas d’utilisation: « Affichage des différentes opérations effectuées »

Précondition:

  • • L’exploitant doit être authentifié.

Scénario nominal:

  • • L’exploitant choisi de connaître la liste des différents mouvements sur la plate‐forme.
  • • Le système lui affiche une liste d’opérations effectuées par date.

o) Cas d’utilisation: « Afficher les statistiques de la plateforme »

Précondition:

  • • L’administrateur doit être authentifié.

Scénario nominal:

  • • Il accède à l’interface des statistiques.
  • • Il choisi l’information qu’il veut se procurer et le système lui fait le calcul et le rapport sur l’information demandée.

p) Cas d’utilisation: « Migration du panier d’un client anonyme »

Précondition:

  • • Le client doit remplir un panier et valider la commande.

Scénario nominal:

  • • Le système s’occupe de migrer tout le panier d’un client anonyme dès qu’il s’authentifie.
  • • Le client pourra ainsi revoir son panier et le valider.

q) Cas d’utilisation: « Afficher des types d’erreurs »

Précondition:

  • • Le système rencontre un problème après intervention de l’exploitant sur la plate‐forme.

Scénario nominal:

  • • Le système affiche le type d’erreur rencontrée selon son contexte.
  • • Il retourne l’exploitant dans sa page pour rectifier.

r) Cas d’utilisation: « Envoyer erreur à l’administrateur »

Précondition:

  • • Le système rencontre une erreur connue.

Scénario nominal:

  • • M’exploitant peut envoyer le rapport de l’erreur à l’administrateur afin qu’il puisse la signaler ou la corriger.

s) Cas d’utilisation: « Consulter l’aide d’utilisation »

Précondition:

  • • L’exploitant doit être authentifié.

Scénario nominal:

  • • Il consulte l’aide disponible sur la plate‐forme afin de connaître les différentes fonctionnalités et leurs enchaînements.

t) Cas d’utilisation: « Messages de notifications »

Précondition:

  • • L’exploitant réalise une opération qui nécessite une validation ou confirmation.

Scénario nominal:

  • • Le système gère chaque opération d’ajout, modification ou suppression nécessitant une confirmation ou validation, en affichant un message relatif à l’opération.

u) Cas d’utilisation: « Envoi de mail »

Précondition:

  • • Exploitant authentifié.

Scénario nominal:

  • • Notre système permet d’envoyer des mails au client au moment de la facturation.
  • • On peut aussi envoyer des mails à l’administrateur afin de signaler un problème.

v) Cas d’utilisation: « Choisir une devise »

Précondition:

  • • L’exploitant accède à la plate‐forme.

Scénario nominal:

  • • La devise par default est le Dinard Algérien. Si un client souhaite acheter avec une autre devise (euro ou dollars), il choisi sa devise et le système lui actualise la page en convertissant tous les prix.

w) Cas d’utilisation: « Choisir le mode de paiement »

Précondition:

  • • L’exploitant valide une commande.

Scénario nominal:

  • • On propose au client deux types de paiement: le fameux Paypal ou le nouveau module de la SATIM.

x) Cas d’utilisation: « Opérations imbriquées »

Précondition:

  • • L’exploitant doit être authentifié.

Scénario nominal:

  • • Le système permet à l’exploitant de réaliser plusieurs opérations sur le même processus (ex: ajout d’une catégorie dans le processus d’ajout d’un produit).

y) Cas d’utilisation: « Impression »

Précondition:

  • • L’exploitant doit être authentifié.

Scénario nominal:

  • • Le client peut bien évidemment imprimer ses factures avec l’option proposé par notre système.

2.2. Capture des spécifications matérielles

Etant donné que notre système est accessible par le web, c’est aussi une plate‐forme ecommerce
donc il existe un serveur de paiement électronique. Pour les données de notre système.

On a préféré détacher notre base de données du serveur web et la stocké en local dans un serveur de base de données pour des raisons de sécurité.
Schéma illustrant notre architecture matérielle.
Figure25. Schéma illustrant notre architecture matérielle.

Machines clients: ce sont des ordinateurs de bureau ou toutes sortes de machine ayant un navigateur web qui permet d’accéder à internet.

Machines serveur (BDD): comporte une importante capacité de stockage, doit être disponible afin qu’on puisse y accéder à tout moment, et doit avoir une puissante capacité de traitement dans le cas où plusieurs clients y accèdent en même temps.

Serveur web: c’est un ordinateur qui répond aux commandes des navigateurs en retournant des pages web. Il peut être aussi sous forme d’ensemble de serveurs permettant le fonctionnement des applications web. La plupart des serveurs web permettent aussi le fonctionnement de plusieurs applications en parallèle (IIS + SQL Server + ASP, PHP + Apache
+ MySQL).

Serveur web du paiement: Il héberge les certificats SSL et assurer l’interface entre le client, notre service et le serveur de paiement.
‐ Du côté de l’organisme de paiement nous constatons les éléments suivants:

Serveur de transactions: il permet de faire les vérifications sur les différentes informations concernant le paiement (statut de la carte, solde, date d’expiration).

Serveur d’accès sécurisé: c’est un serveur qui active les cartes de paiement et génère les mots de passes. Il contrôle aussi les données des clients selon des protocoles sécurisés.

Commerce Gateway: interface entre serveur de paiement et le serveur de transactions, il contient une gestion des risques (blocage…) ainsi qu’un accès sécurisé pour la consultation des différentes opérations.

Lire le mémoire complet ==> (Conception et réalisation d’une plate-forme de commerce électronique)
Mémoire de fin d’études pour l’obtention du diplôme d’Ingénieur d’Etat en Informatique
Ecole nationale supérieure d’informatique