IV.3.2. Les spécifications non fonctionnelles
Les spécifications non fonctionnelles regroupent tout
ce qui est besoins ou exigences que doit remplir le système pour qu'il
assure au mieux son travail. Parmi ces besoins nous pouvons citer :
· Besoin d'utilisabilité
· Besoins de performance
· Besoins de disponibilité/fiabilité
· Besoins de sécurité
· Besoins matériels
· Besoins de déploiement
Faisant parti des qualités exigées par le
génie logiciel, les spécifications non fonctionnelles seront
respectées et suivies à lettre lors du développement et le
déploiement de notre système.
IV.3.3. Les spécifications liées aux domaines
d'activité
Comme nous le dit la définition, les
spécifications liées aux domaines d'activité peuvent
être des spécifications fonctionnelles ou non fonctionnelles mais
ces spécifications doivent décrire d'une manière un peu
plus claire, les activités du système. Nous parlerons de ce type
des spécifications en détail, un peu plus loin dans ce
travail.
T.F.E 2015 | Benito Lubuma L2 Génie info
67
IV.3.4. Comment définir des
spécifications
Le diagramme ci-dessous montre les démarches à
suivre pour aboutir à une bonne spécification du
système.
Figure IV. 15 étapes à suivre pour une bonne
spécification
Après une étude de faisabilité
approfondie qui nous a permis d'avoir une vue d'ensemble du rôle du
système dans son éventuel environnement d'utilisation en vue
d'évaluer sa pertinence. D'où nous nous sommes mis d'accord avec
rapport de faisabilité à la main que déployer un tel
système fera le bonheur de toutes les parties prenantes.
A. Analyse du besoin
Apres une réponse positive provenant de notre
étude de faisabilité, nous allons expliciter et analyser les
besoins. Pour mieux le faire, nous allons définir les personnes
affectées par le système et évaluer leurs besoins par
ordre d'importance.
La quasi-totalité des utilisateurs de notre
système étant des étrangers à l'informatique et
décrivant donc leur interaction avec le système en utilisant des
termes imprécis ou exotiques, une bonne analyse de besoins passe par la
définition des interlocuteurs (personne affectées par le
système) et évaluer leur besoin par ordre d'importance. Ces
points de vue peuvent être classifiés en trois catégories
:
? Celui des personnes qui interagissent avec le système
(utilisateurs) ;
? Celui des personnes qui ont une relation indirecte avec le
système ;
? Celui, plus général, lié au domaine
d'application.
68
1. Celui des personnes qui interagissent avec le
système
Etant donné que le système que nous voulons
développer est un système bénéficiant d'une
architecture hybride qui renferme plusieurs types d'autres architectures,
l'identification des utilisateurs qui devront interagir avec le système
est rendue possible grâce au sous-système d'interface interactive
qui est un système dominé par des interactions entre le
système et des agents externes. Nous pouvons dire que les êtres
humains, particulièrement les utilisateurs de G.A.B seront les
principaux acteurs à interagir avec notre système.
2. Celui des personnes qui ont une relation indirect
avec le système
Notre système étant un système
informatique, nous pouvons identifier les acteurs qui interagissent
indirectement avec de la manière suivante :
· L'administrateur réseau du système,
· La banque.
3. Celui, plus général, qui est lié
au domaine de l'application
Quand nous parlons de ceux qui sont liés au domaine de
l'application, nous faisons allusion aux acteurs qui se situent dans le domaine
de l'activité du système et plus particulièrement, aux
ingénieurs qui développeront et feront la maintenance du
système et les systèmes devant s'interfacer avec le
système spécifié.
| 
