Spécifications fonctionnelles 11








télécharger 95.91 Kb.
titreSpécifications fonctionnelles 11
date de publication18.03.2018
taille95.91 Kb.
typeDocumentos
ar.21-bal.com > documents > Documentos
logo in tech info 2010

« IN’TECH LIVE »

Spécifications 

Version 4.2

24/03/2010

Historique des révisions

Date

Version

Description

Auteur

29/03/2011

1.0

Première version

Niels

30/03/2011

2.0

Ajout des cas d’utilisation

Niels/Thibault

01/04/2011

3.0

Suite des cas d’utilisation

Niels/Vincent

10/04/2011

3.1

Correction

Vincent

11/04/2011

4.0

Finalisation des cas d’utilisation

Niels/Denis

15/04/2011

4.1

Détail des spécifications SR

Thibault / Vincent

19/04/2011

4.2

Correction des fautes

Denis

Sommaire

1Introduction 4

1.1Contexte initial, historique et vision 4

1.2Mission 4

1.3Objectifs 4

1.4Glossaire 4

2Termes du domaine 4

3Termes techniques 4

3.1Documents de référence 4

Description générale 6

3.2Acteurs 6

3.3Cas d’utilisations 7

Spécifications fonctionnelles 11

3.4Carte de navigation 11

3.5Détails des cas d’utilisations 13

Cas d’utilisation n°1 13

4Le cas débute lorsque l’utilisateur clique sur le bouton « Valider » 14

5L’utilisateur attend la réponse du système 14

6Le système analyse les données et si la vérification est correcte, envoie la nouvelle page : « Home » 14

7L’utilisateur voit la nouvelle page apparaître 14

Cas d’utilisation n°2 16

Cas d’utilisation n°4 22

Cas d’utilisation n°5 25

Cas d’utilisation n°6 28

Cas d’utilisation n°7 31

Cas d’utilisation n°8 34

Cas d’utilisation n°9 37

Cas d’utilisation n°10 38

Cas d’utilisation n°11 42

Cas d’utilisation n°12 44

Cas d’utilisation n°13 46

2.5 Environnement opérationnel 49

1.1 Contraintes de conception et d’implémentation 49

7.1Documentation 50

7.2Attributs de qualité 51


1Introduction

1.1Contexte initial, historique et vision


cf. Etude d’opportunité

1.2Mission


cf. Etude d’opportunité

1.3Objectifs


cf. Etude d’opportunité

1.4Glossaire

2Termes du domaine



3Termes techniques



3.1Documents de référence


Etude d’opportunité et de faisabilité

Charte de projet

Résultat des sondages

Etudes déjà menées :

  • Réalisation d’un PowerPoint pour présenter le projet au directeur de l’école.

  • Sondage auprès des élèves et du corps enseignant pour évaluer les besoins.

  • Réalisation d’un document rendant compte des résultats du sondage.

  • Réalisation d’un document de validation de projet.

  • Récupération des en-têtes d’emails.

  • Réalisations de la maquette des différentes vues de l’application.

  • Réalisation du logo.

Description générale

3.2Acteurs





Nom

Description

L’utilisateur

Les étudiants et le corps enseignant d’IN’TECH INFO


L’administrateur

Le BDE, la communication et le corps enseignant d’IN’TECH INFO



3.3Cas d’utilisations




  1. Diagramme de cas d’utilisation


