Vous êtes sur la page 1sur 21

Abdelmalek Essaadi

Faculté des Sciences Juridique


Et Economique de Tétouan
Master Spécialise en management des systèmes d’information

Rapport N°2 : Spécifications des Besoins

Application web et mobile pour la gestion d’une agence d’assurance

Réalise Par : Encadré Par :


AISSAOUI Chaimae Prof. MABROUK Aziz

AITE DRISS Ayoub

BOUZIANE Mohamed

GHOLAMI Hosni

HIOUANE Amina

MAACHE Ayyoub

MARBOUH Ahlam

Année universitaire 2019/2020

1
SOMMAIRE

INTRODUCTION :....................................................................................................................3
I. LES BESOINS FONCTIONNELLES : .....................................................................................4
A. IDENTIFICATION DES ACTEURS DU NOUVEAU SYSTEME : .............................................................. 4
B. IDENTIFICATION DES CAS D’UTILISATIONS :............................................................................... 4
1. Gestion des demandes d’assurance : ........................................................................ 4
2. Gestion des contrats d’assurances : .......................................................................... 6
3. Gestion des sinistres .................................................................................................8
4. Gestion des dossiers sinistres .................................................................................. 11
5. Gestion des règlements : ........................................................................................ 14
6. Gestion des clients : ................................................................................................ 16
II. LES BESOINS NON FONCTIONNELLES : ..........................................................................17
A. DEFINITION DES BESOINS NON FONCTIONNELLES.................................................................... 17
1. Sécurité : ................................................................................................................ 17
2. Audit :..................................................................................................................... 17
3. Performance : ......................................................................................................... 17
4. Capacité ................................................................................................................. 18
5. Disponibilité ........................................................................................................... 18
6. Fiabilité .................................................................................................................. 18
7. Intégrité ................................................................................................................. 18
8. Rétablissement ....................................................................................................... 18
9. Compatibilité .......................................................................................................... 19
10. Aptitude à la maintenance .................................................................................. 19
11. Ergonomie .......................................................................................................... 19
12. Documentation ................................................................................................... 19
CONCLUSION :......................................................................................................................20
WEBOGRAPHIE : ..................................................................................................................21

2
Introduction :

Dans le cadre de notre projet, on est dans la phase de détection des besoins fonctionnels qui

consiste à identifier tous les besoins spécifiant un comportement d'entrée ou de sortie du

Système, et toutes les fonctionnalités qu’on va intégrer dans notre plateforme et application.

On va étudier les spécifications fonctionnelles du système que nous comptons proposer, elle

portera essentiellement sur l’indentification des acteurs interagissant avec ce dernier, ainsi que

les cas d’utilisation des fonctionnalités qu’il entend offrir. Ensuite on va parler des besoins

non-fonctionnels qui caractérisent le système côté performance, confidentialité, convivialité et

sécurité…

3
I. Les Besoins Fonctionnelles :
Le travail suivant sert à identifier les différents besoins auxquels notre système doit répondre. Nous
présentons ci-dessous une liste non exhaustive de ces besoins :

1. La gestion de la demande d’assurances.


2. La gestion des contrats d’assurance (renouvellement).
3. La gestion et le suivi des sinistres ainsi que les différents documents nécessaires à leur
déclaration
4. Gestion et suivi des remboursements sur les sinistres.
5. Enregistrement dans la base de données de certains documents scannés ou sous format
électronique pour consultation, tels que : les quittance de prime, déclarations de sinistres,
justificatifs, …etc.
6. Gestion des clients, des réclamations …

A. Identification des acteurs du Nouveau système :


« Un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositif
matériel ou autre système) qui interagit directement avec le système étudié. Un acteur peut
consulter et/ou modifier directement l’état du système, en émettant et/ou en recevant des
messages susceptibles d’être porteurs de données ». [Roques, 2008]

L’administrateur : responsable de la gestion des utilisateurs du système, leurs droits


d’accès et contrôle le système et la base de données.

Directeur d’Agence d’Assurance (DAA) : consulte toutes les banques de données et les
documents relatifs aux différents processus de gestion des assurances ainsi que les différents
états du tableau de bord, s’occupe aussi de la validation des dossiers sinistre et des contrats.

