Chapitre 2 : Phase d'inception.
Introduction :
Cette phase consiste à comprendre le contexte du
système. Il s'agit de déterminer les fonctionnalités et
les acteurs les plus pertinents, de préciser les risques les plus
critiques et d'identifier les cas d'utilisation initiaux. Ceci dit, notre
description va sembler trop détaillée pour une première
phase de processus.
I. Capture des besoins :
1. Définition des besoins fonctionnels :
Il s'agit des fonctionnalités du système. Ce sont
les besoins spécifiant un comportement
d'entrée / sortie du Système.
Le système à concevoir doit permettre à
l'utilisateur d'effectuer les opérations suivantes:
Référence Fonction
|
R1
|
Rechercher certification par mot
|
|
R2
|
Rechercher certification par domaine
|
|
R3
|
Rechercher certification par technologie
|
|
R4
|
Rechercher certification par code
|
|
R5
|
Consulter certification
|
|
R6
|
Consulter la certification prérequis
|
|
R7
|
Consulter les certifications après
|
|
R8
|
Télécharger un PDF de certification
|
|
R9
|
Inscrire pour passer une certification
|
|
R10
|
Consulter les formations
|
|
R11
|
Télécharger un PDF de formation
|
|
R12
|
Inscrire à une formation
|
|
R13
|
Donner l'avis sur formation
|
|
R14
|
Proposer formation
|
|
R15
|
Recevoir les notifications
|
|
R16
|
Authentifier
|
|
R17
|
Ajouter certification
|
Page | 23
|
R18
|
Modifier certification
|
|
R19
|
Supprimer certification
|
|
R20
|
Ajouter compétence
|
|
R21
|
Modifier compétence
|
|
R22
|
Supprimer compétence
|
|
R23
|
Ajouter formation
|
|
R24
|
Modifier formation
|
|
R25
|
Supprimer formation
|
|
R26
|
Ajouter gérant
|
|
R27
|
Modifier gérant
|
|
R28
|
Supprimer gérant
|
|
R29
|
Ajouter formateur
|
|
R30
|
Modifier formateur
|
|
R31
|
Supprimer formateur
|
|
R32
|
Consulter les inscrits aux certifications
|
|
R33
|
Valider l'inscription d'un client à une certification
|
|
R34
|
Consulter les avis
|
|
R35
|
Consulter les propositions
|
|
R36
|
Consulter les inscrits aux formations
|
|
R37
|
Valider l'inscription d'un client à une formation
|
|
R38
|
Envoyer un e-mail
|
Tableau 1 : Tableau des exigences. 2. Les besoins non
fonctionnels :
Les besoins non fonctionnels concernent les contraintes
à prendre en considération pour mettre en place une solution
adéquate aux attentes des concepteurs des architectures dynamiques.
Mon application doit nécessairement assurer ces besoins
:
? L'extensibilité : dans le cadre de
ce travail, l'application devra être extensible, c'est-à-dire
qu'il pourra y avoir une possibilité d'ajouter ou de modifier de
nouvelles fonctionnalités.
? La sécurité : l'application
devra être hautement sécurisée, les informations ne devront
pas être accessibles à tout le monde, c'est-à-dire qu'il
existe des fonctionnalités accessibles par un identifiant et un mot de
passe attribué à une personne physique.
? L'interface : avoir une application qui
respecte les principes des Interfaces Homme/Machine (IHM) tels que l'ergonomie
et la fiabilité.
? La performance : l'application devra
être performante c'est-à-dire que le système doit
réagir dans un délai précis, quel que soit l'action de
l'utilisateur.
? La convivialité : l'application doit
être simple et facile à manipuler même par des non
experts.
Page | 24
| 