[s5][in\'techlive][diagramme cas d\'utilisation][1

Listes des cas d’utilisations


Nom des fonctionnalités

Acteur(s)

Priorité

Risque

Planning personnalisé

Elèves et membres de l’équipe pédagogique d’IN’TECH INFO

Elevée

Elevé

Planning PI/PRP

Elèves et membres de l’équipe pédagogique d’IN’TECH INFO

Elevée

Moyen

Réservation des salles/matériel

Elèves et membres de l’équipe pédagogique d’IN’TECH INFO

Elevée

Moyen

Supervision

Elèves et membres de l’équipe pédagogique d’IN’TECH INFO

Elevée

Moyen

Mail

Elèves et membres de l’équipe pédagogique d’IN’TECH INFO

Elevée

Faible

Application/Back-office

Elèves et membres de l’équipe pédagogique d’IN’TECH INFO

Moyenne

Moyen

Notifications

Elèves et membres de l’équipe pédagogique d’IN’TECH INFO

Moyenne

Moyen

Sondage

Elèves et membres de l’équipe pédagogique d’IN’TECH INFO

Faible

Moyen

News

Elèves et membres de l’équipe pédagogique d’IN’TECH INFO

Faible

Faible

Chat

Elèves et membres de l’équipe pédagogique d’IN’TECH INFO

Faible

Faible

Spécifications fonctionnelles

3.4Carte de navigation


macintosh hd:users:denis:dropbox:in\'tech live:avant-projet:carte de navigation:carte de navigation.png


3.5Détails des cas d’utilisations

Cas d’utilisation n°1

  1. Nom du cas


Application - Se connecter

Description :


Sur la page de démarrage (page de connexion), il y a un formulaire pour se connecter. Il possède trois informations : mail, mot de passe ainsi qu’un bouton « Valider ». Si on a rempli les champs (informations valides avec la base de données) et que l’on clique sur le bouton « Valider », l’utilisateur sera alors redirigé sur la page « Home » de notre application qui contient les différents outils.

Acteur principal :


Les utilisateurs du « programme » seront les principaux acteurs de ce cas d’utilisation.

Acteurs secondaires :


Les administrateurs

Pré-conditions :


L’utilisateur aura déjà téléchargé, installé et ouvert l’application. Il doit donc se trouver sur la page de connexion.

Post-conditions (garantie en cas de succès) :


L’utilisateur devrait voir apparaître sur son écran la page « HomeConnexion ».

Scénario nominal :


4Le cas débute lorsque l’utilisateur clique sur le bouton « Valider »

5L’utilisateur attend la réponse du système

6Le système analyse les données et si la vérification est correcte, envoie la nouvelle page : « Home »

7L’utilisateur voit la nouvelle page apparaître

Interface utilisateur :


description : c:\users\slein\desktop\maquette application in\'tech live\iphone_page_d\'acceuil_co.pngdescription : c:\users\slein\desktop\maquette application in\'tech live\iphone_connexion.png


Fréquence :


Idéalement, au moins une fois pour chaque étudiant et enseignant par jour.

Cas d’utilisation n°2

  1. Nom du cas


Application - S’inscrire

Description :


Sur la page de démarrage (page de connexion), il y a un bouton pour s’inscrire. Une fois que l’on a cliqué sur le bouton, l’utilisateur est redirigé vers la page d’inscription. Cette inscription possède quatre informations : prénom, nom, mail, mot de passe ainsi qu’un bouton « valider ». Si on a rempli les champs (avec des informations valides, en accord avec la base de données, c’est-à-dire avec les informations utilisées par IN’TECH INFO) et qu’on clique sur le bouton « Valider », l’utilisateur sera alors redirigé sur la page « connexion » de notre application et reçois un pop-up indiquant « inscription bien effectuée ».

Acteur principal :


Les utilisateurs du « programme » seront les principaux acteurs de ce cas d’utilisation.

Acteurs secondaires :


Les administrateurs

Pré-conditions :


L’utilisateur aura déjà téléchargé, installé et ouvert l’application. Il doit donc se trouver sur la page de connexion.

Post-conditions (garantie en cas de succès) :


L’utilisateur devrait voir apparaître sur son écran la page « connexion » et un pop-up précisant que l’inscription à bien été effectué.

Scénario nominal :


  1. Le cas débute lorsque l’utilisateur clique sur le bouton « inscription »

  2. L’utilisateur attend la réponse du système

  3. Le système envoie la nouvelle page : « inscription »

  4. L’utilisateur voit la nouvelle page apparaître

  5. L’utilisateur remplit les champs (avec les informations IN’TECH INFO) et clique sur le bouton « Valider »

  6. Le système vérifie les informations et effectue l’inscription si les informations sont valides.

  7. Le système renvoie sur la page « connexion » et envoie un pop-up à l’utilisateur.

  8. L’utilisateur voit la nouvelle page apparaître ainsi que le pop-up.

  9. L’utilisateur doit alors se connecter.


Interface utilisateur:


description : c:\users\slein\desktop\maquette application in\'tech live\iphone_connexion.pngdescription : c:\users\slein\desktop\maquette application in\'tech live\iphone_inscription.png


Fréquence:


Idéalement, au moins une fois pour chaque étudiant et enseignant lors de la première utilisation.Cas d’utilisation n°3
  1. Nom du cas


Voir (ses mails, son planning, notification …)

Description :


Sur la page « Home», on peut voir les différents boutons des outils. Lorsque l’on clique sur un de ces derniers, on sera redirigé sur l’application en question.

Acteur principal :


Les utilisateurs du « programme » seront les principaux acteurs de ce cas d’utilisation.

Acteurs secondaires :


Les administrateurs

Pré-conditions :


L’utilisateur aura déjà téléchargé, installé, ouvert l’application et s’être connecté.

Post-conditions (garantie en cas de succès) :


L’utilisateur devrait voir apparaître sur son écran la page « connexion » et un pop-up précisant que l’inscription à bien été effectué.

Scénario nominal :


  1. Le cas débute lorsque l’utilisateur clique sur un des boutons des différentes applications

  2. L’utilisateur attend la réponse du système

  3. Le système envoie la page de l’application sélectionnée par l’utilisateur

  4. L’utilisateur voit la nouvelle page apparaître


Interface utilisateur :


macintosh hd:users:denis:dropbox:in\'tech live:maquettes:planningevent.pngmacintosh hd:users:denis:dropbox:in\'tech live:maquettes:planningreservation.pngmacintosh hd:users:denis:dropbox:in\'tech live:maquettes:planningmain.png

description : c:\users\slein\desktop\maquette application in\'tech live\iphone_page_d\'acceuil_co.png


macintosh hd:users:denis:dropbox:in\'tech live:maquettes:mailread.pngmacintosh hd:users:denis:dropbox:in\'tech live:maquettes:supmain.pngmacintosh hd:users:denis:dropbox:in\'tech live:maquettes:supshell.png

Fréquence :


Souvent par tous les utilisateurs

Cas d’utilisation n°4

  1. Nom du cas


Planning – Ajouter Evènement

Description :


Lorsque l’on clique sur le bouton « Ajouter un évènement » (réservation de salle, matériel, événement PRP…), l’utilisateur voit une nouvelle page s’afficher (pop-up ?) qui demandera le type d’évènement, le nom, la durée (…). Une fois ces champs remplis, on devra cliquer sur le bouton « Valider ». L’utilisateur est alors redirigé vers le planning et voit un pop-up apparaître lui indiquant que son événement a bien été créé. Dans le cas où il doit y avoir confirmation (exemple : réservation de matériel), le pop-up indiquera également : « votre demande a été prise en compte et est en cours de validation, vous serez averti via une notification sur l’application ».

Acteur principal :


Les utilisateurs du « programme » seront les principaux acteurs de ce cas d’utilisation.

Acteurs secondaires :


Les administrateurs

Pré-conditions :


L’utilisateur aura déjà téléchargé, installé et ouvert l’application. Il doit également se trouver sur l’application planning.

Post-conditions (garantie en cas de succès) :


L’utilisateur devrait voir apparaître sur son écran la page « Planning » et un pop-up.

Scénario nominal :


  1. Le cas débute lorsque l’utilisateur clique sur le bouton « ajouter événement »

  2. L’utilisateur attend la réponse du système

  3. Le système envoie la nouvelle page : « ajouterEvenement »

  4. L’utilisateur voit la nouvelle page apparaître

  5. L’utilisateur remplit les champs et appuie sur le bouton « Valider »

  6. Le système vérifie les champs et ajoute l’événement à la BDD. Il renvoie la page planning et un pop-up indiquant « Votre événement à bien été créé ».

  7. L’utilisateur voit alors la nouvelle page apparaître et le pop-up

Interface utilisateur:



Fréquence :


Idéalement, au moins une fois pour chaque étudiant et enseignant par jour.

Cas d’utilisation n°5

  1. Nom du cas


Planning - Supprimer Evènement

Description :


Lorsque l’on clique sur le bouton « Supprimer évènement », l’utilisateur voit un pop-up s’afficher qui demandera une confirmation de la suppression. L’utilisateur clique sur oui ou non et est alors redirigé vers le planning et voit un pop-up apparaître lui indiquant que son événement a bien été supprimé.

Acteur principal :


Les utilisateurs du « programme » seront les principaux acteurs de ce cas d’utilisation.

Acteurs secondaires :


Les administrateurs

Pré-conditions :


L’utilisateur aura déjà téléchargé, installé et ouvert l’application. Il doit également se trouver sur l’application planning.

Post-conditions (garantie en cas de succès) :


L’utilisateur devrait voir apparaître sur son écran la page « Planning » et un pop-up.

Scénario nominal :


  1. Le cas débute lorsque l’utilisateur clique sur le bouton « supprimer événement »

  2. L’utilisateur attend la réponse du système

  3. Le système envoie un pop-up : « voulez-vous vraiment supprimer votre événement ?»

  4. L’utilisateur voit le pop-up apparaître

  5. L’utilisateur répond par oui

  6. Le système supprime l’événement de la BDD. Il renvoie la page planning et un pop-up indiquant « Votre événement à bien été supprimé ».

  7. L’utilisateur voit alors la nouvelle page apparaître et le pop-up

Interface utilisateur:







Fréquence :


Idéalement, au moins une fois pour chaque étudiant et enseignant par jour.

Cas d’utilisation n°6

  1. Nom du cas


Planning - Réserver

Description :


Lorsque l’on clique sur le bouton « Réserver », l’utilisateur voit une page « réservation » s’afficher. Cette page comporte plusieurs champs (nom de la salle, heure de réservation, des boutons pour sélectionner le matériel et enfin un bouton « Valider »). L’utilisateur remplit les champs puis clique sur « Valider » et est alors redirigé vers le planning et voit un pop-up apparaître lui indiquant que sa réservation a bien été prise en compte et est en attente de validation. Et qu’il recevra une notification/mail.

Acteur principal :


Les utilisateurs du « programme » seront les principaux acteurs de ce cas d’utilisation.

Acteurs secondaires :


Les administrateurs

Pré-conditions :


L’utilisateur aura déjà téléchargé, installé et ouvert l’application. Il doit également se trouver sur l’application planning et dans la barre d’option.

Post-conditions (garantie en cas de succès) :


L’utilisateur devrait voir apparaître sur son écran la page « Planning » et un pop-up.

Scénario nominal :


  1. Le cas débute lorsque l’utilisateur clique sur le bouton « Réserver »

  2. L’utilisateur attend la réponse du système

  3. Le système envoie la page : « réservation»

  4. L’utilisateur voit la page apparaitre

  5. L’utilisateur remplit les champs et clique sur le bouton « Valider »

  6. Le système vérifie si une réservation est possible et crée la réservation dans la BDD. Il renvoie la page planning et un pop-up indiquant « Votre réservation a été prise en compte et est en attente de validation. Vous serez averti par mail/notification. ».

  7. L’utilisateur voit alors la page planning apparaitre et le pop-up

Interface utilisateur:





Fréquence :


Idéalement, au moins une fois pour chaque étudiant et enseignant par jour.

Cas d’utilisation n°7

  1. Nom du cas


Planning - Option

Description :


Lorsque l’on clique sur la barre «Option », l’utilisateur voit la barre s’agrandir et monter verticalement affichant 3 boutons d’options : « Réserver », « Ajouter Evènement », « Mes évènements & réservations ».

Acteur principal :


Les utilisateurs du « programme » seront les principaux acteurs de ce cas d’utilisation.

Acteurs secondaires :


Les administrateurs

Pré-conditions :


L’utilisateur aura déjà téléchargé, installé et ouvert l’application. Il doit également se trouver sur l’application planning.

Post-conditions (garantie en cas de succès) :


L’utilisateur devrait voir apparaître sur son écran la page « Planning » et la barre « Option » s’agrandit.

Scénario nominal :


  1. Le cas débute lorsque l’utilisateur clique sur la barre « Option »

  2. L’utilisateur attend la réponse du système

  3. Le système agrandit la barre option en conservant la même page

  4. L’utilisateur voit la barre s’agrandir

Interface utilisateur:





Fréquence :


Idéalement, au moins une fois pour chaque étudiant et enseignant par jour.

Cas d’utilisation n°8

  1. Nom du cas


Planning – Afficher évènement

Description :


Lorsque l’on clique sur le flag d’un événement PI & PRP sur le planning, l’utilisateur voit un pop-up apparaitre sur la plage de l’heure où se situe l’événement avec sa description (nom, salle, description…)

Acteur principal :


Les utilisateurs du « programme » seront les principaux acteurs de ce cas d’utilisation.

Acteurs secondaires :


Les administrateurs

Pré-conditions :


L’utilisateur aura déjà téléchargé, installé et ouvert l’application. Il doit également se trouver sur l’application planning.

Post-conditions (garantie en cas de succès) :


L’utilisateur devrait voir apparaître sur son écran la page « Planning » et un pop-up avec la description de l’événement

Scénario nominal :


  1. Le cas débute lorsque l’utilisateur clique sur le flag de « l’événement »

  2. L’utilisateur attend la réponse du système

  3. Le système envoie un pop-up en conservant la même page

  4. L’utilisateur voit le pop-up apparaître

Interface utilisateur:





Fréquence :


Idéalement, au moins une fois pour chaque étudiant et enseignant par jour.

Cas d’utilisation n°9

  1. Nom du cas


Planning – Changer de jour

Description :


Lorsque l’on clique sur le flag d’un événement PI & PRP sur le planning, l’utilisateur voit un pop-up apparaitre sur la plage de l’heure où se situe l’événement avec sa description (nom, salle, description…)

Acteur principal :


Les utilisateurs du « programme » seront les principaux acteurs de ce cas d’utilisation.

Acteurs secondaires :


Les administrateurs

Pré-conditions :


L’utilisateur aura déjà téléchargé, installé et ouvert l’application. Il doit également se trouver sur l’application planning.

Post-conditions (garantie en cas de succès) :


L’utilisateur devrait voir apparaître sur son écran la page « Planning » et un pop-up avec la description de l’événement

Scénario nominal :


  1. Le cas débute lorsque l’utilisateur clique sur le flag de « l’événement »

  2. L’utilisateur attend la réponse du système

  3. Le système envoie un pop-up en conservant la même page

  4. L’utilisateur voit le pop-up apparaitre





Cas d’utilisation n°10

  1. Nom du cas


Mail

Description :


Sur la page « Home», on peut voir les différents boutons des outils. Lorsque l’on clique sur Mail, alors l’utilisateur a accès aux dix derniers mails présents sur son compte Outlook de l’école.

Acteur principal :


Les utilisateurs du « programme » seront les principaux acteurs de ce cas d’utilisation.

Acteurs secondaires :


Les administrateurs

Pré-conditions :


L’utilisateur aura déjà téléchargé, installé et ouvert l’application. Il doit également se trouver sur l’application Mail.

Post-conditions (garantie en cas de succès) :


L’utilisateur devrait voir apparaître sur son écran la page « Mail » avec les dix derniers mails qu’il a reçu.

Scénario nominal :


  1. Le cas débute lorsque l’utilisateur clique sur l’application « Mail »

  2. L’utilisateur attend la réponse du système

  3. Le système charge les dix derniers mails

  4. L’utilisateur voit ses mails apparaître





Interface utilisateur :





Fréquence :


Idéalement, au moins une fois pour chaque étudiant et enseignant par jour.

Cas d’utilisation n°11

  1. Nom du cas


Supervision

Description :


Lors de la première connexion, l’utilisateur a accès à une page sur laquelle il doit renseigner l’adresse IP de son serveur (pour le SR seulement). La page indique aussi comment installer l’utilitaire nécessaire au bon fonctionnement de l’application sur son serveur.

Acteur principal :


Les utilisateurs du « programme » seront les principaux acteurs de ce cas d’utilisation.

Pré-conditions :


L’utilisateur aura déjà téléchargé, installé et ouvert l’application. Il doit également se trouver sur l’application « Supervision ».

Post-conditions (garantie en cas de succès) :


L’utilisateur a sur son écran la page de première connexion de l’outil Supervision.

Scénario nominal :


  1. Le cas débute lorsque l’utilisateur clique sur Supervision

  2. L’utilisateur attend la réponse du système

  3. Le système charge la page de première connexion

  4. L’utilisateur voit la page de première connexion

Interface utilisateur:





Fréquence :


Idéalement, au moins une fois pour chaque étudiant et enseignant par jour.









Cas d’utilisation n°12

  1. Nom du cas


Supervision

Description :


Sur la page « Home», on peut voir les différents boutons des outils. Lorsque l’on clique sur « Supervision », alors l’utilisateur a accès à une page de supervision de son serveur (pour le SR seulement).

Acteur principal :


Les utilisateurs du « programme » seront les principaux acteurs de ce cas d’utilisation.

Pré-conditions :


L’utilisateur aura déjà téléchargé, installé et ouvert l’application. Il doit également se trouver sur l’application « Supervision ». L’utilisateur devra juste installer un package sur son serveur, qu’il pourra télécharger sur notre site. Il aura déjà renseigné l’adresse IP de son serveur.

Post-conditions (garantie en cas de succès) :


L’utilisateur devrait voir apparaître sur son écran la page « Supervision », avec l ‘état de son serveur en temps réel.

Scénario nominal :


  1. Le cas débute lorsque l’utilisateur clique sur l’application « Supervision »

  2. L’utilisateur attend la réponse du système

  3. Le système charge les données tenantes au serveur

  4. L’utilisateur voit le statut de son serveur


Interface utilisateur :


supmain.png

Cas d’utilisation n°13

  1. Nom du cas


Supervision

Description :


Sur la page supervision, l’utilisateur trouve un bouton « plus » (en haut à gauche) pour ajouter des serveurs.

Acteur principal :


Les utilisateurs du « programme » seront les principaux acteurs de ce cas d’utilisation.

Pré-conditions :


L’utilisateur aura déjà téléchargé, installé et ouvert l’application. Il doit également se trouver sur l’application « Supervision ». L’utilisateur devra juste installer un package sur son serveur, qu’il pourra télécharger sur notre site. Il aura déjà renseigné l’adresse IP d’un serveur.

Post-conditions (garantie en cas de succès) :


L’utilisateur devrait voir apparaître sur son écran une page avec la liste des serveurs qu’il supervise.

Scénario nominal :


  1. Le cas débute lorsque l’utilisateur clique sur l’application « supervision »

  2. L’utilisateur attend la réponse du système

  3. Le système charge la liste des serveurs

  4. L’utilisateur voit la liste des serveurs


Interface utilisateur :


suplistserver.png



















2.5 Environnement opérationnel




  • Le produit devra fonctionner sur iOS 3.0 et Android 2.2.

  • Le serveur devra interroger en IMAP le serveur Outlook.

  • Les utilisateurs devront avoir accès à internet pour utiliser l’application.

  • Pour la partie Supervision, le paquet sera disponible sur Windows XP et versions supérieures, sur Debian 5+,


    1. Contraintes de conception et d’implémentation




  • Technologies utilisées :

    • Serveur : Ruby + Framework On Rails

    • Présentation : HTML5/CSS3

    • Animation : jQuery/Javascript

    • Apis Sencha (www.sencha.com)



  • Portables compatibles iOS 3.0 ou Android 2.2


7.1Documentation


Il y aura une documentation utilisateur qui comprendra l’explication de :

    • La connexion

    • L’inscription

    • Les différentes applications

Une documentation administrateur qui expliquera comment :

    • Créer un sondage, une news, une notification

    • Valider la réservation d’une salle, du matériel

Une documentation pour les futurs programmeurs sur le projet en cas d’évolution qui expliquera :

    • le code

    • l’application

    • l’architecture de l’application


7.2Attributs de qualité


Les attributs de qualités importants pour notre application sont :

  • Réutilisabilité : projet repris par de futurs élèves

  • Portabilité : iPhone & Android (puis autre smartphone)

  • Utilisabilité : bonne ergonomie et simple d’utilisation

  • Sécurité : l’application ne devra accepter que les membres du groupe IN’TECH INFO (étudiants, enseignants)

  • Intégrité : protection des données

similaire:

Spécifications fonctionnelles 11 iconDossier de Spécifications Fonctionnelles et Techniques du site éditorial et collaboratif

Spécifications fonctionnelles 11 iconAnnuaire d’entreprise
«time part» : Rédaction de spécifications fonctionnelles pour différents projets de sites marchands

Spécifications fonctionnelles 11 iconGuide d’établissement des spécifications du produit
«notes destinées au responsable de l’établissement des spécifications» après avoir modifié cette section

Spécifications fonctionnelles 11 iconFonctionnelles et Techniques

Spécifications fonctionnelles 11 iconCompétences fonctionnelles

Spécifications fonctionnelles 11 iconCompétences Fonctionnelles

Spécifications fonctionnelles 11 iconSynthèse des compétences fonctionnelles

Spécifications fonctionnelles 11 iconDes architecture fonctionnelles et d’autres émotionnelles

Spécifications fonctionnelles 11 iconRésumé A. Cette section comprend : Le système coulissant individuel...
«Voluntary Specifications for Forced Entry Resistant Aluminum Sliding Glass Doors» (Spécifications volontaires pour portes coulissantes...

Spécifications fonctionnelles 11 iconSpécifications du sal 35








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com