Agent du Service Production (ASP) : S’occupe de la gestion des contrats d’assurances,


demandes d’assurances et des remboursements au niveau de la direction des affaires
juridiques.

Responsable Sinistre (RS) : s’occupe de la déclaration des sinistres, et de l’introduction


des différents documents justificatifs au niveau de chaque structure.

B. Identification des cas d’utilisations :


« Un cas d’utilisation correspond à un certain nombre d’actions que le système devra
exécuter en réponse à un besoin d’un acteur » [Pascal Roques, 2007].

1. Gestion des demandes d’assurance :


n Cas d'utilisation Acteur
5 Ajouter une demande ASP
6 Modifier une demande ASP
7 Consulter les demandes ASP/DAA
8 Supprimer une demande ASP
10 Ajouter et modifier les garanties d’une demande ASP
4
But : ajouter une demande d’assurances (incorporation).

Acteurs : ASP, DAA.

Scénario nominal :

Ce volet assure la gestion des incorporations des demandes d’assurances tout au long du

Processus.

Pré conditions :

- Utilisateur authentifié
- Utilisateur détient les droits d’accès

Scénario nominal :

Ce volet assure la gestion des incorporations (les demandes d’assurance) tout au long du
processus d’assurances

Enchainements :

a) Ajouter une demande d’assurance :


a. L’utilisateur clique sur « Ajouter une demande ».
b. Le système affiche une interface pour la saisie des informations relatives à la
demande.
c. L’utilisateur saisie les informations.
d. L’utilisateur clique sur « Enregistrer ».
b) Consulter une demande :
a. L’utilisateur clique sur « Liste des demandes ».
b. Le système affiche la liste des demandes.
c. L’utilisateur sélectionne une demande.
d. Le système affiche les informations de la demande.
c) Modifier une demande :
a. L’utilisateur clique sur « Liste des demandes ».
b. Le système affiche la liste des demandes.
c. L’utilisateur sélectionne une demande.
d. Le système affiche les détails de la demande.
e. L’utilisateur saisie les informations à modifier.
f. L’utilisateur clique sur « Enregistrer ».
d) Suppression d’une demande :
a. L’utilisateur clique sur « Liste des demandes ».
b. Le système affiche la liste des demandes.
5
c. L’utilisateur sélectionne une demande.
d. L’utilisateur clique sur « Supprimer demande ».
e) Ajouter et modifier des garanties d’une demande :
a. L’utilisateur clique sur « Liste des demandes ».
b. Le système affiche la liste des demandes.
c. L’utilisateur sélectionne une demande.
d. Le système affiche les informations de la demande.
e. L’utilisateur clique sur garanties.
f. Le système affiche la liste des garanties.
g. L’utilisateur ajoute ou supprime les garanties voulues.
h. L’utilisateur clique sur « Enregistrer ».

Post-conditions :

Enchainement (1) : Demande d’assurance ajoutée dans le système.


Enchainement (2) : Demande d’assurance modifiée dans le système.

Enchainement (4) : demande d’assurance Supprimée dans le système.


Enchainement (5) : liste de garanties modifiée dans la demande d’assurance.

2. Gestion des contrats d’assurances :


n Cas d'utilisation Acteur
1 Ajouter un contrat RSP
2 Modifier un contrat RSP
3 Consulter un contrat RSP/DAA
4 Supprimer un contrat RSP
5 Renouveler un contrat

Identification du cas

But : assurer la gestion et le suivi des contrats d’assurances de l’entreprise.

Acteurs : AGTD.

Pré conditions :

- Utilisateur authentifié
- Utilisateur détient les droits d’accès

Scénario nominal :

Ce volet assure la gestion des contrats tout au long du processus d’assurances.

6
Pré conditions :

- Utilisateur authentifié
- Utilisateur détient les droits d’accès

Enchainements :

a) Ajouter un contrat :
a. L’utilisateur clique sur « Ajouter contrat ».
b. Le système affiche une interface pour la saisie des informations relatives au
contrat.
c. L’utilisateur saisie les informations.
d. L’utilisateur clique sur « Enregistrer ».
b) Consulter contrat :
a. L’utilisateur clique sur « Liste contrats ».
b. Le système affiche la liste des contrats.
c. L’utilisateur sélectionne un contrat.
d. Le système affiche les détails du contrat
c) Modifier un contrat :
e. L’utilisateur clique sur « Liste contrats ».
f. Le système affiche la liste des contrats.
g. L’utilisateur sélectionne un contrat.
h. Le système affiche les détails du contrat.
i. L’utilisateur saisie les informations à modifier.
j. L’utilisateur clique sur « Enregistrer ».
d) Suppression d’un contrat :
k. L’utilisateur clique sur « Liste contrats ».
l. Le système affiche la liste des contrats.
m. L’utilisateur sélectionne un contrat.
n. L’utilisateur clique sur « Supprimer contrat ».
e) Renouvellement d’un contrat :
o. L’utilisateur clique sur « Liste contrats ».
p. Le système affiche la liste des contrats.
q. L’utilisateur sélectionne un contrat.
r. L’utilisateur clique sur « renouveler contrat ».
s. L’utilisateur spécifie les paramètres du nouveau contrat
t. L’utilisateur clique sur « enregistrer »

Post-conditions :

Enchainement (1) : contrat ajouté dans le système.


Enchainement (2) : contrat modifié dans le système.
Enchainement (4) : contrat Supprimé dans le système.
Enchainement (5) : contrat renouvelé dans le système.
7
3. Gestion des sinistres
n Cas d'utilisation Acteur
1 Ajouter un sinistre RS
2 Consulter un sinistre RS/DAA
3 Modifier un sinistre RS
4 Suppression d’un sinistre : RS
5 Ajouter un item au sinistre : RS
6 Supprimer item d’un sinistre : RS
7 Ajouter justificatif RS
8 Supprimer justificatif RS

Identification du cas :

But : Ajouter une déclaration de sinistre.

Acteurs : RS, DAA.

Scénario nominal :

Ce volet assure la gestion des déclarations de sinistres tout au long du processus.

Pré conditions :

- Utilisateur authentifié

- Utilisateur détient les droits d’accès

a) Ajouter un sinistre :
a. L’utilisateur clique sur « Ajouter un sinistre ».
b. Le système affiche une interface pour la saisie des informations relatives au
sinistre.
c. L’utilisateur saisie les informations.
d. L’utilisateur clique sur « Enregistrer ».

b) Consulter un sinistre :
a. L’utilisateur clique sur « Liste des sinistre ».
b. Le système affiche la liste du sinistre.
c. L’utilisateur sélectionne un sinistre.
d. Le système affiche les informations de sinistre.

c) Modifier un sinistre :
a. L’utilisateur clique sur « Liste des sinistre ».

8
b. Le système affiche la liste des sinistres.
c. L’utilisateur sélectionne un sinistre.
d. Le système affiche les détails du sinistre.
e. L’utilisateur saisie les informations à modifier.
f. L’utilisateur clique sur « Enregistrer ».

d) Suppression d’un sinistre :


a. L’utilisateur clique sur « Liste des sinistre ».
b. Le système affiche la liste des sinistres.
c. L’utilisateur sélectionne un sinistre.
d. L’utilisateur clique sur « Supprimer sinistre ».

e) Ajouter un item au sinistre :


a. L’utilisateur clique sur « Liste des sinistre ».
b. Le système affiche la liste des sinistres.
c. L’utilisateur sélectionne un sinistre.
d. Le système affiche les informations du sinistre.
e. L’utilisateur clique sur ajouter items.
f. Le système affiche les items possibles d’ajouter.
g. L’utilisateur ajoute les items.
h. L’utilisateur clique sur « Enregistrer ».

f) Supprimer item d’un Sinistre :


a. L’utilisateur clique sur « Liste des sinistre ».
b. Le système affiche la liste du sinistre.
c. L’utilisateur sélectionne un sinistre.
d. Le système affiche les informations du sinistre.
e. L’utilisateur sélectionne un item.
f. L’utilisateur clique sur « supprimer item ».

g) Ajouter justificatif :

9
a. L’utilisateur clique sur « Liste des sinistre ».
b. Le système affiche la liste du sinistre.
c. L’utilisateur sélectionne un sinistre.
d. Le système affiche les informations du sinistre.
e. L’utilisateur clique sur ajouter isutificatif.
f. L’utilisateur saisie le justificatif.
g. L’utilisateur clique sur « Enregistrer ».

h) Supprimer justificatif :
a. L’utilisateur clique sur « Liste des sinistre ».
b. Le système affiche la liste du sinistre.
c. L’utilisateur sélectionne un sinistre.
d. Le système affiche les informations du sinistre.
e. L’utilisateur clique sur justificatif.
f. Le système affiche la liste des justificatifs
g. L’utilisateur sélectionne le justificatif.
h. L’utilisateur clique sur supprimer le justificatif.
i. L’utilisateur clique sur « Enregistrer ».

Post-conditions :

Enchainement (1) : Déclaration de sinistre ajoutée dans le système.


Enchainement (2) : Déclaration de sinistre modifiée dans le système.
Enchainement (4) : Déclaration de sinistre Supprimée dans le système.
Enchainement (5) : Item ajouté à la Déclaration de sinistre.
Enchainement (6) : Item supprimé de Déclaration de sinistre.
Enchainement (7) : Justificatif ajouté de Déclaration de sinistre.
Enchainement (8) : Justificatif supprimé de Déclaration de sinistre.

10
4. Gestion des dossiers sinistres
n Cas d'utilisation Acteur
1 Création d’un dossier sinistre RS
2 Consultation d’un dossier sinistre RS/DAA
3 Modification d’un dossier sinistre RS
4 Suppression d’un dossier sinistre RS
5 Ajouter un sinistre au dossier : RS
6 Supprimer un sinistre d’un dossier sinistre : RS
7 Ajouter justificatif : RS
8 Supprimer justificatif RS
9 Ajouter Quittance de remboursement sinistre : RS
Supprimer une Quittance de remboursement sinistre
10
: RS

Identification du cas :

But : Ajouter un dossier sinistre.

Acteurs : RS, DAA.

Scénario nominal :

Ce volet assure la gestion des dossiers de sinistres tout au long du processus.

Pré conditions :

- Utilisateur authentifié
- Utilisateur détient les droits d’accès

a) Créer un dossier sinistre :


a. L’utilisateur clique sur « Ajouter un dossier sinistre ».
b. Le système affiche une interface pour la saisie des informations relatives au
sinistre.
c. L’utilisateur saisie les informations.
d. L’utilisateur clique sur « Enregistrer ».

b) Consulter un dossier sinistre :


a. L’utilisateur clique sur « Liste des dossiers sinistres ».
b. Le système affiche la liste des dossiers sinistres.
c. L’utilisateur sélectionne un dossier sinistre.
d. Le système affiche les informations du dossier sinistre.

c) Modifier un dossier sinistre :


a. L’utilisateur clique sur « Liste des dossiers sinistres ».
b. Le système affiche la liste des dossiers sinistres.

11
c. L’utilisateur sélectionne un dossier sinistre.
d. Le système affiche les détails du dossier sinistre.
e. L’utilisateur saisie les informations à modifier.
f. L’utilisateur clique sur « Enregistrer ».

d) Suppression d’un dossier sinistre :


a. L’utilisateur clique sur « Liste des dossiers sinistres ».
b. Le système affiche la liste des dossiers sinistres.
c. L’utilisateur sélectionne un dossier sinistre.
d. L’utilisateur clique sur « Supprimer dossier sinistre ».

e) Ajouter un sinistre au dossier :


a. L’utilisateur clique sur « Liste des dossiers sinistres ».
b. Le système affiche la liste des dossiers sinistres.
c. L’utilisateur sélectionne un dossier sinistre.
d. Le système affiche les informations du dossier sinistre.
e. L’utilisateur clique sur ajouter un sinistre.
f. Le système affiche la liste des sinistres possibles d’ajouter.
g. L’utilisateur ajoute un sinistre.
h. L’utilisateur clique sur « Enregistrer ».

f) Supprimer un sinistre d’un dossier sinistre :


b. Le système affiche la liste des dossiers sinistre.
c. L’utilisateur sélectionne un dossier sinistre.
d. Le système affiche les informations du dossier
sinistre.
e. L’utilisateur clique sur « sinistre ».
f. Le système affiche la liste des sinistres relatifs au
dossier.
g. L’utilisateur sélectionne un sinistre.
h. L’utilisateur clique sur « supprimer sinistre ».

g) Ajouter justificatif :
a. L’utilisateur clique sur « Liste des sinistre ».
b. Le système affiche la liste du sinistre.
c. L’utilisateur sélectionne un sinistre.
d. Le système affiche les informations du sinistre.
e. L’utilisateur clique sur « justificatif ».
f. L’utilisateur clique sur « ajouter ».
g. L’utilisateur sélectionne un justificatif.
h. L’utilisateur valide le justificatif.
h) Supprimer justificatif :
a. L’utilisateur clique sur « Liste des dossiers sinistre ».
b. Le système affiche la liste des dossiers sinistre.
12
c. L’utilisateur sélectionne un dossier sinistre.
d. Le système affiche les informations du dossier sinistre.
e. L’utilisateur clique sur « justificatif ».
f. Le système affiche la liste des justificatifs.
g. L’utilisateur sélectionne un justificatif.
h. L’utilisateur clique sur « supprimer ».

i) Ajouter Quittance de remboursement sinistre :


a. L’utilisateur clique sur « Liste des dossiers sinistre ».
b. Le système affiche la liste des dossiers sinistre.
c. L’utilisateur sélectionne un dossier sinistre.
d. Le système affiche les informations du dossier sinistre.
e. L’utilisateur clique sur « quittance ».
f. Le système affiche l’onglet « quittance ».
g. L’utilisateur clique sur « ajouter quittance ».
h. Le système affiche une interface pour la saisie des informations relatives à la quittance.
i. L’utilisateur saisie les informations et clique sur « ajouter ».

j) Supprimer une Quittance de remboursement sinistre :


a. L’utilisateur clique sur « Liste des dossiers sinistre ».
b. Le système affiche la liste des dossiers sinistre.
c. L’utilisateur sélectionne un dossier sinistre.
d. Le système affiche les informations du dossier sinistre.
e. L’utilisateur clique sur « quittance ».
f. Le système affiche la liste des quittances relative au dossier.
g. L’utilisateur sélectionne une quittance.
h. L’utilisateur clique sur « supprimer quittance ».

Post-conditions :

Enchainement (1) : création d’un dossier.


Enchainement (2) : dossier sinistre modifiée dans le système.
Enchainement (4) : dossier sinistre Supprimée dans le système.
Enchainement (5) : sinistre ajouté au dossier sinistre.
Enchainement (6) : sinistre supprimé dans dossier sinistre.
Enchainement (7) : Justificatif ajouté dans dossier sinistre.
Enchainement (8) : Justificatif supprimé dans dossier sinistre.
Enchainement (9) : quittance ajoutée dans dossier sinistre.
Enchainement (10) : quittance supprimée dans dossier sinistre.

13
5. Gestion des règlements :
1 Ajouter un chèque
2 Consulter un chèque en cours de règlement :
3 Modifier un chèque :
4 Suppression d’un chèque :
5 Ajouter une quittance à un chèque « en cours » :
6 Supprimer quittance d’un chèque « en cours » :

Identification du cas :

But : Ajouter une déclaration de sinistre.

Acteurs : AGTD, RASD.

Scénario nominal :

Ce volet assure la gestion des déclarations de sinistres tout au long du processus.

Pré conditions :

- Utilisateur authentifié

- Utilisateur détient les droits d’accès

a) Ajouter un chèque :
a. L’utilisateur clique sur « Ajouter un chèque ».
b. Le système affiche une interface pour la saisie des informations relatives au chèque.
c. L’utilisateur saisie les informations.
d. L’utilisateur clique sur « Enregistrer »

b) Consulter un chèque en cours de règlement :


a. L’utilisateur clique sur « Liste des chèques en cours de règlement ».
b. Le système affiche la liste des chèques en cours règlement.
c. L’utilisateur sélectionne un chèque.
d. Le système affiche les informations du chèque en cours règlement.

c) Modifier un chèque :
a. L’utilisateur clique sur « Liste des chèques ».
b. Le système affiche la « liste des chèques ».
c. L’utilisateur sélectionne un « chèque ».
d. Le système affiche les détails du « chèque ».
e. L’utilisateur saisie les informations à modifier.
f. L’utilisateur clique sur « Enregistrer ».

d) Suppression d’un chèque :


a. L’utilisateur clique sur « Liste des chèques en cours ».
b. Le système affiche la « liste des chèques ».
14
c. L’utilisateur sélectionne un « chèque ».
d. L’utilisateur clique sur « Supprimer chèque en cours ».

e) Ajouter une quittance à un chèque « en cours » :


a. L’utilisateur clique sur « Liste des chèques en cours ».
b. Le système affiche la liste des chèques en cours.
c. L’utilisateur sélectionne un chèque en cours.
d. Le système affiche les informations du chèque en cours.
e. L’utilisateur clique sur ajouter une quittance.
f. Le système affiche les des quittances possibles d’ajouter.
g. L’utilisateur sélectionne une quittance.
h. L’utilisateur ajoute la quittance.

f) Supprimer quittance d’un chèque « en cours » :


a. L’utilisateur clique sur « Liste des chèques ».
b. Le système affiche la liste des chèques.
c. L’utilisateur sélectionne un chèque.
d. Le système affiche les informations du chèque.
e. L’utilisateur sélectionne une quittance.
f. L’utilisateur clique sur « supprimer quittance ».
Post-conditions :

Enchainement (1) : « chèque » ajoutée dans le système.


Enchainement (3) : « chèque » modifiée dans le système.
Enchainement (4) : « chèque en cours » Supprimée dans le système.
Enchainement (5) : quittance ajoutée à un chèque dans le système.
Enchainement (6) : Quittance supprimé d’un chèque.

15
6. Gestion des clients :

n Cas d'utilisation Acteur


1 Contrat à renouveler AR
2 Client à contacter AR
3 Réclamations AR

Identification du cas
But : assurer le suivi des clients.
Acteurs : AR.

Pré conditions :
- Utilisateur authentifié
- Utilisateur détient les droits d’accès

Scénario nominal :
Ce volet assure la gestion des clients de l’assurance.
Enchainements :
a) Contrat à renouveler :
a. L’utilisateur clique sur « contrat à renouveler ».
b. Le système affiche la liste de contrats à renouveler, les dates de renouvellement el
les numéros de téléphone des clients assurés.
c. L’utilisateur choisi l’action à faire.
d. L’utilisateur clique sur « Enregistrer ».
b) Clients à contacter :
a. L’utilisateur clique sur « clients à contacter ».
b. Le système affiche la liste de contacts à contacter, les raisons pour lesquelles les
contacter la réaction à faire.
c. L’utilisateur choisi l’action à faire.
d. L’utilisateur clique sur « Enregistrer ».
c) Réclamations :
a. L’utilisateur clique sur « réclamations ».
b. Le système affiche la liste de réclamations et la réaction à faire.
c. L’utilisateur choisi l’action à faire.
d. L’utilisateur clique sur « Enregistrer ».

16
II. Les Besoins Non Fonctionnelles :

A. Définition des Besoins Non Fonctionnelles


Il s'agit des besoins qui caractérisent le système. Ce sont des besoins en matière de
performance, de type de matériel ou le type de conception. Ces besoins peuvent concerner les
contraintes d'implémentation (langage de programmation, type SGBD, de système
d'Exploitation...)
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.
Parmi les besoins que l’application et la plateforme doivent contenir :

1. Sécurité :
Il faudra aussi noter que l'application devra être hautement sécurisée car les informations ne
devront pas être accessibles à tout le monde pour assurer les clients et les visiteurs.
 Besoins de mot de passe : longueur, caractères spéciaux, expiration, politique de
réutilisation
 Déconnexion après temps morts d’inactivité : durées, actions-
Sécurisé les modes de payements : avoir le choix d’enregistrements des données
bancaire ou pas.

2. Audit :
 Éléments Vérifiés : quels éléments métiers seront vérifiés ?
Il faut vérifier le mail, le numéro (l’envoie d’un sms de vérification) …
 Champs Vérifiés – quels champs de données seront vérifiés ?
Vérification des champs de numéro de téléphone (par exemple ne pas dépasser 10
chiffres) …
 Caractéristiques de fichier d’audit : image avant, image après, signature utilisateur et
horaire, etc.

3. Performance :

• Temps de réponse : le chargement de l’application, ouverture d’écran et des délais de


rafraîchissement, etc.
• En temps de traitement : fonctions, calculs, importations/exportations de données
• L’interrogation de données et Rapports : temps de chargement initial et des chargements
suivantes1

1
https://www.advaloris.ch/nos-services/gestion-de-projet/definir-besoins-fonctionnels-gestion-de-projet

17
4. Capacité

• Bande passante : combien de transactions par heure le système doit-il être capable de traiter
?
• Mémoire (Stockage) : combien de données le système doit-il être capable de stocker ?
• Besoins de croissance d’année-en-année (croissance organique)

5. Disponibilité

• Les heures d’opération : quelles heures de disponibilité ? Considérez les week-ends, les
vacances, des périodes de maintenance, etc.
• Les emplacements d’opération : d’où devrait-il être disponible, quels sont les besoins de
connexion ?

6. Fiabilité

• Moyenne des temps de bon fonctionnement : Quel est le seuil acceptable de temps
d’indisponibilité ? Par exemple : une fois par an, 4,000 heures par an.
• Le temps Moyen de Rétablissement : si cassé, combien de temps est disponible pour
restaurer le système à nouveau ?

7. Intégrité

• La capture des erreurs d’entrée-sortie : comment traiter les échecs d’interface électroniques,
etc.
• Le traitement des mauvaises données : import de données, marquer et continuer ou arrêt la
politique d’importation, etc.
• Intégrité des données : intégrité référentielle dans tables de base de données et interfaces
• Compression d’image et normes de décompression

8. Rétablissement

• Durées des temps de récupération : combien de temps le rétablissement devrait-il prendre


pour s’exécuter ?
• Fréquences des sauvegardes – à quelle fréquences les données de transaction, d’installation
(de paramétrage) et le système (le code) doivent-ils être sauvegardés ?2

2
https://www.developpez.net/forums/d801557/general-developpement/alm/methodes/distinguer-l-
expression-besoins-fonctionnels-non-fonctionnels/

18
• Générations de secours – quels sont les besoins pour la restauration à l’état précédent le
problème ?

9. Compatibilité

• La compatibilité avec des applications partagées : À quels autres systèmes doit-il parler ?
• La compatibilité avec des applications tierces : Avec quels autres systèmes doit-il cohabiter
?
• La compatibilité sur des systèmes d’exploitation différents : sur lesquels doit-il être capable
de fonctionner ?
• La compatibilité sur des plateformes différentes : Sur quelles sont les plateformes
matérielles doit-il marcher ?

10. Aptitude à la maintenance

• La conformité aux standards d’architecture : à quels standards a-t-il besoin de se conformer


ou en être exempté ?
• La conformité aux standards de design : Quels standards de conception doivent être suivis
ou des exemptions obtenues ?
• La conformité aux standards de développement : Quels standards de développement doivent
être suivis ou des exemptions obtenues ?

11. Ergonomie

• Les standards d’ergonomie : la densité d’éléments sur les écrans, la disposition et le flux, les
couleurs, l’Interface Utilisateur, les raccourcis clavier
• Internationalisation / besoins de localisation : langages, orthographe, claviers, formats de
papier, etc.

12. Documentation

• Eléments de documentation requis et utilisateur de chaque élément

19
Conclusion :

Après l’établissement de l’Etat d’Art et l’étude des besoins fonctionnels et non fonctionnels

on a fait les premiers pas afin de réaliser notre projet, on a décrit le logiciel à développer en

détaillant tous ses critères dans deux axes, un qui comporte les besoins fonctionnels et le

deuxième qui traite les besoins non fonctionnels qui sont essentiels pour la concrétisation de

l’application web et mobile. Ensuite on va passer à l’étape de conception et de modélisation

qu’on va la traiter dans notre 3eme rapport.

20
WEBOGRAPHIE :

- https://www.developpez.net/forums/d801557/general-
developpement/alm/methodes/distinguer-l-expression-besoins-fonctionnels-non-
fonctionnels/

- https://www.advaloris.ch/nos-services/gestion-de-projet/definir-besoins-fonctionnels-
gestion-de-projet

21

Vous aimerez peut-être aussi